Problem with pre-existing .nfo when saving metadata in media folders

[alexrw 13]

I'm on Windows 8.1 and tried the latest stable and latest beta as of this writing (downloaded latest 1h ago). There is a very pesky bug happening. I kept hitting this when ripping some of my own Bluray discs in order ot watch them on a media box in Kodi that has no Bluray drive.

 

Suppose I have a file "S01E02.720p.x264-MyRip.mkv" and that there is already a "s01e02.720p.x264-myrip.nfo" that was not created by Emby and which contains some non-xml.

 

Under Windows, the filenames are the same since it's case insensitive, but note the case difference!

 

The problem is that when Emby scrapes the dir, it does replace the .nfo file with one that has valid XML data, but it does not change the file name case. It leaves it as "s01e02.720p.x264-myrip.mkv" instead of "S01E02.720p.x264-MyRip.mkv".

 

The episode name in the web interface or Kodi (I tried both) is "S01E02.720p.x264-MyRip" instead of the actual Episode name retrieved from TheTVDB.

 

However, if I delete the .nfo and then trigger the "Scan media library" task, then a new .nfo is created, this time as "S01E02.720p.x264-MyRip.nfo" and then the Episode name shows up correctly.

 

I think Emby should make sure to delete any existing .nfo first then create a new one and ensure that it has the same case as the video file name.

 

The best would actually be to add a string to the filename, e.g. "-meta" like you do for the thumbnails with "-thumb", e.g. "S01E02.720p.x264-MyRip-meta.nfo" ... this would fix the problem and also preserve the existing .nfo file rather than replace it.

 

Cheers

Edited October 18, 2015 by alexr

[Luke 37086]

I guess it is subjective whether this is considered a bug or not. In linux these are two different files. I can almost promise that if we do this there will be some other use who complains that their original file was deleted. we have promised that emby will save metadata as well as honor existing files. we never really promised that it would be your maid and clean up situations like these.

[alexrw 13]

You seem irked, and I'm not sure why ... I'm also reporting a problem for the Windows version (not sure what Linux has anything to do with this).

 

Emby already deletes/replaces any existing .nfo with the same name, and I don't mind that. The problem is that the one it creates does not have the same case as the video file and then Emby itself gets confused. That is clearly an Emby problem.

 

Why not ensure that the nfo it creates has the same case as the video file?

Edited October 18, 2015 by alexr

[Nologic 30]

Hmm all things aside I'd suggest using theRenamer, FileBot, or Media Center Master, to rename the file. It's best to start from the ground up keeping things organized.

 

Example of one my TV episodes:

W:\TV Shows\Vikings (2013)\Season 03\03X05 - The Usurper.mp4

This makes things fairly clear, so that in the case of data being destroyed or lost somehow, I can generally recover with not a lot of tears. This should also give Emby more or a chance to update NFO's to newer formats, or enhanced data.

[alexrw 13]

That's beyond the point. I'll try again.

 

If there is a nfo in the folder already that happens to have a different case than the video, then Emby does wipe it and replace it with a new nfo (good), but it does not create the correct file case (bad) and then it does not recognise it in the library (bad).

 

Since Emby already wipes and replaces any existing .nfo with the same name, why not ensure it has the same case as the video?

 

