Emby linux server renaming media terribly once in a while

[lastelement21 17]

I threw on Kill Bill this morning.  When I started watching it, it was named Kill Bill.  By the time it ended, it was named x264 crf encode.  This is not the first time this has happened, at all, but it definitely doesn't happen all the time.  My emby server is hosted on linux.

What gives?

[Happy2Play 9780]

Do you have "Prefer embedded titles over filenames" enabled on that library?

[lastelement21 17]

I think I do, however the subtext on that item is that it will only display that when internet metadata or local metadata is unavailable.  Why would a movie that had internet metadata stored and available when I started playing suddenly not?

"This determines the default display title when no internet metadata or local metadata is available."

Edited September 3, 2020 by lastelement21

[lastelement21 17]

I also had no trouble tapping identify and re-filling the item with metadata.  Why would an item suddenly lose its identification?

[Happy2Play 9780]

Ah that is right, so for some reason the media was somewhat unidentified.  Without the log for when it happened it is hard to say.  Does the media go offline at all?

[Luke 42077]

Because that embedded name is taken over the filename as the initial name, and that is what gets used to lookup internet metadata.

Obviously, it's not going to find anything based on that, so it stays as that.

[lastelement21 17]

1 minute ago, Luke said:

Because that embedded name is taken over the filename as the initial name, and that is what gets used to lookup internet metadata.

Obviously, it's not going to find anything based on that, so it stays as that.

Except that it was identified fine just a couple hours ago, when I started playing it.

[lastelement21 17]

3 minutes ago, Happy2Play said:

Ah that is right, so for some reason the media was somewhat unidentified.  Without the log for when it happened it is hard to say.  Does the media go offline at all?

No, the media didn't go offline.  Watched the movie the whole way thru uninterrupted.  Server is hosted on a dual 100gbit fiber connection with backup cable, and would have received a page (along with a number of other people) if any of those had died.

[lastelement21 17]

I do have a pile of embyserver logs, which I can share.

[Happy2Play 9780]

4 minutes ago, lastelement21 said:

Except that it was identified fine just a couple hours ago, when I started playing it.

There may be something in the current server log if it was correct then.

[lastelement21 17]

11 minutes ago, Happy2Play said:

There may be something in the current server log if it was correct then.

Kk, I'll set up a pastebin for the server logs in a sec.  BTW Luke, the file has no metadata.  So what data is it defaulting to instead of the filename when that doesn't exist, and is also for some reason not using the data it already pulled down from the internet when it correctly identified the media when the it was added?

Edited September 3, 2020 by lastelement21

[Happy2Play 9780]

1 minute ago, lastelement21 said:

Kk, I'll set up a pastebin for the server logs in a sec.  BTW Luke, the file has no metadata.  So what data is it defaulting to instead of the filename when that doesn't exist, and is also for some reason not using the data it already pulled down from the internet when it correctly identified it when the media was added?

The video track has to have that name shown.

[Luke 42077]

1 minute ago, Happy2Play said:

The video track has to have that name shown.

Yup, bingo, and combined with the option to use embedded titles, that explains it.

[lastelement21 17]

Doesn't explain how it was identified just fine when it was added, and suddenly lost that info.  Why wouldn't the update process use the same process as being added originally?  Why would the existing metadata suddenly be thrown out?  Why if there is no metadata would it fall back to the encoding type rather than the filename?  I feel like something is missing here.  Please, lemme know what tool/command to run on the media file to double check things and I'll post the output.  I was using VLC to dig at it for myself, but figure you guys have a CLI command like ffmpeg which is more standard.

Server logs:
https://www.urnes.org/embyserver-1.txt

https://www.urnes.org/embyserver-2.txt

 

[lastelement21 17]

I suppose its possible I manually ID'd that item when it was added, but then the issue is emby tossing out a manual identification

[Luke 42077]

What do you mean manually identified? What exactly did you do?

[lastelement21 17]

In the "..." menu of items in the emby interface in web or on android is the "identify" button.  If I did that for this item, in there I would have typed in Kill Bill, and selected the correct result.

[Luke 42077]

Ok it's hard to say as the log doesn't contain anything obvious. Can you get it to happen again?

[lastelement21 17]

Not sure, when I did the identify process again this morning it worked.  I can throw the movie on again and see if it breaks again.  If I notice it happen again to another movie at any point I'll definitely grab more logs.  I was sorta hoping someone else had seen this issue before and I could help dig at it.

BTW 'ffmpeg -i' did have 'x264 crf encode' as the metadata title, just not sure why emby would throw out good info it already had in favor of metadata that doesn't match anything else.  Movie was not added super recently or anything.

Edited September 3, 2020 by lastelement21

[Luke 42077]

That would be great, thanks.

[lastelement21 17]

I ended up turning that setting off.  Still not sure why the embedded title would override an already ID'd item, but using filename as the default makes more sense anyways.  If the filename pops up for me as the title on an already ID'd item I'll post here tho.

[Luke 42077]

Thanks for the feedback.