IceTV API documentation

Started by Daniel Hall at IceTV, March 15, 2016, 05:06:33 PM

Previous topic - Next topic

Daniel Hall at IceTV

Hmm, I cannot see any errors in the server log, and actually looking at the response it does look like all three were correctly updated to a state of 'pending' (this is also reflected in the audit log). However I cannot see the current state of the timer for "24 Hours In Emergency" as it was updated again from the website at 4:24 pm.

I can also see that there is something a little 'interesting' with the reschedule, and while it won't affect the actual scheduling I am checking it out as well.

I have added some additional logging server side to help try and find any issues, can you please perform the test again with three new shows that have not been scheduled under this device before.
Regards,

Daniel.
CTO.

prl

Quote from: Daniel Hall at IceTV on May 11, 2016, 06:43:59 PM
... However I cannot see the current state of the timer for "24 Hours In Emergency" as it was updated again from the website at 4:24 pm. ...
Yes, sorry, I left IceTV enabled while I composed the post, and by the time I'd posted, the T3 had done another update and fixed the problem.
Peter
Beyonwiz T4 in-use
Beyonwiz T2, T3, T4, U4 & V2 for testing

Daniel Hall at IceTV

Quote from: prl on May 12, 2016, 11:17:58 AM
Quote from: Daniel Hall at IceTV on May 11, 2016, 06:43:59 PM
... However I cannot see the current state of the timer for "24 Hours In Emergency" as it was updated again from the website at 4:24 pm. ...
Yes, sorry, I left IceTV enabled while I composed the post, and by the time I'd posted, the T3 had done another update and fixed the problem.

All good, it should be easier to find any issues with the additional logging now as well.
Regards,

Daniel.
CTO.

prl

OK, another try. This time I've checked to make sure that another IceTV update hasn't corrected the problem, and the T3 is shut down.

Again, three one-off timers and the server side IceTV recording entry for one of them ("The Daily Edition") wasn't updated even though a timer was created for the recording on the T3 and the T3 responded that the timer state was "pending".

The update was at about 11:30 today. There will be some earlier clutter, because the timer set yesterday were deleted and my first test crossed over with that, so I had to re-do the test.

The IceTV response and the T3's timers have been reformatted for readability.

Summary:
The Daily Edition, Sally Obermeder and Kris Smith ..., 1463016536
Parliament Question Time - House Of Representatives, Live coverage of Question Time ..., 1463016512
Sonic Boom, Eggheads / Guilt Tripping, 1463016524

Response to IceTV timers data:
[
  {
    u'show_id': u'125723933', u'name': u'The Daily Edition',
    u'start_time': u'2016-05-12T04:00:00+00:00', u'state': u'pending',
    u'channel_id': u'56', u'duration_minutes': u'60', u'action': u'record',
    u'keyword_id': u'0', u'message': u'Added', u'id': u'1463016536',
    u'series_recording_id': u'0', u'device_id': u'164966'
  }, {
    u'show_id': u'125696587', u'name': u'Parliament Question Time - House Of Representatives',
    u'start_time': u'2016-05-12T04:00:00+00:00', u'state': u'pending',
    u'channel_id': u'71', u'duration_minutes': u'75', u'action': u'record',
    u'keyword_id': u'0', u'message': u'Added', u'id': u'1463016512',
    u'series_recording_id': u'11637913', u'device_id': u'164966'
  }, {
    u'show_id': u'125722234', u'name': u'Sonic Boom',
    u'start_time': u'2016-05-12T04:00:00+00:00', u'state': u'pending',
    u'channel_id': u'2384', u'duration_minutes': u'30', u'action': u'record',
    u'keyword_id': u'0', u'message': u'Added', u'id': u'1463016524',
    u'series_recording_id': u'11637914', u'device_id': u'164966'
  }
]


