Recent Posts

Pages: [1] 2 3 ... 10
1
General Discussions / Show image rules?
« Last post by bowser on February 21, 2018, 02:42:47 PM »
Are there any rules for submitting images for shows? A lot of shows are missing one or have old ones. Do the images have to be ripped from a recording or can they be sourced from official promotional material or wikipedia galleries etc?
2
XMLTV (General) / Re: Strange JSON escape characters in EPG data.
« Last post by prl on February 20, 2018, 04:47:37 PM »
Thanks, Daniel.
3
XMLTV (General) / Re: Strange JSON escape characters in EPG data.
« Last post by Daniel Hall at IceTV on February 20, 2018, 03:16:58 PM »
This one is being looked into.
4
XMLTV (General) / Re: Strange JSON escape characters in EPG data.
« Last post by DeltaMikeCharlie on February 20, 2018, 06:13:42 AM »
I sent a long and detailed email about this and a related problem to Daniel Hall a few weeks ago. I haven't heard back.
Thanks prl.
5
XMLTV (General) / Re: New XML Protocol & Channel Data Inconsistencies
« Last post by DeltaMikeCharlie on February 20, 2018, 06:12:29 AM »
As a stab in the dark, I tried to explicitly request EPG data for a channel that was excluded in my preferences using the "&channel_id=xxxx" parameter in my request.  Unfortunately, I received an empty response.

<?xml version="1.0"?>
<shows page="1" rows_per_page="0" total_rows="0" last_update_time="1519067101" />


Would it be possible to add an "ignore_ch_prefs=1" (or similar) parameter to the EPG request?
6
XMLTV (General) / Re: Strange JSON escape characters in EPG data.
« Last post by prl on February 19, 2018, 09:44:12 PM »
I sent a long and detailed email about this and a related problem to Daniel Hall a few weeks ago. I haven't heard back.
7
XMLTV (General) / Strange JSON escape characters in EPG data.
« Last post by DeltaMikeCharlie 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.

--SNIP--
  <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>
  <credits>
--SNIP--

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

--SNIP--
    "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? ",
--SNIP--


"\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".

https://www.fileformat.info/info/unicode/char/201c/index.htm
http://graphemica.com/%E2%80%9C

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?
8
IceTV EPG Content / Re: Blue Bloods recording times an hour out
« Last post by JayseeandDali on February 19, 2018, 04:57:36 PM »
Wasn't the season 8 premiere ("Cutting Losses") on last Thursday week (the 8th)? The one they pulled on the 15th was episode 2 ("Ghosts of the Past"). This weeks episode (the 22nd) should be episode 3 ("The Enemy of My Enemy").

I've just check and you do have "The Enemy of My Enemy" scheduled for this Thursday.

ps - we noticed it had recorded This Is Us instead so just grabbed it from TenPlay.
9
XMLTV (General) / Re: New XML Protocol & Channel Data Inconsistencies
« Last post by DeltaMikeCharlie on February 19, 2018, 04:15:56 PM »
Thanks Daniel.  That makes perfect sense.

Is there any way to override the channels provided in the EPG data?

The channel filtering in preferences is global, that is, they apply to all of my devices.  Due to a buffer bug in the Topfield firmware, the number of channels needs to be restricted to avoid crashes.  However, other XML-based devices without firmware issues can safely process all of the EPG data.  The weakest device cripples all.
10
Talk about a blast from the past, but I have just tested this and it works fine.

Keyword favourites can be used on free accounts.
Pages: [1] 2 3 ... 10