This problem also arises when downloading from the internet as many episodes/movies come with a .nfo file. Or add "-meta" to the .nfo filename and be done with it (don't wipe existing .nfos).

 

It's an Emby problem on Windows when choosing to write the metadata in the media folder (works fine otherwise). It should be fixed nonetheles. 

 

Cheers

 

p.s. Emby should be more robust when scraping in that we should not have to use tens of other tools just so that Emby can scrape a dir -- that kind of defeats the purpose. I'm reporting because I'd like Emby to improve! Kodi is much better at scraping correctly.

Edited October 19, 2015 by alexr

[Nologic 30]

No it's not beyond the point.

 

Proper naming of folders and files, helps prevent corner cases like what you have here.

 

There are dozens if not hundreds of apps that create metadata, and drop them into files with a NFO extension.

 

Of these app's few use the same markup and layout. This produces problems when parsing the file to see if the data it holds is usable.

 

Should the regex or string search file...on some critical data...it's likely best to fetch new data.

 

The casing of file names is cosmetic...while I certainly have my preferred look...it's honestly unimportant.

 

However having proper metadata is important...and while the original NFO file you seen may have looked good...it may have in fact had several issues...were they critical...no clue...but Emby tossed it out for some reason...and because you had no decent naming structure...Emby couldn't do a good job fetching the required info.

 

I honestly care very little about the metadata files...I can rebuild them...but I certainly don't want Emby automatically renaming my actual media...because if it gets that wrong somehow...I'd largely just have to format my drives and start all over.

 

Metadata is nice...but I can find and watch stuff just fine without it, as long as my folder and file structure stays clean.

 

To drive home the importance of file & folder naming. This happened with my brother, who was "THE" system admin for a fortune 500 company. He bought into PLEX's sales pitch that it would find proper metadata and artwork for any media file...and it largely did an okay job....however in several cases there were multiple copies of a given TV show or Movie...one would be a screener, one would be by some ripping group, another would be his own rip from bluray and\or dvd...so on and so forth...but because he didn't take the time and cleanly name stuff...he was flooded with copys...most of them crap quality.

 

I spent 12 hours trying to clean up his junk pile...only to give up and walk away when he moved another pile of shit into the stack, that had dups once again.

 

He finally seems to have come around to taking care of stuff from the ground up. He still uses PLEX...but at least now Plex is near a 100% in scrapping data.

[alexrw 13]

@@Nologic, First, if you read my posts carefully you'll see that I'm not discussing the case of throwing utter junk, dupes and whatnot at Emby. I discovered a bug and I reported it. Emby should create the .nfo file with the correct casing or else it gets itself confused in the scenario I described.

 

Secondly, I understand your points but in all honesty, I didn't choose Emby, Kodi, etc in order to add to my burden of organizing my media files. Scraping media in a robust manner is one of the biggest points of these apps. I won't accept as a solution the usage of 3 extra apps and taking more time to pre-rename/organize my media so that the media organizer can have it easy. It really defeats the purpose. We are in the 21st century so that technology makes our lives easier, not harder.

 

In any case, Kodi is much more robust when it comes to scraping (Emby misses or gets confused far more often). I'm reporting issues because I'd like Emby to improve. Simple as that. From that persepctive, I'm not sure your intervention helps Emby improve (by definition, workarounds are not fixes).

Edited October 19, 2015 by alexr

[Nologic 30]

When you are handing Emby file names like that...you are indeed throwing junk at it.

 

Something like:

 

The.Musketeers.2014.s02e04.720p.x264-MyRip.mkv

 

While ugly as hell, is giving at least some useful info. As hopefully the show name can be parsed from it, as well as airing year...this helps as there are shows with the same name, that aired on different dates.

 

Your example:

S01E02.720p.x264-MyRip.mkv

 

There are so many TV shows that have 2 or more episodes in season 1...one has a better chance of winning the lottery, than getting the correct metadata.

 

The casing of a file name, I doubt very much that it causes Emby to get confused. It has more to do with the fact the file name is more or less useless. As more than likely the NFO in question failed to be parsed.

 

If the NFO can not be parsed, whether its badly formed or lacks the required information...Emby then has to depend on the file name and folder structure...and in your case Emby would need to be psychic..as it has nothing to work from.

 

It's best hope with no valid NFO, or useable file name would be to hash the file and hope somewhere on the web somebody has hashed theirs as well and linked it in some manner to the proper information.

 

You are right that Emby should preserve casing in file names.

 

Maybe it's ability to parse existing NFO/XML's needs to be enhanced.

 

However one needs to put some effort forward to making sure things go right.

 

Oh and I've used Kodi before...it scraps great...it was only correct 78% of the time give or take.

 

As they say garbage in, garbage out.

 

My work flow requires a bit of effort...but ALL of my metadata is correct.

 

For me to add 50 tv shows takes about 30min...and that is mostly because I batch create my own BIF files...otherwise 5-7min max.

 

I can purge all my NFO/XML's and Emby or MCM will have scrapped all the correct metadata within 12hr...thats with 5000+movies, and probably many times that tv episodes.

 

If you purged your files...could you feel at all secure that Kodi or Emby could do the right thing?

[Luke 37086]

if your server is on a linux OS then this should already be working as expected. it will save with the file name identical to the video and the old file will be left behind as garbage.

 

but if your server is windows, we will attempt to save it with the exact name, but the OS will step in and say, I'm case in-sensitive, and that other file that is already there matches. So windows decides on it's own to save over that. so in order to do this, we would have to first delete the previous file. and i suppose we could do that, but then we'll have the inevitable situation of delete succeeds but write fails, and then we have to explain to a user why their existing nfo file is now gone.

[alexrw 13]

if your server is on a linux OS then this should already be working as expected. it will save with the file name identical to the video and the old file will be left behind as garbage.

 

but if your server is windows, we will attempt to save it with the exact name, but the OS will step in and say, I'm case in-sensitive, and that other file that is already there matches. So windows decides on it's own to save over that. so in order to do this, we would have to first delete the previous file. and i suppose we could do that, but then we'll have the inevitable situation of delete succeeds but write fails, and then we have to explain to a user why their existing nfo file is now gone.

 

But you are already wiping the user's file as it is! I'm completely puzzled by your argument ... the user loses the file either way. In most cases, the initial .nfo in question is not important anyway, but it is common for video files, especially episodes, to contain a .nfo file. Emby replaces it but then won't display any metadata and it's been more than annoying.

 

You should not first delete, but instead should:

- first create a temp file in that folder

- then write to it (the nfo xml content)

- then, if successful, delete initial file and rename the temp file

 

That's how safe file replacement is normally done.

 

@@Nologic, I'd appreciate it if you let me and the Emby devs further discuss this issue. Feel free to start another topic to discuss your favourite housekeeping activities.

Edited October 19, 2015 by alexr

[Nologic 30]

Fine by me -

 

wish in one hand and shit in the other and see which one fills up faster.