Beyonwiz T3 timers:
<?xml version="1.0" ?>
<timers>
  <timer begin="1463025480" end="1463030400" serviceref="1:0:1:946:99E:3281:EEEE0000:0:0:0:"
    repeated="0" rename_repeat="1" name="The Daily Edition"
    description="Sally Obermeder and Kris Smith bring us current headline news, as well as entertainment updates and celebrity interviews. Tom Williams and Monique Wright round off the team for this current affairs arvo show." afterevent="auto" eit="43148" tags=""
    disabled="0" justplay="0" always_zap="0" descramble="1" record_ecm="0"
    isAutoTimer="0" ice_timer_id="1463016536">
  </timer>
  <timer begin="1463025480" end="1463031300" serviceref="1:0:1:210:211:1010:EEEE0000:0:0:0:"
    repeated="0" rename_repeat="1" name="Parliament Question Time - House Of Representatives"
    description="Live coverage of Question Time from Federal Parliament in Canberra." afterevent="auto" eit="15802" tags=""
    disabled="0" justplay="0" always_zap="0" descramble="1" record_ecm="0"
    isAutoTimer="0" ice_timer_id="1463016512">
  </timer>
  <timer begin="1463025480" end="1463028600" serviceref="1:0:1:782:327A:3273:EEEE0000:0:0:0:"
    repeated="0" rename_repeat="1" name="Sonic Boom"
    description="Eggheads / Guilt Tripping" afterevent="auto" eit="41449" tags=""
    disabled="0" justplay="0" always_zap="0" descramble="1" record_ecm="0"
    isAutoTimer="0" ice_timer_id="1463016524">
  </timer>
</timers>
Peter
Beyonwiz T4 in-use
Beyonwiz T2, T3, T4, U4 & V2 for testing

Daniel Hall at IceTV

Cheers for that, I can see something that's a little weird, but not the root cause as yet, will run some tests here locally on our dev server and let you know as soon as I know more.
Regards,

Daniel.
CTO.

prl

I can give you the version of the plugin I'm using if that helps.
Peter
Beyonwiz T4 in-use
Beyonwiz T2, T3, T4, U4 & V2 for testing

Daniel Hall at IceTV

Quote from: prl on May 12, 2016, 04:58:16 PM
I can give you the version of the plugin I'm using if that helps.

I don't have a T4 here for testing so it wouldn't matter, I have been trying to replicate the issue in our dev environment manually, but have not been able to.

Will test again on the live server, but its definitely a little weird right now.
Regards,

Daniel.
CTO.

prl

OK. Thanks for the update.

The changes will work on any Beyonwiz T series, if that helps. In fact, the testing I've been doing of this is on a T3.
Peter
Beyonwiz T4 in-use
Beyonwiz T2, T3, T4, U4 & V2 for testing

prl

#38
Hi Daniel.

I've got back to working on fixing the Beyonwiz IceTV plugin problem where it can report "No matching service" when the error is actually "Timer conflict".

I'm still seeing the same problem that I posted about above. When a set of new timers is sent from the IceTV server to my test T4, the last timer sent is set on the T4, but it remains showing "queued" on IceTV, and if it's then deleted on IceTV, it's not deleted on the T4, because Ice thinks that because it wasn't successfully sent, there's no need to delete it.

That the problem is still there isn't a surprise, because you never said you'd found it and fixed it. I'm raising it again because in my testing I noticed something that may help nail down the problem.

When I set up a test case with 4 overlapping single IceTV timers on the T4, and sent a 4th one, I was able to reproduce the bug where the wrong error message was sent.

But something else curious happened. I got an email from the IceTV server telling me that the timer setting had failed (confirming what the debug prints on the T4 said), but the recording's icon on the IceTV Web pages didn't change - it stayed as "Queued Single Recording" when it should have changed to "Error".

So it seems that the timer acknowledgement information from the T4 is arriving as expected in the server, and is being processed by some of the software that should look at it, but is being ignored by other parts of the software.

I hope that gives a hint as to what might be happening in the server.

This server bug makes verifying the client fixes more difficult, because someone testing the fixes needs to be aware that some of the anomalous behaviour has nothing to do with the fix being tested.

Added: I've left the IceTV and T4 state (IceTV device name Beyonwiz T4) as it was at the time of the odd behaviour that I posted about, so if you want to have a look at the logs, the most recent state should be what I see.
Peter
Beyonwiz T4 in-use
Beyonwiz T2, T3, T4, U4 & V2 for testing

prl

