Tvmaze lookup by timestamp failures #717
Comments
In tvmaze.py "lookup by timestamp", there is logic to consider it a match if the recording is a little bit early. This helps cases where you set up a rule to record, at say 9:00, and the broadcaster uses a slightly odd start time, like 9:05. The code set minTimeDelta to 60 minutes, which allowed such a match, even if the show started a full hour before the start time in the TvMaze database. This minTimeDelta value was way too big. For a 7pm show, it caused a false match to an 8pm show found in the TvMaze database. We need to use a smaller default value. Certainly less than 1 hour. Most TV episodes are either 30 minutes or 60 minutes, so we should set this value smaller than 30 minutes to avoid the same sort of problem with 30 minute shows. In this commit, minTimeDelta is now defaulted to 20 minutes. Refs: MythTV#717
From https://www.tvmaze.com/faq/15/episodes : To ensure that the episode airdates on TVmaze are in line with the dates used by TV guides and listings worldwide, episodes that start airing at or after midnight but before 5:00 are considered part of the previous day. This commit checks for a starting time prior to 5am. If found, the date of the previous day will be used when searching for episodes. Refs: MythTV#717
This update allows a user to specify a Rebroadcast
Delay for use in a "Lookup by Timestamp". It wasn't
clear if this should be done with an extra argument
or with an environmental variable, so both have
been implemented.
The user may add the number of minutes for the
Rebroadcast Delay as a third argument
tvmaze.py -N <title> <date time> <rbdelay>
or they may set an environmental variable.
MYTH_REBROADCAST_DELAY=60 tvmaze.py -N <title> <date time>
The delay is in minutes because in some locations,
there are some timezone offsets in 15 or 30 minute
increments. It's possible that there could be
Rebroadcast Delays with similar characteristics.
I'm not certain that Rebroadcast Delay is always a
positive number, so specification of a negative
number of minutes is supported.
Here are a couple of examples of specifying the Rebroadcast Delay:
$ TZ=America/Denver tvmaze.py -l en -a US -N "9-1-1: Lone Star" "2023-01-24 19:00:00" 60
<?xml version='1.0' encoding='UTF-8'?>
<metadata>
<item>
<title>9-1-1: Lone Star</title>
<subtitle>The New Hotness</subtitle>
<description>The 126 are called into action to a county fair when a fast-moving group of severe thunderstorms hit Austin, Texas; Owen's newfound passion for motorcycling puts him on a potentially dangerous path; Tommy meets an attractive single father.</description>
<season>4</season>
<episode>1</episode>
<inetref>42164</inetref>
...
MYTH_REBROADCAST_DELAY=180 TZ=America/Los_Angeles tvmaze.py -l en -a US -N "9-1-1: Lone Star" "2023-01-24 20:00:00"
<?xml version='1.0' encoding='UTF-8'?>
<metadata>
<item>
<title>9-1-1: Lone Star</title>
<subtitle>The New Hotness</subtitle>
<description>The 126 are called into action to a county fair when a fast-moving group of severe thunderstorms hit Austin, Texas; Owen's newfound passion for motorcycling puts him on a potentially dangerous path; Tommy meets an attractive single father.</description>
<season>4</season>
<episode>1</episode>
<inetref>42164</inetref>
...
Resolves: MythTV#717
|
Ad |
|
I thought about using an environmental variable to avoid changing the TV grabber API. I'm fine with removing that code, but it will introduce a new syntax: A future step will be to add a way for the user to specify their Rebroadcast Delay in the MythTv database. The code which calls the grabber script will be modified to add a 3rd argument to pass Rebroadcast Delay, when it is defined. Of the current TV grabber scripts, only one (tvmaze.py) will know how to handle this new argument. The other scripts will fail immediately, saying wrong number of arguments. Will it be okay to modify tmdb3tv.py and ttvdb4.py to allow, but ignore, this new argument? Alternatively, we can call the scripts with and without the rbdelay argument. If Rebroadcast Delay is defined, call -N with rbdelay. If that fails, call -N without rbdelay. That logic would work, but for tmdb3tv.py and ttvdb4.py users, it would add a new, always failing script invocation for every metadata lookup. |
This update allows a user to specify a Rebroadcast
Delay for use in a "Lookup by Timestamp".
The user may add the number of minutes for the
Rebroadcast Delay as a third argument for -N:
tvmaze.py -N <title> <date time> <rbdelay>
The delay is in minutes because in some locations,
there are some timezone offsets in 15 or 30 minute
increments. It's possible that there could be
Rebroadcast Delays with similar characteristics.
I'm not certain that Rebroadcast Delay is always a
positive number, so specification of a negative
number of minutes is supported.
Here is an example of specifying the Rebroadcast Delay. In
the US "Mountain" region the Rebroadcast Delay is 60 minutes.
$ TZ=America/Denver tvmaze.py -l en -a US -N "9-1-1: Lone Star" "2023-01-24 19:00:00" 60
<?xml version='1.0' encoding='UTF-8'?>
<metadata>
<item>
<title>9-1-1: Lone Star</title>
<subtitle>The New Hotness</subtitle>
<description>The 126 are called into action to a county fair when a fast-moving group of severe thunderstorms hit Austin, Texas; Owen's newfound passion for motorcycling puts him on a potentially dangerous path; Tommy meets an attractive single father.</description>
<season>4</season>
<episode>1</episode>
<inetref>42164</inetref>
...
The previous implementation allowed specifying the
Rebroadcast Delay with an environmental variable. That
functionality is now removed.
Resolves: MythTV#717
|
Please see my comments on 81e782c , too. |
In tvmaze.py "lookup by timestamp", there is logic to consider it a match if the recording is a little bit early. This helps, for example, if you set up a Manual Record rule to start at 8:00, but the broadcaster starts the show at 8:01 or 8:05. In tvmaze.py, we used to allow an early match for episodes starting as much as 60 minutes earlier, but that caused problems. In this new implementation, we limit the early match period to, at most, half of the episode length. This removes the problem of a false match for a rerun episode followed by a new episode. If the episode is 60 minutes, then the maximum early match period is 30 minutes. If it's 7 minutes, then the maximum early match period is 3.5 minutes. Refs: MythTV#717
|
@rcrdnalor : I'm not sure what you're asking for by "daily workflow". The purpose of these improvements is to make TvMaze lookup by timestamp work more reliably. It shouldn't give false results for a rerun episode. It should conform to the TvMaze policy which states that episodes that start airing at or after midnight but before 5:00 are considered part of the previous day. It should work for people living in timezones which implement Rebroadcast Delays. |
|
Looking a the linked reference https://en.wikipedia.org/wiki/Broadcast_delay |
Since the feedback from the forum and the mailing list did not show up new ideas and perspectives, Values are stored as strings an return 'None' if not existent. |
The tvmaze.py metadata grabber script has been updated to acquire an optional Rebroadcast Delay from the MythTv database. The database is only read when we know it's a 'Lookup by Timestamp' and no Rebroadcast Delay has been specified on the command line. This allows us to use the Rebroadcast Delay without having to update the callers of the grabber to add a new argument. Refs: MythTV#717
|
Thanks for the example code. I've used it to implement the solution you suggested, and have just committed that update. I've got a possible implementation for the configuration code. This places the configuration under Setup -> Video -> General -> General (Advanced) It works well, but I'm not sure if it's an ideal location. I like that the other configuration values on this page are similar. Mostly integer values which the user can increment or decrement or enter directly. Is this a reasonable configuration spot? Would some other spot be better? I considered Setup -> Artwork and Data Sources but we're not really setting either of those, and it was hard to track down the code which services that configuration page. |
I apologize for being unclear. I meant something like which stores the value in the mythconverg.settings table immediately. |
An option has been added to tvmaze.py to set
the Rebroadcast Delay in the MythTv database.
The syntax is
tvmaze.py --rebroadcastdelay <minutes>
<minutes> is an integer in the range (-1440, 1440)
Refs: MythTV#717
|
I've added an option to set the Rebroadcast Delay in tvmaze.py. I still think it should also be settable in MythTv Setup. |
|
I have found a case where Rebroadcast Delay doesn't work well. I examined TV listings across Canada one night this week to see if there are consistent Rebroadcast Delays. There are 8 timezone regions in Canada. A large portion of the content were programs originating from the United States. We'll start with the original broadcast times for the shows in the US (which is how they get stored in the TvMaze database), and compare to the broadcast times in different Canadian regions. You can see that Canada spreads Primetime shows across at least 4 hours, compared to the standard 3 hours in the US. In the US, broadcasters air the same shows in the same order across each region. In Canada, they shuffle the order of shows from region to region. In the Canada/Central region they aired the same show at different times on different channels. There's no single Rebroadcast Delay or set of multiple Rebroadcast Delays per region which would work consistently. We could work around these issues with a compromise. At least 95% of the time TV shows have only one episode per day or per week. Say we have a recording without an exact time match. We have a list of episodes for the given day. If there's only one such episode, we could presume that it's a date match for the recording. In the example listings above, this would work for all the shows except for 'La Brea' which aired two episodes in one day. The following would implement this work around: The downside of this compromise is that for a show which airs a rerun episode followed by a new episode, we would end up assigning the metadata for the new episode to recordings of both episodes. In the United States, we'd get the precise episode information for all the shows including both episodes of 'La Brea' if the Rebroadcast Delay is properly set. In Canada, we'd get precise episode information for everything except 'La Brea' in every region. Both 'La Brea' episodes would get assigned generic series information. |
When running a match-by-timestamp in tvmaze.py, if there is only one episode on the given date, consider it a date match. This will help us get precise metadata even if the timezone offset and rebroadcast delay adjustments don't give us an exact timing match. Refs: MythTV#717
Platform: Any
MythTV version: 33, master
Component: metadata
What steps will reproduce the bug?
Three lookup by timestamp scenarios show failures.
The earlier show should return no exact match. It should return:
The rerun episode should have a generic series description, and should not specify the Season, Episode, and Subtitle.
The TvMaze database does have the information, but it's stored under the previous date, 2023-01-31:
https://www.tvmaze.com/episodes/2478344/late-night-with-seth-meyers-2023-01-31-terry-crews-andrew-dismukes-rian-johnson-keio-stroudNote that in regions where some programs are shown with a Rebroadcast Delay, other programs (such as live sporting events) are shown without any delay. When searching for a match to the given timestamp, we may need to try both the Live and Rebroadcast times.
How often does it reproduce? Is there a required condition?
These 3 failures reproduce every time.
What is the expected behaviour?
What do you see instead?
Additional information
The text was updated successfully, but these errors were encountered: