bad quality covers / thumbs

[scheideggstrasse 0]

Hi

 

some of my covers / thumbs (~5%) in the movie list have a bad quality.

when I edit the images over the context-menu and fetch a new cover the quality is fine, until the scheduled indexer run.

 

and ideas?

 

cheers

[MndWrp 101]

Some of the artwork providers don't have systematical good quality.. The most consistent one as far as quality is fanart.tv i think.

[Luke 42077]

Sounds like the pooor quality version is in your media folder, possibly as a tbn file, correct?

[MikePlanet 144]

Hi Luke,

jumping in here to confirm, that when there is local artwork in the folder this will be preferred over images from internet image providers. Imho this is - depending on the user settings/scenario - a bug.

Thus I would suggest to change the behaviour as follows:

- If the user decides to store artwork within movie folder locally, the local artwork should be preferred - user can manually update it, if they want or live with what's in there

- If the user decides not to store artwork within the media directory, the images should be loaded from internet image sources

My use case is the second one and I store the images within emby metadata folder - but as you mention, if local images are existing within the media folder, those are linked to the media item. This makes browsing the library very slow, as all sleeping harddisks of the media storage need to spinup which causes delays of several seconds (multiplied to the number of discs where media of a respective view are located).

I know that this could be solved by manually deleting local images from the media folder, but I think it could be handled automatically by the server easily ...

[Luke 42077]

Hi Luke,

jumping in here to confirm, that when there is local artwork in the folder this will be preferred over images from internet image providers. Imho this is - depending on the user settings/scenario - a bug.

 

Sorry but the whole reason for having local images is so that they will be used. I cannot even begin to imagine the outpouring of complaints we would see if we started ignoring them. As far as the spinup goes that's not really related to this topic so there's no sense going back and forth about it here.

[Happy2Play 9780]

@@MikePlanet

 

Well aren't the images caches so they all reside in the cache folder (whether you store with media or not) and the drives don't need to spin up?  And how long would it be before providers put a lower limit on requests if users were to always be hitting there servers for image request?

[scheideggstrasse 0]

Sounds like the pooor quality version is in your media folder, possibly as a tbn file, correct?

 

yep. there is a 2KB .jpg stored in the media folder.

but this file is created by emby and not contained in the folder before indexing

[MikePlanet 144]

@@MikePlanet

 

Well aren't the images caches so they all reside in the cache folder (whether you store with media or not) and the drives don't need to spin up?  And how long would it be before providers put a lower limit on requests if users were to always be hitting there servers for image request?

Indeed, once they're cached it should be as you mentioned - but this would require to initially load everything - just to let it be cached. Otherwise whenever you open a view that still was not cached you're back to waiting for drive(s) to spin up. Actually, it is mostly an observation, I did not check any emby code to verify.

Re provider limits: You might have misunderstood me - I was not talking about pulling the images on demand from the providers, scraping should only be done once - my suggestion was to NOT link within the emby db to the media directory, but (once) pull image from internet provider and store it within (central) media folger - where all other media is also stored, when there is no local image existing. But I understood, that Luke is afraid too many ppl would complain about this behaviour change (which could be controlled by the setting to store media centrally or within the media folder!). Would be nice to get it as an option then, this would not change any (todays) default behaviour, but still alows to setup a system, that will NOT access any mediafolders except the playback itself.