Enhancing how photos thumbnails are loaded

[mselley 6]

Just following on from a thread with some feature suggestions from the issues im facing.

For reference the CPU used in this test was a i5 2400 and the images were all JPG and range between 3mb and 6mb all shot from the same camera at 4608x3456

 

First part is looking at the thumbnail generation as it is taking quite a long time with initial load of the thumbnails of a particular resolution are taking between 1-5 second to generate. With the really long render times like the 4-5 seconds are all portrait images. These are taking 5 times longer to render.

Looks like the way these are generated could do with some enhancement.

 

The second and main part is the thumbnail caching on the server.

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

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 theory is fine until we dig a little deeper to see how these are being handled. I noticed the thumbnails are generated by exact resolution. So if the browser size is changed by a couple of pixels which causes the thumbnails on the page to change size by a few pixels then the server will go away and regenerate all of these again taking 1-5 seconds an image.

 

I have put some examples below to show what currently happens,as 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.

 

The other issue is the cache that is used for these thumbnails is only valid for 30 days. This means as with photo albums that i may not look at again for a few months so i will have to wait all over again.

 

I would suggest that it makes 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. This could be something like Large Medium Small. Any client side request for thumbnails within the size range of one of those three will get served up.

 

This also means that we could Pre-Cache all the thumbnails for a given library. This would have a huge performance increase for viewing photo libraries with Emby. This would be an optional setting due to the time and disk space required to perform this when a library is scanned.

 

I am not sure how thumbnails are handled for Videos and Music, but this may or may not be relevant to those too.

Edited July 30, 2019 by mselley

[Luke 37191]

Yes there are improvements we can make here. Thanks for the feedback.

[mselley 6]

Great thanks for that luke, this will be a direct sell for me to buy a lifetime premiere, so that my family can sync and view our photos.

[Baenwort 97]

I'd like to agree that it would be great to allow a toggle on cache persistence. This explains so much about why photo folder performance is so inconsistent. 

 

I like the idea of using Emby as a photo viewer and display but right now between the in ability to chose between jpg, raw, or both along with the long loading times for photo folders with large numbers of picture it makes it painful to use. 

[mselley 6]

Hi Luke,

 

Just following up on this if there have been/planned in any improvements to this part of the system? I would really like to use this software to share photos with family, but currently its just too slow.

Thanks

[Luke 37191]

I think performance will be slightly improved in regards to this in the upcoming 4.4 release, although the development was not specific to photos and certainly not specific to images falling between 3mb and 6mb. But the general improvements that have been made may help a little with this, but I think more is still needed in order to be able to better handle large photos of this size.

[mselley 6]

Thanks for the Update Luke, do you know if there is an issue logged in Github for this i can follow just so i dont have to pester you here?

[Luke 37191]

You can file one or keep the discussion here, either is fine. The next release of emby server will update to a new version of the skia graphics library which may help.

[mselley 6]

Thanks Luke, i have submitted a issue on github to track https://github.com/MediaBrowser/Emby/issues/3626
I will be following the updates to the next release of emby hopefully the performance increases with the new graphics library.

[luisgreen 0]

In the meanwhile I wrote this gist that helps to cache the thumbnails inside an NGINX container and REALLY accelerate the load times.

https://gist.github.com/luisgreen/7f98f90d7d934ed8081eb802c156c7a9

Maybe @Luke and @mselley can take a look at it to alleviate his server as I did. I still have no metrics as I did just today.

Hope this helps.

 

Edited August 6, 2020 by luisgreen
Spelling

[Carlo 4331]

On 7/30/2019 at 2:31 PM, mselley said:

Great thanks for that luke, this will be a direct sell for me to buy a lifetime premiere, so that my family can sync and view our photos.

 

On 3/5/2020 at 5:16 PM, mselley said:

Hi Luke,

 

Just following up on this if there have been/planned in any improvements to this part of the system? I would really like to use this software to share photos with family, but currently its just too slow.

Thanks

If you were thinking about registering a domain to use with your Emby Server this can help you out in multiple ways.

First a domain name is cool to have and people just input your domain instead of having to remember IPs or using Emby Connect.

2nd you can setup your Emby Server behind Cloudflare which adds additional security and caching so images (all posters, pictures, fanart) get cached at the CDN level and load nearly instantly which makes your system seem very fast. Fixes this issue as a by-product of caching images.

3rd you can have Cloudflare generate a cert that can be used in Emby Server to enforce SSL/https for added protection and encryption.

I can help you with this remotely as I've got it down to a science and can fly through it quickly.

Let me know if this is something you would want to do.

Carlo

[Baenwort 97]

I was told by Cloudflare that video hosts should not be placed behind them as it is against the T&C to serve primarily non-html data.  https://community.cloudflare.com/t/is-plex-allowed/172158/5

Is this different for Emby or does Emby hide it some how?

I have my own domain and I'm always looking for ways to beef up my security.

[Carlo 4331]

That's cause some of the knuckleheads probably tried to set it up to cache the videos which is a NO, NO.

I setup page rules for html and graphics only.  All video get's served from your Emby Server.

So from that context you are essentially only caching a website (sans video) or equivalent content which they say is fine as you wouldn't be using it like a "video host".

As far as I know all Emby clients pull pictures and graphics via http or https which are "web page requests" to specific images just as they would be embedded in a web page.

Plex and Emby do things a bit differently and Emby acts more like a conventional webpage/web server.

With that said I wouldn't go and start asking questions because I person answering that doesn't understand the setup you are using will jump to the wrong conclusions or think "problem Plex installation" when if fact it's not like that at all.

When I get my bandwidth report at the end of the month it's not reporting TB of info or even GB but MB of data so it's just serving HTML and images in the context I use.  I'm sure some twitter pages or Facebook pages use far more data than my site.

You could also run your own proxy to do the same as Cloudflare does but everything is still delivered via your network vs the CDN (content delivery network) but it will still increase the speed of photo and graphic delivery since it has a static version of the content.

 

Edited August 6, 2020 by cayars