Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - DeltaMikeCharlie

Pages: [1]
General Discussions / Some Improper Character Encoding
« on: March 23, 2021, 03:34:28 PM »
I've found that both my PVR (JSON feed) and your web site show what appears to be invalid characters, for example:

Your web site EPG shows:

Setsuko, a 55-year-old single office lady in Tokyo

These appear to be Unicode characters that have had their UTF-8 encoding expanded unnecessarily.

‘ in hex is E2 80 98 which is the Unicode codepoint 'LEFT SINGLE QUOTATION MARK' (U+2018) in UTF-8
Likewise, ’ is E2 80 99 which represents codepoint 'RIGHT SINGLE QUOTATION MARK' (U+2019)

There may be more, but these are the ones that I have noticed.  A search for "" on the web site should find them.  I have seen them in both the title and description.

The JSON feed is slightly worse:

Setsuko, a 55-year-old single ‘office lady’ in Tokyo

‘ = C3 A2 E2 82 AC CB 9C

’ = C3 A2 E2 82 AC E2 84 A2

It appears to have been encoded as UTF-8 twice.

From what I've read online, this seems to be a common issue regarding incorrectly interpreting encoding schemes.

Perhaps ICE is receiving these characters pre-corrupted from an upstream source or they are incorrectly encoding them for web or JSON presentation.

Perhaps ICE TV could search for these characters and replace them with their originally intended UTF8 equivalents prior to making that data available on their platform.  As these particular strings of characters are nonsensical, inadvertently changing the intended meaning would be a fairly low risk.

IceTV EPG Content / Frasier actor credit
« on: October 17, 2020, 09:11:26 AM »
In Frasier, it appears that "John Mahoney" is being credited as "Joh Mahoney".

XMLTV (General) / Timer status not updating
« on: June 16, 2018, 10:47:30 AM »
I'm not sure if I am doing something wrong, or if there is a bug in the API.

When I receive a new timer from ICE with a "waiting" status, I create the timer on the PVR and then send back a status update to "pending".  However, this status is not always reflected on the ICE portal.  Normally, the timer icon on the portal will change from "Queued Single Recording" to "Single Recording" when the "pending" status is returned.

It seemed to happen more prominently for the last timer in a group of timers.  However, I just did a quick test as I was preparing for this post and I found that it seems to always be the last timer that is not correctly updated, regardless of how many were processed.

As a test:  I started with 2 groups of 3 timers.  In the first group, all 3 timers showed as "Single Recording", however, in the second group, only the first 2 showed as "Single Recording" and the third showed as "Queued Single Recording".  The timers were in this state for several polling cycles and in my log file I could see ICE continuously sending "waiting" messages for the "Queued Single Recording" timer, even though I was continuously sending "pending" responses.

I then created another single timer and then the last timer of the second group suddenly became a "Single Recording" and now the new single timer appears to be stuck on "Queued Single Recording".

Has any one else encountered this issue?

Also, this only seems to happen with timers sent from ICE.  If I create a timer on the PVR and then send it to ICE, the ICE portal immediately shows the timer as "Single Recording" but leaves the previous "Queued Single Recording" still in its "waiting" state.

Perhaps a workaround would be to never accept an ICE timer.  Always send a deletion request back to ICE for timers created by the portal, but then create a manual timer on the PVR for the same event and post that manual timer to ICE as a new timer.

XMLTV (General) / Phantom Timer
« on: April 10, 2018, 11:53:09 AM »
I seem to have received a phantom timer:

<timer id="16386666313566939991" name="NCIS: Los Angeles" device_id="nnnnnn" channel_id="5" show_id="138115637" start_time="2018-04-10T11:40:00+00:00" duration_minutes="55" action="record" state="pending" message="Updated by Scheduler SERIES" series_recording_id="0" keyword_id="0" pre-padding="-1" post-padding="-1" padding-type="" />

