Author Topic: IceTV API documentation  (Read 18147 times)

Offline DeltaMikeCharlie

  • Full Member
  • ***
  • Posts: 57
    • View Profile
Re: IceTV API documentation
« Reply #15 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?

Offline Dave at IceTV

  • Guru
  • *****
  • Posts: 1258
    • View Profile
    • IceTV Knowledgebase Articles
Re: IceTV API documentation
« Reply #16 on: March 29, 2016, 04:20:08 PM »
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).
« Last Edit: March 29, 2016, 04:33:54 PM by Daniel Hall at IceTV »
cheers

Dave
Customer Service

Offline DeltaMikeCharlie

  • Full Member
  • ***
  • Posts: 57
    • View Profile
Re: IceTV API documentation
« Reply #17 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.

Offline Dave at IceTV

  • Guru
  • *****
  • Posts: 1258
    • View Profile
    • IceTV Knowledgebase Articles
Re: IceTV API documentation
« Reply #18 on: March 30, 2016, 08:40:37 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.

Offline DeltaMikeCharlie

  • Full Member
  • ***
  • Posts: 57
    • View Profile
Re: IceTV API documentation
« Reply #19 on: May 01, 2016, 02:11:00 PM »
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.

Code: [Select]
<?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.

Code: [Select]
<login>
<member email_address="me@here.com.au" password="TopSecret" region_id="1" />
<device id="222" uid="" label="PIMP2" type_id="11" />
</login>
Response
Code: [Select]
<?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.

Code: [Select]
<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.

Offline prl

  • Guru
  • *****
  • Posts: 3206
    • View Profile
Re: IceTV API documentation
« Reply #20 on: May 02, 2016, 03:43: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).
« Last Edit: May 03, 2016, 11:09:45 AM by prl »
Peter
Beyonwiz T4 in-use
Beyonwiz T2, T3 & T4 for testing

Offline prl

  • Guru
  • *****
  • Posts: 3206
    • View Profile
Re: IceTV API documentation
« Reply #21 on: May 02, 2016, 06:53:25 PM »
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.

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.

Offline Daniel Hall at IceTV

  • Administrator
  • Guru
  • *****
  • Posts: 1233
    • View Profile
    • IceTV
Re: IceTV API documentation
« Reply #22 on: May 10, 2016, 02:33:02 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.
Regards,

Daniel.
CTO.

Offline prl

  • Guru
  • *****
  • Posts: 3206
    • View Profile
Re: IceTV API documentation
« Reply #23 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.

Offline Daniel Hall at IceTV

  • Administrator
  • Guru
  • *****
  • Posts: 1233
    • View Profile
    • IceTV
Re: IceTV API documentation
« Reply #24 on: May 10, 2016, 03:42:40 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.

Offline prl

  • Guru
  • *****
  • Posts: 3206
    • View Profile
Re: IceTV API documentation
« Reply #25 on: May 10, 2016, 04:28:34 PM »
Thanks.

Offline Daniel Hall at IceTV

  • Administrator
  • Guru
  • *****
  • Posts: 1233
    • View Profile
    • IceTV
Re: IceTV API documentation
« Reply #26 on: May 10, 2016, 08:57:41 PM »
Thanks.

This one didn't get finished today, will have an update for you tomorrow.

Offline prl

  • Guru
  • *****
  • Posts: 3206
    • View Profile
Re: IceTV API documentation
« Reply #27 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.

Offline Daniel Hall at IceTV

  • Administrator
  • Guru
  • *****
  • Posts: 1233
    • View Profile
    • IceTV
Re: IceTV API documentation
« Reply #28 on: May 11, 2016, 11:33:11 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

Offline prl

  • Guru
  • *****
  • Posts: 3206
    • View Profile
Re: IceTV API documentation
« Reply #29 on: May 11, 2016, 04:32:55 PM »
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):
Code: [Select]
[
  {
    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):
Code: [Select]
<?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>
« Last Edit: May 11, 2016, 04:34:44 PM by prl »


Share via facebook Share via twitter

xx
Is IceTV a 7 day EPG, or 5 day EPG ?

Started by chopper on IceTV EPG Content

7 Replies
190 Views
Last post October 17, 2019, 07:43:57 PM
by chopper
xx
Common setup pitfalls using IceTV with Plex

Started by Daniel Hall at IceTV on Plex

0 Replies
224 Views
Last post July 01, 2019, 05:33:55 PM
by Daniel Hall at IceTV
xx
Setup IceTV on Plex server on Qnap TS 251+ with HDHomerun Connect

Started by Iceplex on Plex

27 Replies
913 Views
Last post July 22, 2019, 07:10:01 PM
by MD
xx
Full IceTV Subscription vs Plex Subscription

Started by Peter_H on Plex

8 Replies
444 Views
Last post July 16, 2019, 02:45:11 PM
by Daniel Hall at IceTV