[mythtv-users] Metadata Lookup Dependent Upon Extension?

[jim]

On 01/18/2015 01:14 PM, Mike Perkins wrote:
> 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.
>
Is v0.27-193 an older version than v0.27.4? If so that may account for
the difference.
 
Please attach all output as a file in bug reports.
MythTV Version : v0.27-193-g8ee257c
MythTV Branch : fixes/0.27
Network Protocol : 77
Library API : 0.27.20140323-1
QT Version : 4.8.6

I have been using the version and update process available via the
Software Manager in Linux Mint 17.1. I'll have to look into getting the
package from the source instead.