I have looked on my web interface and I can see no matching "My Series" entry.  The only entry that I see matches the entry that the API returns.

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE keyword SYSTEM "">
 <keyword id="143114" match_pattern="episode:&quot;testselection&quot; " type="Record" device_id="nnnnnn" device_label="PVR-Name" network_id="-1" channel_id="-1" recording_quality="Prefer HD" matches_per_day="0" airing="First runs and re-runs" marked_for_deletion="0" />

I also looked in '/series/favourites' and also found nothing.

I created a test search containing "NCIS" some time ago, but is has been deleted for quite a few days.

Am I doing something wrong, or is there a problem on ICE's side?

XMLTV (General) / XMLTV vs ICETV Products
« on: April 05, 2018, 04:17:25 PM »
On the web site, there are 2 subscription types described: "ICETV" and "XMLTV".  It's clear that XMLTV excludes the "full service" features of the more expensive ICETV service.  Using the ICETV service, I have been able to obtain data formatted in both XML and JSON.

Can you please confirm if the "XMLTV" service restricted to XML-formatted data, or if JSON-formatted data is also available?

XMLTV (General) / Rename Device XML vs JSON
« on: March 23, 2018, 12:00:40 PM »
When I make the following XML request, it is successful:

Code: [Select]
<device uid="aa:bb:cc:dd:ee:ff" label="NewName" type_id="33" />

However, when I make what appears to be an equivalent JSON request, it returns a http status of 200, but the device is not modified:

Code: [Select]
"devices": [{
"uid": " aa:bb:cc:dd:ee:ff ",
"label": "NewName",
"type_id": "33"

I have tried including the "types" object and/or the id property as per the sample documentation, but that makes no difference.

Even though the documentation says to use a POST, that always returns a "405 - Method not allowed" but a PUT returns a 200.  The XML version also needs a PUT, not a POST.

I was converting my app from XML to JSON, but I guess that I will keep this call using XML.

XMLTV (General) / Timer creation question.
« on: March 12, 2018, 10:53:23 AM »
I would like to know what ICE's recommended practice is when a timer is scheduled for a channel that has multiple LCNs associated.

For example, in Sydney, "ABC" is available on 2 LCNs: 2 and 21.

<channel id="2" name="ABC" name_short="ABC" network_id="2" region_id="1" is_hd="0" lcns="2,21" region_name="NSW - Sydney" network_name="ABC" is_hidden="0" icon_src="" icon_width="0" icon_height="0">
  <dvb original_network_id="4112" transport_stream_id="545" service_id="545" />
  <dvb original_network_id="4112" transport_stream_id="545" service_id="547" />


When a timer is created for "channel id=2", it theoretically should spawn 2 timers, one for each of the LCNs.

<timer id="1234567890" name="Grand Designs" device_id="1234" channel_id="2" show_id="137486682" start_time="2018-03-12T00:00:00+00:00" duration_minutes="60" action="record" state="waiting" message="Created with Interactive web interface." series_recording_id="0" keyword_id="0" pre-padding="-1" post-padding="-1" padding-type="" />

I know that I could: 1) ask the user to designate a preferred LCN; or 2) arbitrarily pick one, I'd just like to know what ICE would expect to happen.

XMLTV (General) / Strange JSON escape characters in EPG data.
« on: February 19, 2018, 05:12:14 PM »
I have noticed a difference in the "show" description text depending on if the selected format is JSON or XML.

Here is an XML example.  Note the quotes around the first line of the description.

  <desc lang="en">I wanted to know what their plan was. I was their plan!

The Doctor has been summoned by an old friend, but in the Cabinet War Rooms far below the streets of blitz-torn London, it's his oldest enemy he finds waiting for him...

The Daleks are back - but can Winston Churchill be in league with them? </desc>

However, the JSON version has a series of escape characters that do not appear to correspond to the character shown in the XML version.

    "desc": "\u00E2\u0080\u009CI wanted to know what their plan was. I was their plan!\u00E2\u0080\u009D\r\n\r\nThe Doctor has been summoned by an old friend, but in the Cabinet War Rooms far below the streets of blitz-torn London, it's his oldest enemy he finds waiting for him...\r\n\r\nThe Daleks are back - but can Winston Churchill be in league with them? ",

