Local Images are being replaced even when metadata locked

[Heckler 147]

Last night I went to watch something and was notified that a new version of MBC was available... So I let it download and install the latest official release, a couple of days ago there was also an official release for the server. Version 3.0.5395.0

 

As I was browsing through my movies, I noticed that background and folder images were very slow to populate... At first I figured it was just caching stuff and would sort itself out... 

 

But then I noticed that some of the folder images were different to the ones I know were chosen, and then I started noticing that backdrop images were also wrong.

 

Over the last couple of months I've slowly been working through every single movie and checking images and backdrops, making sure that they were all present and correct after the issues themoviedb seemed to have that were fixed in the server recently.

 

I have a set of criteria that I use for every single movie in my collection. After adding a movie, I always check and adjust the metadata to suit my requirements... Sometimes it's missing info, or I simply don't like some of the child like writing on the overviews. I also remove people and leave only the cast and director. When I have adjusted the data and chosen the images (I always choose 1000x1500 folder and 1920x1080 backdrops if available)

 

So this evening I started going through the metadata and checking a few things, and this is what I've discovered (see image)... Many of those images have been replaced with much smaller ones and some it has replaced every single folder and backdrop images at roughly the same size. Entire boxsets have been overwritten and every single image replaced.

 

In each case this has happened... every single one of those xml files was locked.

 

 

 

Now after spending a lot of time (1300 movies, each one checked manually)... It looks like I have to go through and do it again... all very frustrating as I'm sure you can agree.  

 

 

 

Has something changed, are local files no longer prioritised over grabbing them from the net?

 

