Reply to thread

Message

<blockquote data-quote="mrbenji" data-source="post: 265494" data-attributes="member: 69110">Getting closer...Are you talking about the Mediaportal Schedules Direct plugin?&nbsp; If so the answer is no.&nbsp; That plugin doesn't generate an XML at all... it simply updates MediaPortal's EPG data directly.&nbsp; My XML file is generated by XMLTV's official utility suite (<a href="http://xmltv.org/wiki/" target="_blank">homepage here</a>)... specifically by the tv_grab_na_dd grabber.Well, they defined the spec and developed the utility suite that creates and works with files in the XMLTV format. This could very well be the case.&nbsp; I spent some time yesterday skimming the tv_grab_na_dd perl script (the actual code is in a file called tv_grab_na_dd.in).&nbsp; The logic seems simple enough: If there's no &quot;new&quot; data attribute it embeds the &quot;original air date&quot; attribute (plus 6 zeros) into a previously-shown tag and writes it to the XML.&nbsp; If there is a &quot;new&quot; attribute it doesn't write out a previously-shown tag.This does explain why the deltas varied by a few hours:&nbsp; the &quot;programme start&quot; value is in the format YYYYMMDDHHMMSS, while the embedded original air date is YYYYMMDD plus 6 added zeros for HHMMSS.&nbsp; &nbsp; Most of the first run shows I was looking at were Prime Time shows starting at 8:00 or 9:00, and (since I mistakedly considered hours &amp; minutes instead of just y/m/d) the delta was different for 8:00 shows vs. 9:00 shows.Another factor: my timezone was set for UTC, which is what XMLTV recommends. The XMLTV configuration script says: &quot;It is better to specify +0000 and let the final application deal with a local conversion (helps with DST issues), but you can specify a Time Offset if desired.&quot; However, if I manually specify my timezone as -0700 (Pacific Daylight Time) and ignore the hours &amp; minutes part of the embedded date, the delta is completely gone... i.e. the y/m/d part of the &quot;programme start&quot; tag matches the embedded &quot;original air date&quot;. So it seems I've boiled down the issue to one thing:&nbsp; it seems the tv_grab_na_dd grabber doesn't see &quot;new&quot; attributes for first run shows, so no matter what my timezone offset these shows always have previously-shown tags.My next stop is the Schedules Direct forum... hopefully they can determine whether my issue's caused by an error in the data they get from Tribune Media or an error in the way the XMLTV tv_grab_na_dd grabber queries or interprets that data.&nbsp; I've also posted to the XMLTV bug tracker for good measure.</blockquote>

[QUOTE="mrbenji, post: 265494, member: 69110"] [b]Getting closer...[/b] Are you talking about the [I]Mediaportal[/I] Schedules Direct plugin? If so the answer is no. That plugin doesn't generate an XML at all... it simply updates MediaPortal's EPG data directly. My XML file is generated by XMLTV's official utility suite ([URL="http://xmltv.org/wiki/"]homepage here[/URL])... specifically by the tv_grab_na_dd grabber. Well, they defined the spec [I]and [/I]developed the utility suite that creates and works with files in the XMLTV format. This could very well be the case. I spent some time yesterday skimming the tv_grab_na_dd perl script (the actual code is in a file called tv_grab_na_dd.in). The logic seems simple enough: If there's no "new" data attribute it embeds the "original air date" attribute (plus 6 zeros) into a previously-shown tag and writes it to the XML. If there [B]is[/B] a "new" attribute it doesn't write out a previously-shown tag. This does explain why the deltas varied by a few hours: the "programme start" value is in the format YYYYMMDDHHMMSS, while the embedded original air date is YYYYMMDD plus 6 added zeros for HHMMSS. Most of the first run shows I was looking at were Prime Time shows starting at 8:00 or 9:00, and (since I mistakedly considered hours & minutes instead of just y/m/d) the delta was different for 8:00 shows vs. 9:00 shows. Another factor: my timezone was set for UTC, which is what XMLTV recommends. The XMLTV configuration script says: "It is better to specify +0000 and let the final application deal with a local conversion (helps with DST issues), but you can specify a Time Offset if desired." However, if I manually specify my timezone as -0700 (Pacific Daylight Time) [B]and[/B] ignore the hours & minutes part of the embedded date, the delta is completely gone... i.e. the y/m/d part of the "programme start" tag matches the embedded "original air date". So it seems I've boiled down the issue to one thing: [B]it seems the tv_grab_na_dd grabber doesn't see "new" attributes for first run shows[/B], so no matter what my timezone offset these shows always have previously-shown tags. My next stop is the Schedules Direct forum... hopefully they can determine whether my issue's caused by an error in the data they get from Tribune Media or an error in the way the XMLTV tv_grab_na_dd grabber queries or interprets that data. I've also posted to the XMLTV bug tracker for good measure. [/QUOTE]

Verification