[mythtv] Manual Recordings and metadata lookup

[Steve Erlenborn]

On 3/23/21 8:36 AM, Peter Bennett wrote:
> On 3/22/21 1:49 PM, Roland Ernst wrote:
>> A user reported [1] that for manual recordings, the subtitle is 
>> filled in by a date-time object.
>> This causes problems when retrieving the metadata data, because the 
>> options
>> " -N title date-time" is not required for the metadata grabbers [2].
>>
>> What is the reason to fill in the date-time to the subtitle field?
>> What use cases are covered / supported by this convention?
>>
>> [1] https://github.com/MythTV/mythtv/pull/336
>> [2] https://www.mythtv.org/wiki/MythTV_Universal_Metadata_Format
>>
>> Roland
>>
> Manual recordings have no access to the subtitle, so it is likely that 
> the developers used that instead of leaving subtitle blank. I would 
> think that manual recordings do not normally use metadata lookup. If 
> metadata lookup is used for manual recordings perhaps we should ignore 
> subtitle on manual recordings or ignore subtitle if it contains a 
> date-time. I think that calling the grabber with -N title date-time is 
> not valid.
>
   I am the user who mentioned that <grabber> -N <title> <date-time> 
always fails for
Manual recordings. That's not fatal. The mythmetadatalookup program 
proceeds to run
<grabber> -M <title> to get an inetref value. Then it runs <grabber> -C 
<inetref> to
retrieve general metadata information on the TV series.

   No, it's not accurate to "think that manual recordings do not 
normally use metadata
lookup". 95% of my record rules are Manual, and they've been 
successfully retrieving
metadata, on my system, ever since my patch, #12277 "Metadata collection 
always fails
for Manual Record rules", was submitted 7 years ago, and was pulled into 
the official release
3 years ago.

   At first, I thought it was pointless to be invoking <grabber> -N for 
a Manual recording
rule, but I've changed my mind. Now, I think it was clever of the 
developers to pass
<date-time>. When the <subtitle> string is in the form of <date-time>, 
that information
can be sufficient to find episode specific information for a recording.  
TvMaze provides an
episodesbydate search option. The date and time need to be adjusted 
based on the local
timezone and the timezone specified in the database. Once that's been 
done, an exact
match for an episode can often be found. I'm working on an update to the 
tvmaze.py
grabber to properly support this -N <title> <date-time> syntax.

   There are some limitations. The database only stores the original 
broadcast date
and time. If the show you've recorded is a rerun at a different date or 
time, the
search for an exact match will fail. In such a case, we won't know about 
the exact episode,
but mythmetadatalookup will proceed to get general metadata information 
about the
recording by using the -M and -C options.

   When it succeeds, the episode specific information is retrieved, 
including
the episode description. My hope is that this extra information will 
eventually
get displayed. When I automatically record a series episode based on EIT
sent over the air, there's usually a short description of the episode which
appears when a recording is highlighted. It seems like this should also work
for Manual record rules, if we can determine the specific information for
an episode. That doesn't work yet because even when mythmetadatalookup gets
all the information it needs from the -N invocation, it currently 
proceeds to run
-M and -C to get generalized information anyhow. Some refinements will be
needed in the metadata lookup code to make this work better.

   It might be harder to add support for -N <title> <date-time> to the 
other new
television metadata grabber, "TheMovieDB.org V3 television". I've 
scanned through
the API at developers.themoviedb.org and although their database holds 
'first_air_date',
I haven't found an option to do an episode search based on this date value.

   I think that calling the grabber with -N title date-time is valid. It 
just hasn't been
used for anything useful yet.

  - Steve

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-dev/attachments/20210323/1b477b76/attachment.htm>