Hi Everyone,
We are please to announce that we have just released the documentation for the IceTV EPG and Smart Recording API.
With this documentation it is possible for PVR projects to be able to integrate into IceTV's EPG and Smart Recording service.
To be able to utilize the service an application developer will need to be apply for a developer key, this can be done by emailing developer@icetv.com.au (this is detailed in the documentation).
The documentation can be found at http://developer.icetv.com.au/ (http://developer.icetv.com.au/)
Thanks Daniel.
Would it be possible to have the "regions" entity carry some DST offset data like the DVB TOT currently does? This would mean adding the current UTC offset, next transition date and next UTC offset.
I've just had a quick look at it, and there were errors in the first two entries in "shows" that I looked at. The documentation says that "category" is an array of entries have only one element, "name", but a category actually looks like:
"category": [{"name": "Documentary","eit":"0x23"},{"name": "Movie","eit":"0x10"}]
I.e. each category entry has two elements, "name" and "eit", not just "name".
I was also hoping that the API might enumerate the legal values for "name" and "eit" in category (since the IceTV values for both "name" and "eit" use a completely different set of names and interpretations from broadcast TV), but even the mere existence of "eit" is missing in the documentation.
Having this enumeration of the "name", "eit" pairs is necessary for the implementation of IceTV Genre/Category labels on the Beyonwiz T series.
Similarly, the documentation for "credits" says that "director" and "actor" are string elements of "credits". That's simply not what the "credits" structure looks like:
"credits": {"director": "Johnnie To","actors": [{"name": "Simon Yam"},{"name": "Kelly Lin"},{"name": "Ka Tung Lam"}]}
There is no "actor" element at all, and "actors" is an array of "name" elements.
It's really a bit disappointing. I hope that protocol descriptions (which I haven't had a proper look at) are better.
Quote from: DeltaMikeCharlie on March 15, 2016, 06:25:18 PM
Thanks Daniel.
Would it be possible to have the "regions" entity carry some DST offset data like the DVB TOT currently does? This would mean adding the current UTC offset, next transition date and next UTC offset.
We can also provide these in POSIX timezone string, so for example Sydney would be "EST+10EST+01,M10.1.0/02:00,M4.1.0/03:00". Will add this to the documentation as it requires a change on our end to set an application to use that.
Quote from: prl on March 17, 2016, 01:16:04 PM
I've just had a quick look at it, and there were errors in the first two entries in "shows" that I looked at. The documentation says that "category" is an array of entries have only one element, "name", but a category actually looks like:
"category": [{"name": "Documentary","eit":"0x23"},{"name": "Movie","eit":"0x10"}]
I.e. each category entry has two elements, "name" and "eit", not just "name".
I was also hoping that the API might enumerate the legal values for "name" and "eit" in category (since the IceTV values for both "name" and "eit" use a completely different set of names and interpretations from broadcast TV), but even the mere existence of "eit" is missing in the documentation.
Having this enumeration of the "name", "eit" pairs is necessary for the implementation of IceTV Genre/Category labels on the Beyonwiz T series.
Similarly, the documentation for "credits" says that "director" and "actor" are string elements of "credits". That's simply not what the "credits" structure looks like:
"credits": {"director": "Johnnie To","actors": [{"name": "Simon Yam"},{"name": "Kelly Lin"},{"name": "Ka Tung Lam"}]}
There is no "actor" element at all, and "actors" is an array of "name" elements.
It's really a bit disappointing. I hope that protocol descriptions (which I haven't had a proper look at) are better.
These have been updated, looks like it was mostly due to differences in the JSON vs the XML feeds.
Thanks, Daniel.
Quote from: Daniel Hall at IceTV on March 17, 2016, 05:06:56 PMWe can also provide these in POSIX timezone string
Thanks Daniel.
Quote from: DeltaMikeCharlie on March 17, 2016, 06:54:13 PM
Quote from: Daniel Hall at IceTV on March 17, 2016, 05:06:56 PMWe can also provide these in POSIX timezone string
Thanks Daniel.
Oh, and this has been updated in the documentation as well.
Having read the examples more closely, I have noticed that the requests are all https. Is there an option for using http?
Because of the limited Linux OS provided with the Topfield PVRs, I have to statically link absolutely everything. This makes the openssl libraries huge and the TAPs even bigger.
Quote from: Daniel Hall at IceTV on March 17, 2016, 05:07:36 PM
Quote from: prl on March 17, 2016, 01:16:04 PM
I've just had a quick look at it, and there were errors in the first two entries in "shows" that I looked at. The documentation says that "category" is an array of entries have only one element, "name", but a category actually looks like:
"category": [{"name": "Documentary","eit":"0x23"},{"name": "Movie","eit":"0x10"}]
I.e. each category entry has two elements, "name" and "eit", not just "name".
I was also hoping that the API might enumerate the legal values for "name" and "eit" in category (since the IceTV values for both "name" and "eit" use a completely different set of names and interpretations from broadcast TV), but even the mere existence of "eit" is missing in the documentation.
Having this enumeration of the "name", "eit" pairs is necessary for the implementation of IceTV Genre/Category labels on the Beyonwiz T series.
Similarly, the documentation for "credits" says that "director" and "actor" are string elements of "credits". That's simply not what the "credits" structure looks like:
"credits": {"director": "Johnnie To","actors": [{"name": "Simon Yam"},{"name": "Kelly Lin"},{"name": "Ka Tung Lam"}]}
There is no "actor" element at all, and "actors" is an array of "name" elements.
It's really a bit disappointing. I hope that protocol descriptions (which I haven't had a proper look at) are better.
These have been updated, looks like it was mostly due to differences in the JSON vs the XML feeds.
The field names for the JSON category entries have been corrected, but there's no proper enumeration of the values used for the two fields. The comment "Value as closest match to Table 28 in ETSI EN 300 468" really is a bit misleading, because IceTV uses multiple genre/category names for single Table 28 numerical values, and assigns names to Table 28 numerical values that the standards (both ETSI EN 300 468 and AS 4599) specify as "undefined content". The EIT content descriptor value 0x00 is both "undefined content" and given multiple text values by IceTV.
IceTV also seems to place "Adventure" with both codes 0x12 and 0x13. In Table 28 of ETSI EN 300 468, 0x12 is "adventure/western/war" and 0x13 is "science fiction/fantasy/horror".
Examples of other codes given multiple text values in the IceTV data are:
Ice IceTV
EIT Genre AS 4599 ETSI EN 300 468
---- ----- -------
0x10 Drama Movie/Drama movie/drama (general)
0x10 Medical Movie/Drama movie/drama (general)
0x10 Movie Movie/Drama movie/drama (general)
0x11 Crime Movie/Drama detective/thriller
0x11 Murder Movie/Drama detective/thriller
0x11 Mystery Movie/Drama detective/thriller
0x11 Thriller Movie/Drama detective/thriller
0x12 Action Movie/Drama adventure/western/war
0x12 Adventure Movie/Drama adventure/western/war
0x12 Cult Movie/Drama adventure/western/war
0x12 War Movie/Drama adventure/western/war
0x12 Western Movie/Drama adventure/western/war
0x13 Adventure Movie/Drama science fiction/fantasy/horror
0x13 Fantasy Movie/Drama science fiction/fantasy/horror
0x13 Horror Movie/Drama science fiction/fantasy/horror
0x13 Sci-Fi Movie/Drama science fiction/fantasy/horror
0x14 Animation Movie/Drama comedy
0x14 Comedy Movie/Drama comedy
0x14 Sitcom Movie/Drama comedy
The documentation still doesn't describe the "credits" element correctly. It gives its fields as "director" and "actor", when the second of those fields is "actors", and the documentation simply says that it's an "array", without specifying what it's an array of (and it's not a simple array of strings). There is an example of what the JSON "actors" array actually looks like in the example in the documentation.
Sorry to be going on a bit over the Genre codes, but the numeric codes appear to be the only way to make use of this IceTV data reliably in the T series.
The documentation states that the HTTP "Accept:" header needs to be set to "application/xml", however, I could only retrieve the "regions" entity using "text/xml".
http://developer.icetv.com.au/Home.html#src-917535_Home-HTTPAcceptheader
Here is the syntax that I had to use with wget:
wget.exe -O regions.xml --header="Accept: text/xml" "http://api.icetv.com.au/regions?api_key=[My_KEY]&application_version=1"
If I added an extension to the URI, then I could force XML format:
wget.exe -O regions.xml "http://api.icetv.com.au/regions.xml?api_key=[MY_KEY]&application_version=1"
Using the extension was the only way I could get JSON. The Accept header seemed to be ignored.
The Beyonwiz IceTV plugin uses JSON with "Accept: application/json", but it also supplies "Content-Type: application/json". It seems that the IceTV server demands the Content-Type even when it's not a POST query. I think that's wrong, but my HTTP is pretty rudimentary.
This works for me:
wget -O - --header="Accept: application/json" --header="Content-Type: application/json" "http://api.icetv.com.au/regions?api_key=[BeyonwizAppKey]&application_version=1"
If I change "json" to "xml" in the headers, I get XML instead of JSON. In fact all 4 possible combinations of "json" and "xml" in the headers work for that query. I assume if it was a POST query, you'd need the POST data to match the "Content-Type".
I have managed to get some EPG data in XML format by using an extension on the URI.
I have noticed that the "id" field is fairly large and all of the samples that I have looked at so far are 32bit integers.
I was hoping to use this field as an equivalent to the DVB EIT event_id field so that when modifications come in, I can easily identify it with the existing Topfield TAP API, however, this is only 16 bits. The "Event ID" field in the Topfield PIMP feed is also only 16 bits and was perfect for this purpose.
Internally, the Topfield timer records also carry this 16 bit code so that and indication can be shown in the EPG when a show is scheduled to be recorded.
I have experimented with reducing it mathematically but then I either end up with duplicates or having to keep track of the lowest id to subtract from the rest. The only way I see to reliably reduce this number would be to implement a lookup table with 4,294,967,296 slots and allocating the next available 16 bit integer with a lot of housekeeping.
The DVB specifications state that this number only needs to be unique within a channel, however, this would still just help me by using one lookup table per channel.
Quoteevent_id: This 16-bit field contains the identification number of the described event (uniquely allocated within a service definition).
Is there any way to provide a 16 bit ID for the EPG events? I also realise that this may need to be carried on to the timers node as well.
I have another query, this time about logging in.
I already have 2 PVRs registered with ICE and I'm trying to login using one of these. Unfortunately, they don't seem to have a uid, so I can't logon because I get an error:
Quote<error error_code="13" error_msg="Device details are required for recording app" />
Seeing that I have to login to get my list of devices, I basically have to create a new device just to be able to login.
When I was accessing via PIMP, I could get a list of recorders and then use the recorder index/id to access the EPG/Timer data.
Q1. How do I login without specifying a device node so that I can get a list of my devices?
Q2. How do I login as an existing PVR that has not been allocated a uid? I have tried using the id provided in my devices list (different to my PIMP device id) but I still get the error.
Quote from: DeltaMikeCharlie on March 17, 2016, 07:49:48 PMIs there an option for using http?
This is no longer necessary, I have managed to find a stand-alone cURL binary for the Topfield PVR architecture that supports https.
Firstly, I think that the following is my own doing, I'm not saying that ICE are to blame.
I have 2 Topfield PVRs that "normally" use ICE as an EPG source. As mentioned in a previous post, a third PVR was created when I logged on with the new API.
Last night, I discovered that my main PVR had stopped receiving ICE EPG data and I was unable to make it login. When I check my account, my main PVR was still there, but its name had been changed. I also found that I had about 6-7 "Smart Recording App" tokens listed, persuadably left over from my testing during the day.
I deleted these app tokens and the third phantom PVR and I was again able to receive EPG data on my main PVR.
I am assuming that I exceeded some licensing threshold and that ICE rightfully refused to service PVRs beyond that limit.
Can ICE please confirm how many recording devices a standard user is entitled to? Furthermore, can ICE please explain the relationship, if any, between app tokens and licensing entitlement?
Quote from: DeltaMikeCharlie on March 28, 2016, 07:55:48 AM
Firstly, I think that the following is my own doing, I'm not saying that ICE are to blame.
I have 2 Topfield PVRs that "normally" use ICE as an EPG source. As mentioned in a previous post, a third PVR was created when I logged on with the new API.
Last night, I discovered that my main PVR had stopped receiving ICE EPG data and I was unable to make it login. When I check my account, my main PVR was still there, but its name had been changed. I also found that I had about 6-7 "Smart Recording App" tokens listed, persuadably left over from my testing during the day.
I deleted these app tokens and the third phantom PVR and I was again able to receive EPG data on my main PVR.
I am assuming that I exceeded some licensing threshold and that ICE rightfully refused to service PVRs beyond that limit.
Can ICE please confirm how many recording devices a standard user is entitled to? Furthermore, can ICE please explain the relationship, if any, between app tokens and licensing entitlement?
You can have 5 recording devices in 1 paid account. These are the devices that show up on your My Recorders tab in My Account.
https://www.icetv.com.au/cgi-bin/webmembers.cgi?op=editSubscription
Newer recorders, phone apps and the old desktop widgets all use tokens. A new token is created each time the login process is completed in the app/widget or on the recorder.
Even if you somehow ended up with multiple hidden devices that exceeded your 5 device limit your original devices would still be allowed to access your account. It would be the new excessive devices that would be blocked from being added to the account or from accessing the account.
There is a daily fetch limit imposed on xml downloads, which I'm sure counts attempted connections and downloads as well. So if you were fetching the guide in xml format it is possible that your testing may have put you over the daily fetch limit for that day.
Maybe when your main Topfield's device name changed the device type also changed to a type that is blocked by the xml fetch limit. Or maybe it just changed to one that would not work with a Topfield... until you changed it back to the correct type when you renamed it (if you changed it back).
I'm not sure if CR/LFs are valid within XML elements. However, I have found an example of one in the new XML EPG data that was not present in the old XML EPG data.
In the old XML data, the CR/LF was converted to a space. In the new XML data the CR/LF was preserved and caused the element to be split over 2 lines.
I'm note sure if this is legal or not, simply different.
Quote from: DeltaMikeCharlie on March 30, 2016, 08:10:16 PM
I'm not sure if CR/LFs are valid within XML elements. However, I have found an example of one in the new XML EPG data that was not present in the old XML EPG data.
In the old XML data, the CR/LF was converted to a space. In the new XML data the CR/LF was preserved and caused the element to be split over 2 lines.
I'm note sure if this is legal or not, simply different.
A CR/LF is valid within XML elements. Any xml parser should normalise line breaks into a space (0x20). Unless they were in the xml file as in which case the parser would show it as line break.
I have noticed that when I list my devices, I can see my "older" PIMP interface devices that were created via the IceTV web site as well as the newly created API devices.
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE devices SYSTEM "http://iceguide.icetv.com.au/iceguide/devices.dtd">
<devices>
<type id="11" manufacturer_id="7" manufacturer_name="Topfield" manufacturer_url="" model="TRF-2400" notes="Topfield TRF-2400" />
<type id="18" manufacturer_id="7" manufacturer_name="Topfield" manufacturer_url="" model="TRF-2460" notes="Topfield TRF-2460" />
<device id="111" uid="" label="PIMP1" type_id="18" />
<device id="222" uid="" label="PIMP2" type_id="11" />
<device id="333" uid="11:22:33:44:55:66" label="API1" type_id="11" />
</devices>
I would like to be able to logon to one of the existing PIMP interface devices, but I receive an error because there is no uid field set for these devices.
<login>
<member email_address="me@here.com.au" password="TopSecret" region_id="1" />
<device id="222" uid="" label="PIMP2" type_id="11" />
</login>
Response
<?xml version="1.0"?>
<errors>
<error error_code="13" error_msg="Device details are required for recording app" />
</errors>
However, when I look at the IceTV web portal, a new API login token has been issued and when I use that token for my request, I receive data associated with the PIMP device.
The login has actually worked, however, the new API has not recognised it as such.
I have tried to allocate a new uid during login, but a new API device is created with the same name as my PIMP device but a different device id.
<login>
<member email_address="me@here.com.au" password="TopSecret" region_id="1" />
<device id="222" uid="NEW_UID" label="PIMP2" type_id="11" />
</login>
Is there a way to either:
1) Allow the new API to return the login token for a PIMP devices?
or
2) Allocate devices without a uid (older PIMP devices) a uid, either via the new API interface for automatically by IceTV?
or
3) Obtain a list of current tokens and devices that were used to obtain those tokens?
or
4) Login using the device id instead of the uid?
My plan is to write a TAP to replace the existing Topfield IceTV interface. It would be nice for users to be able to simply login as their existing device and automatically get all of their searches, series, etc. I know that I can extract these details from these older devices using the new API and then copy them to the new device, but that just seems sloppy.
Quote from: prl on March 17, 2016, 01:16:04 PM
I've just had a quick look at it, and there were errors in the first two entries in "shows" that I looked at.
... the documentation for "credits" says that "director" and "actor" are string elements of "credits". That's simply not what the "credits" structure looks like:
"credits": {"director": "Johnnie To","actors": [{"name": "Simon Yam"},{"name": "Kelly Lin"},{"name": "Ka Tung Lam"}]}
There is no "actor" element at all, and "actors" is an array of "name" elements.
It's really a bit disappointing. I hope that protocol descriptions (which I haven't had a proper look at) are better.
The documentation for credits is still wrong for the JSON data. The documentation says that the "actors" field is called "actor", and that it's an array of strings, when it's in fact an array of JSON objects (as quoted above).
As part of an attempt to deal with a number of bugs in the Beyonwiz IceTV plugin, I've tried changing the plugin to follow the Timer Workflow (http://developer.icetv.com.au/Timer_Workflow.html).
However, if the only action I do on creating a timer on the PVR side is to set the IceTV JSON timer "state" field to "pending" and the timer "message" field to "Added", and send the timer back with "PUT /shows/timers", the response to that request a copy of the timers list I sent, but the timer remains as "queued" on the IceTV server side.
Do I need to remove the "action" field from the timer before sending it back?
Here's an example of the response to when I send an updated timer back to the server:
Quote[IceTV] putTimers result -- [{u'show_id': u'125548348', u'name': u'Australian Story', u'start_time': u'2016-05-02T10:00:00+00:00', u'state': u'pending', u'channel_id': u'57', u'duration_minutes': u'30', u'action': u'record', u'keyword_id': u'0', u'message': u'Added', u'id': u'1462178866', u'series_recording_id': u'11608510', u'device_id': u'164966'}] --
The Python array is the Python mapping of the JSON send back.
Quote from: prl on May 02, 2016, 03:43:04 PM
Quote from: prl on March 17, 2016, 01:16:04 PM
I've just had a quick look at it, and there were errors in the first two entries in "shows" that I looked at.
... the documentation for "credits" says that "director" and "actor" are string elements of "credits". That's simply not what the "credits" structure looks like:
"credits": {"director": "Johnnie To","actors": [{"name": "Simon Yam"},{"name": "Kelly Lin"},{"name": "Ka Tung Lam"}]}
There is no "actor" element at all, and "actors" is an array of "name" elements.
It's really a bit disappointing. I hope that protocol descriptions (which I haven't had a proper look at) are better.
The documentation for credits is still wrong for the JSON data. The documentation says that the "actors" field is called "actor", and that it's an array of strings, when it's in fact an array of JSON objects (as quoted above).
Documentation has been updated.
Thanks, Daniel.
Are you able to help with my other question, about what the role is of "completed" and "pending" responses to a timers request?
I'm happy to re-ask on the developers' email address, but I thought the answer might be useful to other people looking at the documentation.
I think I can fix the bugs in the Beyonwiz IceTV plugin without an answer, but an answer might help make the plugin a bit cleaner.
Quote from: prl on May 10, 2016, 03:28:57 PM
Thanks, Daniel.
Are you able to help with my other question, about what the role is of "completed" and "pending" responses to a timers request?
I'm happy to re-ask on the developers' email address, but I thought the answer might be useful to other people looking at the documentation.
I think I can fix the bugs in the Beyonwiz IceTV plugin without an answer, but an answer might help make the plugin a bit cleaner.
Yeah, I am looking into that today, along with the login for an existing device from DMC.
Thanks.
Quote from: prl on May 10, 2016, 04:28:34 PM
Thanks.
This one didn't get finished today, will have an update for you tomorrow.
OK, thanks. I can put some instances of the problem into my IceTV logs, if that helps.
Quote from: prl on May 11, 2016, 11:11:29 AM
OK, thanks. I can put some instances of the problem into my IceTV logs, if that helps.
It would actually, and let me know the timer id's to make then easier to find. :D
Hi, Daniel.
Here is some more detailed information for this case. It's for three single recordings on my "Beyonwiz T3" device at 20:30 on Food Network, NITV and SBS. The timers were the only timers set on the device.
The result is that all three recordings were set on the Beyonwiz, but only the recordings for Real Pasifik and Cutthroat Kitchen changed from "Queued Single Recording" to "Single Recording". 24 Hours In Emergency remained as "Queued Single Recording".
This appears to mean that this method of acknowledging adding timers works the same as the current Beyonwiz distributed IceTV plugin, which also seems to miss changing the state of the timer on the server side for one a batch of the timers sent to the Beyonwiz in these circumstances.
I'd meant to ask about the timer missing out on being updated on the IceTV side in the distributed plugin when this issue had been clarified, but it seems that the two issues may be the same, or at least related.
Summary (title, description, IceTV timer id):
24 Hours In Emergency, Series 7, Episode 1, 1462946761
Real Pasifik, Tonga, 1462946746
Cutthroat Kitchen, I Crisped A Grill And I Liked It, 1462946735
Response from IceTV server (reformatted for clarity):
[
{
u'show_id': u'125677790', u'name': u'24 Hours In Emergency',
u'start_time': u'2016-05-11T10:30:00+00:00', u'state': u'pending',
u'channel_id': u'59', u'duration_minutes': u'60', u'action': u'record',
u'keyword_id': u'0', u'message': u'Added', u'id': u'1462946761',
u'series_recording_id': u'11635720', u'device_id': u'164966'
},
{
u'show_id': u'125682953', u'name': u'Real Pasifik',
u'start_time': u'2016-05-11T10:30:00+00:00', u'state': u'pending',
u'channel_id': u'2542', u'duration_minutes': u'30', u'action': u'record',
u'keyword_id': u'0', u'message': u'Added', u'id': u'1462946746',
u'series_recording_id': u'11635718', u'device_id': u'164966'},
{
u'show_id': u'125681970', u'name': u'Cutthroat Kitchen',
u'start_time': u'2016-05-11T10:30:00+00:00', u'state': u'pending',
u'channel_id': u'2573', u'duration_minutes': u'55', u'action': u'record',
u'keyword_id': u'0', u'message': u'Added', u'id': u'1462946735',
u'series_recording_id': u'11635715', u'device_id': u'164966'
}
]
Beyonwiz timers (also reformatted for clarity):
<?xml version="1.0" ?>
<timers>
<timer begin="1462962480" end="1462967400"
serviceref="1:0:1:351:350:3202:EEEE0000:0:0:0:" repeated="0" rename_repeat="1"
name="24 Hours In Emergency" description="Series 7, Episode 1" afterevent="auto"
eit="62532" tags="" disabled="0" justplay="0" always_zap="0" descramble="1"
record_ecm="0" isAutoTimer="0" ice_timer_id="1462946761"
>
</timer>
<timer begin="1462962480" end="1462965600"
serviceref="1:0:1:354:350:3202:EEEE0000:0:0:0:" repeated="0" rename_repeat="1"
name="Real Pasifik" description="Tonga" afterevent="auto"
eit="2168" tags="" disabled="0" justplay="0" always_zap="0" descramble="1"
record_ecm="0" isAutoTimer="0" ice_timer_id="1462946746"
>
</timer>
<timer begin="1462962480" end="1462967100"
serviceref="1:0:1:353:350:3202:EEEE0000:0:0:0:" repeated="0" rename_repeat="1"
name="Cutthroat Kitchen" description="I Crisped A Grill And I Liked It" afterevent="auto"
eit="1185" tags="" disabled="0" justplay="0" always_zap="0" descramble="1"
record_ecm="0" isAutoTimer="0" ice_timer_id="1462946735"
>
</timer>
</timers>
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.
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.
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.
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>
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.
I can give you the version of the plugin I'm using if that helps.
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.
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.
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.
The documentation pages don't seem to be playing nice. When I try to access http://developer.icetv.com.au/Home.html (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=
:(
Try it without the Home.html.
Thanks. That works. It loohs lik a new setup.
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. (http://beyonwiz.com.au/forum/viewtopic.php?f=55&t=11062)
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.
Bump...