Emby spin up all drives to show posters

[VoNpo 2]

Hi,

 

Stats:

- UnRAID based NAS with emby docker.

- Dedicated SSD for emby (appdata, metadata, transcode etc.)

- Images and .nfo files are located with media files.

- I'm keeping drives at spin down most of the time because of noise and power consumption. (I know that spin up is most stessful for HDD and for best reliability those NAS drives should be run 24/7.)

 

Problem is that emby seems to load all posters from HDD, not from dedicated SSD where it should be.

When I open emby, there is no posters and I can see and hear my rack mounted nas to spin up drives one by one to show those posters.

 

Is there any way to stop this happening and force emby to use SSD only?

Is it possible that I'm missing some setting from my emby server?

 

EDIT:

Log shows that kind of message for all files located in that library during spin up:

 

Info HttpServer: HTTP Response 200 to 192.168.1.55. Time: 50ms. http :// 192.168.1.60:8096/emby/Items/6362/Images/Primary?maxHeight=343&maxWidth=229&tag=xxxxxxxxxxx&quality=90

Info HttpServer: HTTP GET http :// 192.168.1.60:8096/emby/Items/6363/Images/Primary?maxHeight=343&maxWidth=229&tag=xxxxxxxxxxx&quality=90. UserAgent: Mozilla/5.0 (Windows NT 10.0; rv:68.0) Gecko/20100101 Firefox/68.0
Debug ImageProcessor: Image encoding took 42ms for /mnt/Movies/....

Edited March 16, 2020 by VoNpo

[maegibbons 1287]

Are you not storing images with your media?

 

Krs

 

Mark

 

Sent from my SM-N976B using Tapatalk

[VoNpo 2]

Images and nfo file are stored in same folder with video file.

From library settings; Metadata savers: nfo and "save artwork into media folders" are checked.

 

Dedicated SSD have a cache folder which includes resized images, but somehow they are not used.

Edited March 16, 2020 by VoNpo

[PenkethBoy 2068]

Looks to me that your cached file had expired - so emby was recreating it - hence need to go get the original from your media folders

 

i.e. Debug ImageProcessor: Image encoding took....

 

emby does this periodically - IIRC 30 days for cached images

[VoNpo 2]

Looks to me that your cached file had expired - so emby was recreating it - hence need to go get the original from your media folders

 

i.e. Debug ImageProcessor: Image encoding took....

 

emby does this periodically - IIRC 30 days for cached images

Somehow it does that image encoding every time when disk(s) are spin down.