"\u00E2\u0080\u009C" actually appears to be the UTF-8 representation of "LEFT DOUBLE QUOTATION MARK " character which is "0x201C" in hex.

I have encountered a number of web sites suggesting that the correct JSON encoding should actually be "\u201C".

I have also seen this occur with "\u00E2\u0080\u009D" (right double quote "\u201D") and "\u00E2\u0080\u0093" (en dash "\u2013").  Perhaps there are others.

I'm happy to be proven wrong, but I thought that files containing JSON were already supposed to be in Unicode and that only reserved characters (such as quotes, commas, etc) needed to be escaped.

It appears that the process that is creating the JSON output is reading the source as ASCII text and not UTF-8 text and converting each byte of the Unicode string individually and not as a combined entity.

I am using cURL with [--header "Accept: application/json"].  I was willing to concede that perhaps cURL is mangling the data on the way in, however, the trace file shows the data arriving pre-mangled.

Is there something wrong with my request or is the server genuinely serving up these seemingly erroneously escaped characters?

XMLTV (General) / New XML Protocol & Channel Data Inconsistencies
« on: February 19, 2018, 02:30:48 PM »
I have observed an inconsistency between the channel data returned from a "regions/x/channels" request and a "shows" request.

Using "9Go!" in Sydney as an example, the channel data from the "region" contains 2 separate LCNs and 2 separate sets of DVB triplets.

<?xml version="1.0"?>
<regions page="1" rows_per_page="25" total_rows="25">
 <region id="1" name="NSW - Sydney" city="Sydney" state="New South Wales" country="Australia" timezone="Australia/Sydney" />
<channel id="2393" name="9Go!" name_short="9Go!" network_id="6" region_id="1" is_hd="0" lcns="93,99" region_name="NSW - Sydney" network_name="Nine" is_hidden="0" icon_src="" icon_width="0" icon_height="0">
  <dvb original_network_id="4114" transport_stream_id="1056" service_id="1059" />
  <dvb original_network_id="4114" transport_stream_id="1056" service_id="1064" />

However, the channel data that precedes a listing of "shows" contains only a single LCN and 2 duplicated DVB triplets.

<shows page="1" rows_per_page="4214" total_rows="4214" last_update_time="1459048773">
<channel id="2393">
  <display-name lang="en">9Go!</display-name>
  <dvb original_network_id="4114" transport_stream_id="1056" service_id="1059" />
  <dvb original_network_id="4114" transport_stream_id="1056" service_id="1059" />

  <icon src="" width="0" height="0" />
<show id="125015052" series_id="40967" episode_id="0" start="2016-03-26T11:30:00+00:00" stop="2016-03-26T13:55:00+00:00" channel_id="2620" part_of_series="false">

This also occurs with "ONE", "9 Sydney" and "ABC" in Sydney.

