Jump to content

viewing images generates high CPU


plessers@gmail.com

Recommended Posts

plessers@gmail.com

Hello,

 

I have following issue:

- picture library with "normal" pictures (approx 2000x4000 pixels, 4MB size)

- when entering the folder containing the pictures, my CPU hits 100%

594d8c0079f74_20170623233701.png

 

 

Running Version 3.2.20.0 on a WIN10 box

Thumbs are not cached. Every new session in a browser generates the same problem

 

 

Is there anything to do about it?

Pushing my server in overdrive every time I want to display a picture makes it impossible to use.

 

kind regards,

Bart

 

 

 

 

 

  • Like 1
Link to comment
Share on other sites

Images that large will take time to process. They are certainly cached - check the request & response headers.

Link to comment
Share on other sites

plessers@gmail.com

Hi Luke,

I meant server-side-caching. Is this also the case?

 

If I taken another client (let's say Emby Theatre application), the same weird behavior. Some pictures (in my case the first 2, and last 20 or so) are only shown after a while. High CPU at server.

Does Emby generates thumbs for the previews? Do they have to be generated everytime a client connects (which would explain the high CPU) ? Or are they server-side cached?

 

 

kind regards

Bart

Link to comment
Share on other sites

  • 2 years later...
mselley

Sorry to drag up an old thread, but did you ever get to the bottom of this? Tried using emby for my photos, but both machines I have tried max the cpu on loading images and thumbs and is way too slow to use.

Both low powered a 2 series i3 and a N40L but still would expect a bit quicker. Doesn't appear to be caching anything on the server end.

Link to comment
Share on other sites

mselley

Hi,

 

Server log attached. During the log i loaded a folder of photos on android, then again in the browser.

Both times maxed out the cpu rendering thumbnails.

Using an i5-2400 for the machine.

 

Images are all JPG and range between 3mb and 6mb all shot from the same camera at 4608x3456

 

Thanks

Emby Image Log.txt

Link to comment
Share on other sites

Hi, and if you pull up that same folder again with those apps, how does it compare?

Link to comment
Share on other sites

mselley

Hi,
 

So did some more testing and there are a few parts to this. (Browser cache was disabled for this test otherwise it would just retrieve the images from the disk cache. Also stuck to browser testing with chrome)

 

The initial load of the thumbnails of a particular resolution are taking between 1-5 second to generate is this expected? (The cause of the really long render times like the 4-5 seconds are all portrait images. Which take about 5x the amount of time a landscape image is taking.)

 

After the first load of the thumbnails the server is caching these and i am getting 1-3 ms responses.

2019-07-26 07:20:50.800 Info HttpServer: HTTP Response 200 to 192.168.1.61. Time: 1ms. http://192.168.1.200:8096/emby/Items/2842/Images/Primary?maxHeight=212&maxWidth=282&tag=6157ab6c2e11e6a46782b585946f8f94&quality=90

This is great, is there any documentation on the cache like how large does it go(is it configurable) or is it time based etc?

 

On a side optimisation note, i noticed the thumbnails are generated by exact resolution rather than a ranges or using a tolerance, eg large medium small. So if the browser size is changed by a couple of pixels which causes the thumbnails on the page the change size by a few pixels then the server will go away and regenerate all of these again taking 1-5 seconds an image. Would it make sense to work on a range basis, as the transfer size is negligible between a few pixels and then the image resizing to the exact thumbnail size is offloaded to the client which again is minimal. 

I have put some examples below, you can see the last request is only 1 pixel different to the previous one taking another 4 second to render.

2019-07-26 07:13:00.124 Info HttpServer: HTTP Response 200 to 192.168.1.61. Time: 4542ms. http://192.168.1.200:8096/emby/Items/2777/Images/Primary?maxHeight=209&maxWidth=278&tag=552c5873880a860874a1ae556fb5a22a&quality=90
2019-07-26 07:16:08.560 Info HttpServer: HTTP Response 200 to 192.168.1.61. Time: 1ms. http://192.168.1.200:8096/emby/Items/2777/Images/Primary?maxHeight=217&maxWidth=289&tag=552c5873880a860874a1ae556fb5a22a&quality=90
2019-07-26 07:16:56.573 Info HttpServer: HTTP Response 200 to 192.168.1.61. Time: 1ms. http://192.168.1.200:8096/emby/Items/2777/Images/Primary?maxHeight=217&maxWidth=289&tag=552c5873880a860874a1ae556fb5a22a&quality=90
2019-07-26 07:17:29.933 Info HttpServer: HTTP Response 200 to 192.168.1.61. Time: 4926ms. http://192.168.1.200:8096/emby/Items/2777/Images/Primary?maxHeight=212&maxWidth=283&tag=552c5873880a860874a1ae556fb5a22a&quality=90
2019-07-26 07:18:15.684 Info HttpServer: HTTP Response 200 to 192.168.1.61. Time: 2ms. http://192.168.1.200:8096/emby/Items/2777/Images/Primary?maxHeight=212&maxWidth=283&tag=552c5873880a860874a1ae556fb5a22a&quality=90
2019-07-26 07:18:38.563 Info HttpServer: HTTP Response 200 to 192.168.1.61. Time: 1ms. http://192.168.1.200:8096/emby/Items/2777/Images/Primary?maxHeight=212&maxWidth=283&tag=552c5873880a860874a1ae556fb5a22a&quality=90
2019-07-26 07:19:44.520 Info HttpServer: HTTP Response 200 to 192.168.1.61. Time: 4428ms. http://192.168.1.200:8096/emby/Items/2777/Images/Primary?maxHeight=212&maxWidth=282&tag=552c5873880a860874a1ae556fb5a22a&quality=90
2019-07-26 07:20:49.970 Info HttpServer: HTTP Response 200 to 192.168.1.61. Time: 2ms. http://192.168.1.200:8096/emby/Items/2777/Images/Primary?maxHeight=212&maxWidth=282&tag=552c5873880a860874a1ae556fb5a22a&quality=90

The main issue with the caching on the sizes being this exact is that it ends up being device specific, which kind of defeats the purpose of the server side cache. Even devices with the same screen resolution but another user having an extra toolbar in the browser will cause the size difference.

 

Also if the thumbnail cache was built using ranges or using a tolerance, eg large medium small, then it would be amazing to have the ability to get the server to go pre-cache all of these thumbnails for a given library when crawling, obviously this would be an optional setting due to the time and disk space required to cache large libraries.

 

Sorry a lot of questions.

Thanks in advance.

Edited by mselley
Link to comment
Share on other sites

Hi, cache files older than 30 days are recycled.

 

Yes the sizing is something that needs to be looked at, but it should require more than a few pixel changes to have the browser request different sizes.

Link to comment
Share on other sites

mselley

What are your thoughts on the up to 5 seconds for the initial thumb generation?

Also any thoughts on having the ability to pre cache thumbnails on library scan?

Link to comment
Share on other sites

That is a long time yes, but these are big images. But yes I agree that some improvement is needed.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...