Short unpadded local recordings cause spurious timers on IceTV server

[prl]

If a short recording timer is created on the Beyonwiz, it appears as a set of spurious single recordings on the same channel on the IceTV server spanning about 24 hours.

The problem is caused in Plugins.SystemPlugins.IceTV.plugin.EPGFetcher in methods putTimer() and postTimer(). They attempt to adjust the times on the Beyonwiz-generated timer by removing its padding, but the code has no way of determining whether the timer was padded or not.

If the duration of the timer is less than the sum of the current pre- and post-padding, the resulting timer duration will be negative (I have not tested the case where the adjusted time is 0). The code does not test the duration to ensure that it is a reasonable value and the negative duration is sent as part of the timer update to the IceTV server. The server correctly sends back an error message, but what appears to be a contributory bug in the server causes recording timers to be set on the IceTV server for about a 24-period from the timer's start.

The underlying problem causing this bug that timers lack the information needed to accurately remove padding when trying to match the timer against the EPG. This is also the underlying cause of bug #449, and of problems caused in AutoTimers when "Guess existing timer based on begin/end" is enabled.

I have also alerted IceTV support (specifically Dave at IceTV) about the cause of this problem, and the possibility of a contributory bug in the IceTV server.

Replication steps

Enable IceTV and update the EPG and timers if necessary. Check that the pre- and post-timer settings are in a user's typical range (the default 2 + 20 min IceTV default, for example).

Enable debug logging on the Beyonwiz and restart the GUI to get a new log file.

Select a channel where there are no, or few, existing timers for the next 24 hours or (a little more). This makes the pattern of timer creation more obvious.

Create a short timer that satisfies timerduration < prepadding + postpadding. A "given duration" instant timer is a convenient way of doing this.

Go to the IceTV account's My Week page for the device, and refresh the display. There should be back-to-back recording times shown on the real timer's channel spanning the next 24 hours.

Look for the IceTV log messages in the debug logs (enabling extra IceTV debug logging is not necessary, and created clutter).

The timer update message from the Beyonwiz will be something like: [IceTV] headers {'Content-Length': '204', 'Content-Type': 'application/json', 'Accept-Encoding': 'gzip, deflate', 'Accept': 'application/json', 'User-Agent': 'SystemPlugins.IceTV/20150925 (Beyonwiz; T3)'} [IceTV] {"name": "The Talk", "start_time": "2016-01-07T02:02:39+00:00", "duration_minutes": -20, "channel_id": 55, "state": "running", "action": "record", "message": "Created by Beyonwiz T3", "device_id": 164966}

The error message should look something like: [IceTV] 406 Not Acceptable [IceTV] headers {'content-length': '104', 'access-control-allow-methods': 'GET, POST, PUT, DELETE', 'x-powered-by': 'CppCMS/1.0.3', 'set-cookie': 'AWSELB=FF9FA59B0AA9FAB4E737D9FE7A7C22F11253580EC0D24ADC55CEE08267D3C43F5DA893040553F9688133D842341C470880B88B69097B6B2F6A527998EE6589C2E8AD6EA1EA;PATH=/;MAX-AGE=3600', 'access-control-allow-credentials': 'true', 'server': 'Apache/2.2.15 (CentOS)', 'connection': 'keep-alive', 'cache-control': 'no-cache="set-cookie"', 'date': 'Thu, 07 Jan 2016 02:00:46 GMT', 'access-control-allow-origin': '', 'access-control-allow-headers': 'origin, content-type, accept', 'content-type': 'application/json; charset=utf-8'} [IceTV] {"errors":[{"error_code":11,"error_msg":"start_time and/or channel_id and/or duration are invalid "*}]}