The documentation pages don't seem to be playing nice. When I try to access http://developer.icetv.com.au/Home.html, I get:
404 Not Found

    Code: NoSuchKey
    Message: The specified key does not exist.
    Key: Home.html
    RequestId: 1FB50BD0229F9F6D
    HostId: nYdsOwpMwXklRXboKylgaAEeoPV6dp5Io3qq29O7Sag1Cw7SdE9xT1K2LTxpDHGFVLqqq9ndu7U=


:(
Peter
Beyonwiz T4 in-use
Beyonwiz T2, T3, T4, U4 & V2 for testing

Rowdy

Topfield 5000, 2400, Skippa

prl

Thanks. That works. It loohs lik a new setup.
Peter
Beyonwiz T4 in-use
Beyonwiz T2, T3, T4, U4 & V2 for testing

prl

When a timer is created locally on a PVR using the "new" IceTV API (Beyonwiz T series, Skippa, etc), the Timer Workflow document says:
Quote
Local Timers

Timers created locally on the TV Recorder must be sent to the IceTV server, this can be done for a single timer via a POST to /shows/timers or in a batch as a PUT to /shows/timers.

Locally generated timers initially have no id, this will be generated by the server and returned to the client in the response from the request that created them.

The TV Recorder should match the timers in the response to the locally generated timers and update them as needed.

I have some questions about just what is supposed to happen with locally created timers that:

  • Don't exactly match a current EPG timeslot (e.g. span two or more sequential events)
  • Have a repeat option selected (daily, weekly, etc)

The question is prompted by Beyonwiz users having locally-created repeating timers being unexpectedly deleted by the IceTV server. I can't establish a pattern of when this happens other than that it seems to happen after (but not necessarily immediately after) the first time the repeat timer runs.

Here's an example collected from the logs by one user (on WAST GMT+8):
The timer was read from timers.xml at startup on Fri Apr 14 ~10:40 WAST:
{532}<    50.112> [RecordTimer] Record RecordTimerEntry(name=ABC News At Noon, begin=Fri Apr 14 11:55:00 2017, end=Fri Apr 14 12:35:00 2017, serviceref=1:0:19:2E5:261:3201:EEEE0000:0:0:0:, justplay=0, isAutoTimer=0, ice_timer_id=16285299137673692582)
The logging doesn't print the repeat setting, but the repeat setting is 31 (0x1f), which is a Mon-Fri repeat.

Then at Fri Apr 14 ~17:12 WAST ("last_update_time":"1492161123"):
"timers":[{"id":"16285299137673692582","device_id":"176230","channel_id":"2687","name":"ABC News At Noon","show_id":"131424503","start_time":"2017-04-14T04:05:00+00:00","duration_minutes":"6","action":"forget","state":"waiting","message":"Unschedule requested via PIMP web interface.","series_recording_id":"0","keyword_id":"0"}]

The sequence of events was (all WAST times):
Apr 14 10:40: boot
Apr 14 10:40: timer for ABC News At Noon read from file, recording from Apr 14 11:55 to Apr 14 12:35
Apr 14 11:55: timer starts
Apr 14 12:35: timer ends
Apr 14 17:12: IceTV sends "forget" request for timer

So there's about 3 3/4 hours between the end of the recording and when the timer is deleted.

This local timer is for the unpadded EPG run time of ABC News at Noon, the IceTV plugin can't tell what the padding is, so it always strips padding and that's why the start time and the duration of the server side timer is so different from the local timer.

The user has kept the logs and is happy to share them, or extracts from them, if that will help locate server-side loging information about the deletion.

The same user also has a number of locally set repeat timers being watched, both with standard padding and with times that wouldn't match an IceTV EPG entry exactly, and many of them are continuing to run without problems.

The discussion on this issue on the Beyonwiz forum is in Daily recordings not working.

Any information about why that timer (and others like it) seem to be being deleted apparently at random, and on how locally-set repeating timers are intended to be handled in the API would be greatly appreciated.

With the current Beyonwiz IceTV plugin, I would expect that a repeating timer set on the Beyonwiz would initially appear as a single recording on the IceTV Web page, and then disappear from the Web page, but otherwise run normally after the first run.
Peter
Beyonwiz T4 in-use
Beyonwiz T2, T3, T4, U4 & V2 for testing

prl

Peter
Beyonwiz T4 in-use
Beyonwiz T2, T3, T4, U4 & V2 for testing