XMLTV / xmltv

Utilities to obtain, generate, and post-process TV listings data in XMLTV format
GNU General Public License v2.0
275 stars 93 forks source link

XMLTV V1.0.0 tv_grab_zz_sdjson fails #132

Closed DaveCantor closed 2 years ago

DaveCantor commented 3 years ago

New XMLTV.exe v1.0.0 failed

Two day ago, because of some lineup errors, I upgraded from XMLTV v0.5.70 to v1.0.0, and it seemed to work.

Today, I noticed that my software did not mark any of the programs on today as "New". By examining the output of v1.0.0 compared to the output of v0.5.70, I discovered that there was missing data in the new version. These were missing:

<previously-shown start="20210221" />
<new />

There may be other missing things, but these were the ones that screwed up my program. I'm running on Windows 10 and I'm using lineups: channels=USA-OTA-02571 channels=USA-FUBOTV-DEFAULT with tv_grab_zz_sdjson.conf

I have now switch back to version 0.5.70 and things are back to normal.

This happens for me and for the person who wrote the software that I'm using.

garybuhrmaster commented 3 years ago

In commit d5877709e410abaec0bbb8a2ea963ae4f69284ca an error in the XMLTV DTD interpretation for the tv_grab_zz_sdjson grabber was corrected IRT the "new" flag (it was doing the wrong thing). Applications that are trying to determine "new" need to be updated to properly calculate/determine what "new" means to them (some apps have always calculated "new" by other means for years, and some others were just doing the wrong thing and getting lucky).

garybuhrmaster commented 3 years ago

btw, if the app is tvheadend, a previous discussion in another grabber at https://github.com/garybuhrmaster/tv_grab_zz_sdjson_sqlite/issues/10 provided a proposed patch for tvheadend to provide a method to calculate a "new" for that app similar to what some other apps had been doing. I have no idea if the OP took the proposal, validated it, and pushed it upstream to the tvheadend developers, or whether the OP is carrying the patch(es) locally.

rmeden commented 3 years ago

All expand on Gary's explanation a bit.

Per the XMLTV specification,  "New" is a brand new program.  Not a new episode or even a new season.  In the U.S., we typically call that a "Premier".

For new episodes the tag should not exist. If it does, the date it was previously shown is used.

When I wrote "TV_CHECK", I treat programs with without a

tag or a value of less than a week as a new episode.  As I'm used to Schedules Direct data, I also look at the  tag and treat SH* values as repeats.... that means Gracenote (the data source) doesn't know the episode details.. that typically means a repeat.
garybuhrmaster commented 3 years ago

As I'm used to Schedules Direct data, I also look at the  tag and treat SH* values as repeats.... that means Gracenote (the data source) doesn't know the episode details.. that typically means a repeat.

Although, as it turns out, there are known cases (PTI on ESPN (which came up in a different forum)) where Gracenote uses a SH* value for every showing (the new ones every day, and even the repeated ones later in the evening), so one needs to just record all those shows without any repeat checks. Every heuristic tends to need the ability to override for the special cases.

rmeden commented 3 years ago

On 5/23/2021 11:31 AM, Gary Buhrmaster wrote:

As I'm used to Schedules Direct data, I also look at the  tag and
treat SH* values as repeats.... that means Gracenote (the data
source) doesn't know the episode details.. that typically means a
repeat.

Although, as it turns out, there are known cases (PTI on ESPN (which came up in a different forum)) where Gracenote uses a SH* value for every showing (the new ones every day, and even the repeated ones later in the evening), so one needs to just record all those shows without any repeat checks. Every heuristic tends to need the ability to override for the special cases.

Daily news shows are also a common case where Gracenote doesn't offer a unique episode-id.   Basically they use SH* when they don't know any better.

Robert

garybuhrmaster commented 2 years ago

Closing this issue as the grabber is working properly per the DTD.