Strangely, the duplicated triplets issue does not occur with the "shows" when using JSON, but the second LCN is still missing.

    "id": "2393",
    "name": "9Go!",
    "url": "",
    "lcn": "99",
    "dvb_triplets": [
        "original_network_id": "4114",
        "transport_stream_id": "1056",
        "service_id": "1059",
        "lcn": "99",
        "frequency": "0"
    "icon": {
      "src": "",
      "width": "0",
      "height": "0"

JSON formatted data for "/regions/x/channels" is also fine.

Also, some channels provided in the "shows" response contain duplicated DVB triplets as well as triplets that are not mentioned in the "regions/x/channels" response.

<channel id="100" name="ABC NEWS" name_short="ABC NEWS" network_id="2" region_id="1" is_hd="0" lcns="24" region_name="NSW - Sydney" network_name="ABC" is_hidden="0" icon_src="" icon_width="0" icon_height="0">
  <dvb original_network_id="4112" transport_stream_id="545" service_id="544" />

<channel id="100">
  <display-name lang="en">ABC News 24</display-name>
  <dvb original_network_id="4112" transport_stream_id="529" service_id="528" />
  <dvb original_network_id="4112" transport_stream_id="561" service_id="560" />
  <dvb original_network_id="4112" transport_stream_id="547" service_id="672" />
  <dvb original_network_id="4112" transport_stream_id="545" service_id="544" />
  <dvb original_network_id="4112" transport_stream_id="625" service_id="624" />
  <dvb original_network_id="4112" transport_stream_id="627" service_id="656" />
  <dvb original_network_id="4112" transport_stream_id="563" service_id="688" />
  <dvb original_network_id="4112" transport_stream_id="545" service_id="544" />
  <icon src="" width="0" height="0" />

I'm assuming that "regions/x/channels" is the authoritative data set and that the channels data in "shows" should be discarded.

IceTV EPG Content / The Mysteries Of Laura - Sydney
« on: July 28, 2015, 10:01:03 AM »
When does this show start?

ICE currently has 20:45 whereas the FTA EPG has 20:40.  It seems that ICE has "The Hotplate" running for 01:15 and FTA has 01:10.  This seems to have shoved everything over 5 minutes until "Weeds".

XMLTV (General) / New XML API
« on: June 12, 2015, 06:37:58 AM »
Some time ago, I was told by an IceTV staff member that a new XML API was being developed.

Is this still happening?

Is there a target date for when this API will be available to developers?

I would like to write a TAP to add ICE functionality to my non-ICE Topfield PVR.

XMLTV (General) / XML API Capabilities
« on: November 21, 2014, 10:34:39 AM »
I'm currently researching the capabilities of the ICE XML feed with the intent of writing a TAP to add ICE EPG capabilities to non-ICE Topfield PVRs.  I have looked at the XML EPG format and that appears to be relatively straight forward.

Does the XML API have the capability to exchange information about scheduled recordings?  Either shows that the PVR has scheduled to record or shows that have been selected to be recorded from the ICE web site / app / etc.

General Discussions / Feature Request - Customised Repeat Flag
« on: September 28, 2012, 07:25:01 AM »
I have a PVR that either does not receive or does not display the repeat status of EPG events obtained via ICE TV.  I realise that technically this is an issue for the manufacturer and should be resolved with a firmware upgrade, but I have an alternate solution that may also benefit other users.

In the same way that each individual user can customise their EPG feed by selecting the timezone, region, LCN map, etc, would it be possible to add a new "repeat status display" configuration option?

There are three free-text fields provided with each EPG event, namely: "Title", "Sub-Title" and "Description" (according to the XML schema).  Would it be possible to customise one or more of these fields to show the repeat status?

As various PVRs and HTPCs would have various layouts and formats of displaying these three fields, any method of adding a repeat flag should be flexible enough to suit any permutation of EPG display layout.

I would like to propose that ICE TV provide each user, on a user-by-user basis, the option to add a customisable field, to either the beginning or end of any of these three fields.

The customised field could contain "Repeat" or "(R)" or "Rpt", this would be left to the user's discretion for what suits their situation best depending upon available screen real-estate.  (To reduce liability, ICE TV may consider a profanity filter.)

Likewise, the location of the field could be changed depending upon the layout of the EPG presented by their system.  For example, some people may choose to add the string "(R)" to the end of the "Title" so that it is easily and quickly visible, whereas others may choose to add "Repeat - " to the beginning of the "Sub-Title" field.

The modified field(s) would be sent to the PVR and as they are free-text fields, the PCR would simply process them as such.

Although the primary goal is to add the repeat status, this scheme could be expanded to add the production date of the event, the actors or director, etc.  One would have to be mindful of how much space is available in the three free-text fields mentioned and perhaps such "extended information" could only be added to the end of the full description as a precaution.

Pages: [1]