Why are locked files still being overwritten, I was told in another thread that this had been fixed in a release a couple of weeks ago (maybe longer, I can't find the thread at the moment)... It would appear that this bug is still present.

 

I don't have the log file unfortunately... I restarted and created a new one to see if the same thing happened, but it didn't.

 

 

[ebr 14913]

Are you 100% certain it was us?

 

Why don't you have the log file? Restarting the server won't remove it...

[Heckler 147]

I don't understand what you mean by 'was it us' @ebr 

 

I had replaced all of the images recently, every folder/poster was 1000x1500 or greater and every backdrop was 1920x1080... or if none available, 1280x720.... As you can see in the image above, the image sizes are much smaller resolution. In other cases, the image sizes were as I would expect, but every image had been replaced and I'm assuming downloaded fresh.

 

Even if the smaller resolution images could be taken out of the equation, which is possible if no images were available at the time and I had to go searching for anything I could find... That still doesn't explain why images are being overwritten when local ones are available, nor why it is overwriting data for locked xml files. I remember redoing the Resident Evil boxset just a couple of days ago... and every single image was replaced again last night, it was one of the items that I noticed behaving badly and not displaying any images at all, even though the metadata was there. 

 

I'll have a root around in the morning and see if I can find the right log file for you. I thought when you restarted the server it created a new log file... I'm assuming the old one will still be there somewhere.

 

At the moment I'm sat here going through the metadata manager, and I've found about 30 with smaller resolution files, and about 50 that have had all images replaced entirely. In the case of the smaller res ones, identical files are available at the full size when you browse for them. All of the movies that had this problem seem to be located on the same drive, but I've done the checks and it's come up clean. I then checked the drive I have the image cache on and that too passed all health checks.

[ebr 14913]

I just meant do you have any other systems that download artwork - any other metadata managers or other things that could have possibly replaced the files.

 

Also, you keep saying "locked xml" but then talking about images that have been replaced.  Just so I understand, are we just talking about images here?  Because xml and images are two different things and locking the xml wouldn't have any affect on the images.  Images, however, are not supposed to be replaced unless you specifically ask for them to be.

[Heckler 147]

@@ebr  I rely entirely on MBS to grab all metadata, I then adjust the data as I need to.

 

I'm taking a look at things again and at first I thought it was only older movies that were showing up with reduced size images... but then I came across a couple that were only added in the last couple of weeks.... But again I stress that I may have gone looking for images during the period users were unable to grab images from themoviedb... an issue that is now fixed.

 

So I'm trying to concentrate on finding those that have had images replaced.

 

I've checked for logs and found several... sizes vary from 200k to 45mb. I'm trying to think of the exact time I updated MBC. I'd gone to bed really early as I'm getting up at 4am at the moment... But there are 2 logs from the 22nd, one from 05:37 (45mb) and the other from 00:00 (216k)

 

I then have the new log starting from 00:00 on the 23rd.

 

 

Looking at the 45MB log and there's a lot of stuff in there about coverart treatments... I think this was after a restart of the server to finish an update to coverart... So I think that's the log.... It's just a massive one that I can't attach.

 

I can PM you a link to my dropbox if you'd like

Edited October 24, 2014 by Heckler

[Luke 37064]

maybe you did a refresh and seleted the replace all images option. that is the only way MBS will ever replace images. even if the items are unlocked that is the case.

[ebr 14913]

That's what I was thinking too.  You might have done it without realizing it.  You might have been trying to refresh data on a folder and not realized that would refresh all children too (perhaps there should be a warning).

[Heckler 147]

I was in the client at the time, not the browser... as far as I am aware there isn't an option to refresh and replace all images... unless something has changed recently... and if you do a refresh from within the client shouldn't it refresh from the local data/images and not download new ones. 

[ebr 14913]

I'm not sure which app to which you are referring when you say "client" but if you refresh from within MBC it is the same as doing it in the web client.

[Heckler 147]

I was in MBC not the metadata manager... In MDM you have to specifically select the refresh and replace images, that's not an option within MBC... So does this mean that refreshing from within MBC overwrites whatever you already have, without you needing to specify that's what you want. As I understood it, refreshing with MBC simply refreshes the local data... or at least thats the way it used to be. In this instance, it wasn't loading the local images, even though they were present... the reason for that is unknown at present and I can't see anything in the log, but then I'm not sure what to look for really. So any refresh I did from MBC should have reloaded the local data unless it's been changed now.

 

It also raises the question... Does refreshing from MBC override the locked xml files too?  When I lock them, it's because I don't want them altered, it's why I have autoupdates for metadata turned off... If they're locked, then I would hope that no user is able to override that in any way without first unlocking the field from within metadata manager (or manually adjusting the xml file itself... which i assume would require a scan to refresh that anyway).

 

Any enlightenment on how safes the data is when locked, would be greatly appreciated... especially after manually adjusting 1300+ movies to suit my needs.

[Heckler 147]

@@ebr you mentioned earlier that locking the xml file doesn't lock the images... so can I ask why this feature is even there... if it does nothing at all?   I thought you are supposed to have the ability to lock sections or the whole file. I started to lock the genre/rating/people ones, and then started locking the images/backdrops... Then I just started locking the entire file.

 

 

I've accepted the fact that I'm not gonna know the how/why of every image that's gone or been reduced... But I would like to know if these features to do with locking the metadata & images actually work as described... Or is my attempt to have total control over the local metadata futile... Because manually adjusting these files took me 2 months (in short bursts when I had some free time to kill).

 

I just don't want to feel frustrated that I may have wasted all that time and effort... Because I love MB, and won't stop using it over this, I'll just have to live with it being able to change things as it wants.

[ebr 14913]

The locking refers to the metadata files and images are always locked unless you manually refresh them.  I didn't know that a manual refresh would overwrite locked metadata files as well though (I think that's what Luke said).

 

The refresh call from MBC hasn't changed in like a year but the way the server refreshes things has evolved quite a bit since then so its possible that it behaves differently now than it did before.  MBC requests a full recursive refresh.  Really, that feature is a hold-over from MB 2 days and should almost never be needed which is why it isn't exposed anywhere in the interface.

[Rainey 2]

I use a bat file to backup the metadat files in each directory. It just rar's up the smaller files and saves a copy.

 