Just tried to spin drives down manually and opened emby library again from brower (didn't restart browser, just going back and forth of libraries)

 

Edited March 16, 2020 by VoNpo

[zachmann 1]

I have the same problem. Unraid spins my drives down after a specific amount of time. At the spin down status emby shows only a few Covers / Thumbnails. After logging into emby all drives spin up and the images appear. 

Debug log says:

2020-03-23 14:18:53.180 Info HttpServer: HTTP GET http://192.168.178.120:8096/emby/Items/48169/Images/Primary?maxHeight=285&maxWidth=190&tag=b9f2a418fa4587134b42e931e85a31b5&quality=90. UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.149 Safari/537.36 Edg/80.0.361.69
2020-03-23 14:18:53.186 Debug ImageProcessor: Image encoding took 295ms for /mnt/Serien/Unser Planet/poster.jpg

This behaviour occurs every time. Is there a setting we missed or is it a bug and should the images be in the emby cache?

 

extra info:

- My emby docker is installed on a cache m2 ssd raid under Unraid. 

- Images are stored with the movie/series files

 

 

 

 

Looks to me that your cached file had expired - so emby was recreating it - hence need to go get the original from your media folders

 

i.e. Debug ImageProcessor: Image encoding took....

 

emby does this periodically - IIRC 30 days for cached images

 

if the cache is outdated why does emby "new image processing" of the same images everytime the disks are spined down?

Edited March 23, 2020 by zachmann

[Luke 42078]

are you clearing the contents of the server's cache folder?

[VoNpo 2]

No, should I do that manually at time to time somehow?

My whole emby folder in server side uses ~800MB of 256GB (Dedicated SSD)

[PenkethBoy 2068]

 

 

if the cache is outdated why does emby "new image processing" of the same images everytime the disks are spined down?

this does not occur for me - have check the last 10 days of my logs and the files processed are not the same ones each time

 

do you have your browser clear its cache - or any plugins that do this or in incognito mode perhaps? 

 

and i assume your emby cache directory is separate to your HDD ?

[zachmann 1]

are you clearing the contents of the server's cache folder?

 

No, should I do that manually at time to time somehow?

My whole emby folder in server side uses ~800MB of 256GB (Dedicated SSD)

 

Neither do I.

Cache resides with the whole Emby Dcoker on SSDs (Cache drives under Unraid in my setup are two nvme m2 ssd in raid1).

 

 

this does not occur for me - have check the last 10 days of my logs and the files processed are not the same ones each time

 

do you have your browser clear its cache - or any plugins that do this or in incognito mode perhaps? 

 

and i assume your emby cache directory is separate to your HDD ?

 

No, no browser and no plugin ist clearing cache plus this behaviour also appears by using the Emby Apps for Android and Windows.

 

Setup is:

- emby official Docker

- all Emby Data and Cache are on my Unradi ssd cache volume (Cache drives under Unraid in my setup are two nvme m2 ssd in raid1)

- transcoding directory resides in RAM.

 

Maybe I have to change my settings to let emby make more thumbnails?

[PenkethBoy 2068]

there are no settings for the cache to change 

 

thumbnails for chapters do have options but this is something different

 

maybe unraid/docker specific

 

but how you describe your setup should work

[zachmann 1]

I love emby and how flawless it works, but this behaviour is a big problem. 

Is there any other idea? I can provide all logs and settings I made to help analysing the "error".

 

 

are you clearing the contents of the server's cache folder?

 

Should I do it manually maybe to let emby rebuild the whole cache?

 

I don't know how the cache folder should look like. I would like to show how mine looks like, but I can't add an image. Site won't accept an image in my post, so here it is:

https://imageshack.com/i/powbfyNkp

 

surprising to me is the modified date of my images folder

Edited March 24, 2020 by zachmann

[Happy2Play 9780]

And why would the date on that folder have any relevance?  Now the folders within that directory is another story.

 

[zachmann 1]

My fault, inside the images folder the folders 0,1,2, etc. are up to date.

But I dont have a folder called "coverart" as in your image, the covers are what gets loaded every time. Is there a setting or should it be always in this folder?

[PenkethBoy 2068]

Not related - coverart folder is created by the coverart plugin

[zachmann 1]

Ok... are there any other hints? 

As mentioned before I can provide all kinds of logs and settings I made. I really have to get this fixed. Otherwise, my hard drives could break down much faster than usual. There has to be a possibility. If it's a docker/unraid thing. I can get a ubuntu vm up and running for emby if that helps.

[Jdiesel 1431]

There are a lot of myths and bad information out there about the benefits and spinning down drives versus leaving them running. Unless drives are going unused for extended periods of time (days not hours), you have thermal issues, or need to reduced noise from drives due to the location of the server, the benefits of spinning down drives is not enough to outweigh the issues, complications, and performance hit.

 

Not is say that troubleshooting why Emby is recreating the image cache each time isn't worthwhile though.

Edited March 25, 2020 by Jdiesel

[zachmann 1]

I know, I'm working as an system administrator. The only benefit of spinning down is not using that much electricity, dont pay so much for it. But paying an extra of 50€/year for not spinning the drives up and down is a lot of money. Maybe the better choice, if the drives crash earlier caused by spinning down and up it could cost more than the 50€/year. Maybe I will let them spin.

 

BUT

 

The question is why is the cache not working as intended?

 

@@Luke

Do you need further logs or anything to get a clue?

I wonder if its really related to docker and Unraid host?

[Luke 42078]

 

 

The question is why is the cache not working as intended?

It does work, it's just that different devices will need the images in different sizes or formats, so that means the cache isn't always shared from one device to another.

 

What we could do to fully prevent this would be to store a full copy of the original in the server's cache folder, and then we'd never need to touch the drives. There are open feature requests for us to do this.

[Happy2Play 9780]

That is why users that do not store images with media have a slight advantage in this area, but from a rebuild standpoint is a negative as all images have to be redownloaded.

[zachmann 1]

It does work, it's just that different devices will need the images in different sizes or formats, so that means the cache isn't always shared from one device to another.

 

What we could do to fully prevent this would be to store a full copy of the original in the server's cache folder, and then we'd never need to touch the drives. There are open feature requests for us to do this.

Ok I understand. Is there any idea / timeline when this feature will be released or at least be worked on?

Where can I follow the progress of those feature requests?

 

 

That is why users that do not store images with media have a slight advantage in this area, but from a rebuild standpoint is a negative as all images have to be redownloaded.

 

I know, but I have plenty of customized images. A rebuild by simple download with emby is not an option for my collection.

[VoNpo 2]

It does work, it's just that different devices will need the images in different sizes or formats, so that means the cache isn't always shared from one device to another.

 

What we could do to fully prevent this would be to store a full copy of the original in the server's cache folder, and then we'd never need to touch the drives. There are open feature requests for us to do this.

Understand that, but I think there is still problem (don't know is it emby, docker or unraid related)

If browser is kept open and in same size/position, there should not be need to resize poster image, right?

But even in that case, image will be loaded from drive and encoded if drive is spin down when going back and forth emby libraries. If drive is not stopped, there is no image encoding in log file.

 

Anyways, storing original size images in cache should solve all these problems. Big thumb up for that feature!

[trott90 20]

On 27/03/2020 at 09:55, Luke said:

It does work, it's just that different devices will need the images in different sizes or formats, so that means the cache isn't always shared from one device to another.

 

What we could do to fully prevent this would be to store a full copy of the original in the server's cache folder, and then we'd never need to touch the drives. There are open feature requests for us to do this.

how about this request? I cannot find it in  Feature Requests forum

[Luke 42078]

@AdrianW has an open feature request about it.

[AdrianW 1058]

Looks like @trott90 already found the request.

Here's the link for anyone else reading this thread: Preemptively cache images