[mythtv-users] Metadata Lookup Dependent Upon Extension?

[Mike Perkins]

On 18/01/15 17:20, jim wrote:
> I've noticed something that doesn't seem right regarding how metadata
> lookup performs when importing DVDs and naming the resulting files. I've
> tested with several DVDs and the results are repeatable.
>
> Post the ripping process, using Browse Videos and Scan for Changes, I
> find the following scenario.
>
> If a file is created, with proper DVD title, and without any extension,
> the metadata lookup runs automatically with one of two results. If there
> is no ambiguity in the on-line databases, the proper metadata is
> returned, the presentation transitions from a black box with a large
> white question mark to the DVD's coverart, etc. If there is ambiguity in
> the on-line databases, a nice graphical interface is brought up to allow
> the user to select the correct metadata package based on graphical and
> textual information, and then the coverart appears, etc.
>
> If the exact same file is created, but with a .mkv extension, the
> metatdata lookup functions differently. Some of the metadata may be
> found, but no artwork is obtained. The artwork can still be obtained but
> now requires user interaction, via several additional steps.
>
> Why should presence of a file extension cause this difference? Shouldn't
> the metadata lookup strip off the extension and use only the title?
>
> The DVDs are all ripped as h.264 using a mkv container. The only
> difference is the presence or absence of the .mkv file extension in the
> file name.
> Several other processes in my system require proper file extensions, and
> I believe having the extension is a best practice.  A similar filing
> structure, /mythtv/videos/title/title.mkv, is used for all the ripped DVDs.
>
> Thoughts?
>
I've recently ripped some DVDs using Handbrake to h.264 in an .mkv container - 
basically, just using the Handbrake defaults. I have not noticed the scenario 
you describe.

I /did/ notice that the metadata collection suddenly sprang into life recently 
after never having worked before. A recent rebuild might have triggered that.

Perhaps it depends which version you are using? Mine is:

$ mythfrontend --version
Please attach all output as a file in bug reports.
MythTV Version : v0.27.4
MythTV Branch :
Network Protocol : 77
Library API : 0.27.20141016-1
QT Version : 4.8.2
Options compiled in:

This is the stock deb-multimedia package.

-- 

Mike Perkins