It can either make one large file or make one file in each movie directory, it depends on what directory it is run from.

If you have a directory Media that has a few folders of different movies types like Movies, Adult, Kids and you run the bat file

in the main media directory it will create one large file for the backup. If you run the bat file in Kids it will creat a rar file in each movie directory.

 

Here is the sample file i use.

@ECHO OFF
rem This file is working to recurse directories and RAR the metadata files in each directory,
Rem it will skip the larger movies files and only get the smaller .jpg and metadata files.
rem Just edit/change the base directory E:\Postings\ in the below line to point to the RAR.exe file.
rem Run this bat file in the base directory where the directorys of files you want to RAR are.
rem RAR files will have the name of the directory the files are in.
rem This file is for Metadata backup/update, it scans directories of files and creates
rem a RAR file in each main directory the next time it is run it just updates the files.
rem If you want to remove the files for some reason i have included a line below for that.
rem Just remove the rem statement and put in front of the last line to not create them again.

rem rar options
rem   ep2           Expand paths to full
rem   u             Update files
rem   r             Recurse subdirectories
rem   sl<size>      Process files with size less than specified
rem   m<0..5>       Set compression level (0-store...3-default...5-maximal)
rem 
rem  Note: current file size limit is set at 500K  -sl500000
rem        Adjust as needed
rem
@ECHO.
rem Delete all old metadata RAR file first. If you 
rem for /R %%I in (*-metadata.rar) do del "%%~fI"
rem
rem Create RAR files
for /D %%I in (*.*) do "E:\Postings\rar.exe" u -ep2 -r -sl500000 -m5 "%%~fI\%%~nI-metadata" "%%~fI\*.*"

[bemy 3]

I also changed a lot of images manually by selecting the image of the movie, but it seems there are replaced back by the old low-res images that were placed in the first place.

It would be better to make an option to automatically place and image only if no images exists (so manual changes are not replaced again later) or not to replace larger images with a smaller version. Locking each item individually (which can only be done from the Metadata Manager) is not very handy in this case.

Edited January 15, 2016 by bemy

[adhalli69 0]

I'm new to Emby but I'm having a similar problem.

 

I have a bunch of TV shows on a NAS which Emby has access to. After scanning them all, they all have posters downloaded, however 2 shows have banners downloaded instead of posters.

I can manually fix this which seems to work initially, however whenever i do a library scan or the automatic scan runs, it reverts my changes back to using the banner.

I've tried using Edit Image, re-identifying the shows, manually uploading images and even moving the series off my NAS, running a scan to remove them from Emby and then re-adding them. Same thing happens every time.

I also tried correcting the issue, going into media manager and selecting Lock this item to prevent future changes, but that made no difference.

 

At this point I've run out of things to try.

[Luke 37064]

hi @@adhalli69, have you enabled saving local metadata to media folders? what are the contents of those tv series folders, can you show screenshots? thanks !

[adhalli69 0]

The directory containing the shows on the NAS is shared via SMB and mounted to the Ubuntu server that Emby is running on as as read-only.

All metadata is all stored on the Emby server itself. As I said, I'm new to Emby so there were some trust issues there

 

The 2 shows I'm having issues with are Fifth Gear and Kenny vs Spenny.

Here's what it keeps reverting to:

 

Here's after I fixed

 

Then I did a library scan and it reverted back to:

[Happy2Play 8282]

What images are stored with the media, if any how are they named?  Can you post a server log.

[adhalli69 0]

That's it, i checked on the NAS and there were 2 "Folder.jpg" files, in those 2 dirs only.

 

I deleted them, did a library refresh and now all is good.

 

Not sure where those 2 images originated. Emby was innocent all along, sorry to sully its good name.

[Luke 37064]

If Emby had write access it would have replaced those images at the time you edited them. Otherwise what happens is on the next library scan that image gets rediscovered and takes priority over any images stored elsewhere.