[mythtv-users] MythMetadataLookup questions

Robert McNamara robert.mcnamara at gmail.com
Mon Aug 1 05:29:49 UTC 2011

On Sat, Jul 30, 2011 at 2:01 AM, Jan Ceuleers <jan.ceuleers at gmail.com> wrote:
> Here's another multi-language use case.
> I'm in Belgium and I get a lot of channels from neighbouring countries
> in multiple languages. Even on our domestic channels we get programming
> in the original language (e.g. Hollywood movies or BBC content in
> English, French crime drama such as Maigret in French, etc) with Dutch
> subtitles. The metadata titles and subtitles are also announced in their
> original language.
> The principal language in my household is English, so that is the
> language I run the frontend in.
> Cheers, Jan

Hi Jan,

Thank you for your thoughtful reply.  I am happy to go on explaining
how these things work so long as the tone remains cordial.

Remember that the language limitation is only going to inhibit
automated matching-- not function.  For those items that don't
automatically match for you (and depending on the quality of your
guide data, many might), all that you need do is:

1) Edit the recording rule for the title.
2) If the rule is not automatically matched, either due to an API
issue (using cross-languages) or due to a guide data issue, put the
inetref for the item in the "Metadata Options" screen.  If the guide
data is exceptionally poor (a TV show lacks a subtitle, and the
category_type is not set to one of the known values for a series/tv
show), then you may wish to set the season and episode values to
something besides 0 to force it to use the TV grabber (I suggest 1x01
since any show should have that).  This way, the metadata classes know
exactly which grabber to use, and since they know the inetref
already-- This bypasses title matching entirely.
3) At this point, you can either hit one of the buttons (Select Online
fanart/banner/coverart) or save the rule and let mythmetadatalookup
--refresh-all-artwork do the work automatically.
4) Optional:  If your recordings haven't got inetrefs yet (the field
is BLANK in the database/edit recording metadata screen) you can run
mythmetadatalookup --refresh-all to copy all the rule inetrefs across
to their recordings.  This is something that seems to be missed by
some.  It's also possible that after all of the mis-manipulation done,
that the recordings have some wrong value set, and thus the
copy-across cannot take place (the code presumes that if the user set
the rule to one value, and the recording to another, that they must
know what they're doing, and leaves it alone).

The primary issue in this thread is bad guide data/unusual
configurations preventing things being as automated as the users would
like-- but the functionality itself is there, and will work for you if
you take some time to get familiar with it-- I daresay that you will
find it even more powerful, especially as the functionality is
expanded to further enhance recordings with metadata not provided by
conventional guide sources (so far, we add the season and episode
numbers for matched episodes, and assign artwork, but the possibility
exists to add much, much more).

In at least one instance in this thread, we see what it obviously a
television show (10+ instances of the exact same title, with no
subtitle) but because of severely poor guide data, the metadata
classes assume that the best grabber to start with would be the movie
grabber-- there are multiple results at TMDB, and because the user
hasn't set the inetref for that rule and copied it across to the
recordings, the grabber simply does nothing rather than do the wrong
thing-- which, in this case, it would if it went any further.  Any
decision would be the wrong one, so the code instead prefers to do
nothing, expecting that the user will have made themselves aware of
how to fix things so that the right decision is made henceforth.

Users since .22 will recognize this behavior as identical to how
MythVideo metadata grabbing works-- if something has a season and
episode value, the TV grabber is used-- if it has a subtitle, the TV
grabber is used first as it's likely to be TV (but not definitely)--
if it has neither a subtitle nor season/episode information, the Movie
grabber is used.  The new metadata stuff expands on this logic
somewhat by trying to account for bad guide data or generic episodes
by checking category information, the rule that created a recording,
etc. They also anticipate these kinds of guide data problems and offer
the user an opportunity to work around them by setting
inetref/season/episode on the rule (and automated methods of copying
that data across to recordings produced by those rules).

In the other replies to this thread, there's a combination of manual
manipulation of the database, lack of information, lack of following
the steps outlined above, and lack of willingness to use the parts of
the code that make it all work.  In those cases, I am convinced that
the database values are so compromised by these mistakes that I cannot
offer any additional assistance-- I'm also not inclined to try as my
last detailed response yielded some pretty extreme overreaction.  All
official themes, and all of my own, support the new metadata screens--
I cannot assist those using third party themes which have not been
updated-- they are unable to use this new functionality, but not
through my doing.  Moreover, Mythweb does not *yet* support metadata
lookup officially, though I wrote new API methods to allow it to do
so, and we have a patch pending in trac to add them.  So, when a user
tells me that they are outright unwilling to use a supported theme,
unwilling to schedule through the frontend, and are manually
manipulating the database, I just cannot conceivably assist them--
moreover, that database is tainted in such a way that should the user
try to start using the code correctly, the results are undefined.

Will users need to learn new behaviors?  Yes.  Will existing users be
irritated because things are not 100% automated in all cases?
Undoubtedly.  Does the new metadata lookup contain bugs, and could it
be made more effective?  Certainly!  But it is my hope that those
users will understand that the promise of adding additional textual
metadata, the ability to specify their preferred artwork (on a
season-by-season basis, and getting new, fresh artwork when the season
rolls over), and the massive speed boost in the Watch Recordings
screen when the artwork is statically assigned to rules and recordings
make it worthwhile in the near term, and very worthwhile in the long

I hope that this reply helps you to understand how you can take
advantage of this new functionality when you begin to use it.  I
recognize that this involves a potentially significant amount of
initial work for users with very active existing setups.  For users
with high quality guide data like Schedules Direct, many of these
steps can be skipped because the metadata code can make much better
assumptions when provided with more accurate and complete data.
However, once users settle in to how things work when creating new
rules (by opening Metadata Options when setting up a new rule, or
doing the equivalent in Mythweb when that part is committed), it will
become a part of their muscle memory and they will experience the
near-perfect results that I, and my many guinea pigs in writing this
code, do.  Moreover, when this becomes a part of released code, new
MythTV users will simply understand that if they wish to get artwork,
they will need to allow the code to perform a lookup (and assist it
when necessary).


More information about the mythtv-users mailing list