For The Record - The rule-based scheduling suite (4 Viewers)

[dvdfreak]

Actually, if this is a common problem I can make "the new TV Scheduler" handle this situation automatically. If I understand correctly, this is what you did: if the previously-shown date matches the date of the program itself you remove the previously-shown tag, right?

So what I could change is that in this case I do not mark the program as being a repeat, only when the previously-shown date is in the past...

 

[mrbenji]

It's slightly more complicated than that. For whatever reason, most of my first-run programs have a "previously-shown" date that's about a day and 3 hours earlier than the actual run time (time zone issue?). Not even the 1 day 3hr difference is a constant, however... sometimes it's 1 day 4hrs earlier, and a few programs are a full 1 day, 23hrs earlier! I'm on Pacific Standard Time, btw.

Also, sometimes the "previously-shown" date is *in* the previously-shown tag, like:
<previously-shown start="20080207000000" />)

Other times the previously-shown tag is reduced to "<previously-shown />" and there's a <date></date> tag with the earlier runtime in it, minus the 6 trailing zeros. So my script checks for a full date in either place ("full date" because for movies the <date> tag often just has the release year of the movie in it), and removes any existing previously-shown tag if the broadcast date is 1 day, 23hrs after the "previously shown" date or closer.

Hope that was clear... and hopefully my code's legible enough to explain better!

 

[mrbenji]

Here's part of my original XMLTV output file, downloaded using the tv_grab_na_dd grabber.

 

[dvdfreak]

Hope that was clear... and hopefully my code's legible enough to explain better!

Perfectly clear!

But what's also clear after your explanation is that this seems to be a very specific tweak to your XMLTV source, so it wouldn't make much sense to add it directly into my code.

 

[mrbenji]

...what's also clear after your explanation is that this seems to be a very specific tweak to your XMLTV source

If you mean that mine is a unique situation, I doubt it... this is the default output from XMLTV's Schedules Direct plugin, i.e. the #1 (I believe) TV grabbing tool's output from the best source of US TV listings. But maybe other users can weigh in on whether they have the same problem?

The only thing I suspect could be specific to my timezone is the permissible delta between the provided dates, but if that's the case then setting a delta of, say, 1 day, 7 hrs should work for 99% of the shows out there, for any user in any U.S. state. Hopefully some users in Hawaii or on the East Coast can confirm/disprove this theory?

, so it wouldn't make much sense to add it directly into my code.

Well, you definitely wouldn't want to add it in except as a non-default option with adjustable delta... but hopefully we can get the XMLTV developers to look into why this is happening in the first place, in which case changes to TvScheduler wouldn't be needed.

 

[dvdfreak]

...what's also clear after your explanation is that this seems to be a very specific tweak to your XMLTV source

If you mean that mine is a unique situation, I doubt it... this is the default output from XMLTV's Schedules Direct plugin, i.e. the #1 (I believe) TV grabbing tool's output from the best source of US TV listings. But maybe other users can weigh in on whether they have the same problem?

OK, interesting, so I should perhaps reconsider this and add it as a standard feature after all.

Well, you definitely wouldn't want to add it in except as a non-default option with adjustable delta... but hopefully we can get the XMLTV developers to look into why this is happening in the first place, in which case changes to TvScheduler wouldn't be needed.

I'm note so sure it shouldn't be the default. I hate it when programs have too many settings myself, so I try to avoid the situation of "a setting for this, a setting for that,..." as much as possible

Feedback from other users, especially about this strange time-offset, would be most interesting.

And also, has anyone mentioned this to the author of the Schedules Direct plugin? Could there be something he can do to improve this? The closer to the source you fix a problem, the better of course.

 

[sunsetdk]

I'm note so sure it shouldn't be the default. I hate it when programs have too many settings myself, so I try to avoid the situation of "a setting for this, a setting for that,..." as much as possible

Sorry for butting in. I do agree with you on the settings, but you could put those setting in an advanced tab/form/thing.

Just an idea

 

[mrbenji]

has anyone mentioned this to the author of the Schedules Direct plugin? Could there be something he can do to improve this? The closer to the source you fix a problem, the better of course.

Sure, I'll figure out the best way to contact the XMLTV developers and describe the issue. Maybe there's an easy fix from the XMLTV side of things.

 

[dvdfreak]

has anyone mentioned this to the author of the Schedules Direct plugin? Could there be something he can do to improve this? The closer to the source you fix a problem, the better of course.

Sure, I'll figure out the best way to contact the XMLTV developers and describe the issue. Maybe there's an easy fix from the XMLTV side of things.

Just to make sure I don't misunderstand: where does your actual XMLTV file come from? Is it written by the Schedules Direct plugin or not?

Because if that's the case there's no need to go and talk to the people behind the official XMLTV distribution, because all they did is define the spec. If's the Schedules Direct plugin that actually writes the data, things could possibly be fixed there. But the problem could very easily lie with the source of the data, the site where the Schedules Direct gets the data from...

 

[mrbenji]

Getting closer...

Just to make sure I don't misunderstand: where does your actual XMLTV file come from? Is it written by the Schedules Direct plugin or not?

Are you talking about the Mediaportal 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 (homepage here)... specifically by the tv_grab_na_dd grabber.

Because if that's the case there's no need to go and talk to the people behind the official XMLTV distribution, because all they did is define the spec.

Well, they defined the spec and developed the utility suite that creates and works with files in the XMLTV format.

...the problem could very easily lie with the source of the data, the site where the Schedules Direct gets the data from...

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 is 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) and 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: it seems the tv_grab_na_dd grabber doesn't see "new" 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. I've also posted to the XMLTV bug tracker for good measure.