poor performance image processor emby slide show

[MatthiasM 6]

Hello comunity

as I become more and more productive with my private photos and emby I remark often a time lag starting a slide show with my LG TV and/or a web browser.

Now I did a little deep dive into that situation and found that the internal image processor within emby needs a long time to resize the processed images/photos.

Nearly 5s is needed to build a scaled image and during this 5s a blank screen is showed up. Same if I skip an image forward.

The image (2.2 MB .jpg) I choose as example isn't that big and the hardware emby is running on isn't that weak (Synology DS920+ 8GB RAM and SSD cache).

emby is 4.6.4.0 latest greatest. Synology is DSM Version: 6.2.4-25556. The example imgage is attached.

I hope for some tuning tips

Thanks and regards

Matthias

 

The system monitor shows some action but no overload:

here is what the emby log showed up (debug mode on):

2021-08-20 09:51:03.551 Info Server: http/1.1 GET http://192.168.1.1:7070/emby/Users/71cac90c0d7e4912a3b2fc799bd5f217/Items?ParentId=208271&Filters=IsNotFolder&Recursive=false&SortBy=SortName&Limit=5000&Fields=Chapters,ProductionYear,PremiereDate&ExcludeLocationTypes=Virtual&EnableTotalRecordCount=false&CollapseBoxSetItems=false&X-Emby-Client=Emby Web&X-Emby-Device-Name=Firefox&X-Emby-Device-Id=TW96aWxsYS81LjAgKFdpbmRvd3MgTlQgMTAuMDsgV2luNjQ7IHg2NDsgcnY6NzAuMCkgR2Vja28vMjAxMDAxMDEgRmlyZWZveC83MC4wfDE1NzM4ODc0Nzc1NDY1&X-Emby-Client-Version=4.6.4.0. UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Firefox/91.0
2021-08-20 09:51:03.553 Debug SqliteItemRepository: Public GetItemLinks
2021-08-20 09:51:03.553 Debug SqliteItemRepository: Public GetItemLinks
2021-08-20 09:51:03.553 Debug SqliteItemRepository: Public GetItemLinks
2021-08-20 09:51:03.553 Debug SqliteItemRepository: Public GetItemLinks
2021-08-20 09:51:03.553 Debug SqliteItemRepository: Public GetItemLinks
2021-08-20 09:51:03.553 Debug SqliteItemRepository: Public GetItemLinks
2021-08-20 09:51:03.554 Info Server: http/1.1 Response 200 to 192.168.1.4. Time: 3ms. http://192.168.1.1:7070/emby/Users/71cac90c0d7e4912a3b2fc799bd5f217/Items?ParentId=208271&Filters=IsNotFolder&Recursive=false&SortBy=SortName&Limit=5000&Fields=Chapters,ProductionYear,PremiereDate&ExcludeLocationTypes=Virtual&EnableTotalRecordCount=false&CollapseBoxSetItems=false&X-Emby-Client=Emby Web&X-Emby-Device-Name=Firefox&X-Emby-Device-Id=TW96aWxsYS81LjAgKFdpbmRvd3MgTlQgMTAuMDsgV2luNjQ7IHg2NDsgcnY6NzAuMCkgR2Vja28vMjAxMDAxMDEgRmlyZWZveC83MC4wfDE1NzM4ODc0Nzc1NDY1&X-Emby-Client-Version=4.6.4.0
2021-08-20 09:51:03.571 Info Server: http/1.1 GET http://192.168.1.1:7070/emby/Items/337047/Images/Primary?maxWidth=3840&tag=e2b5ce0a18dc887e1b3490211bc12c23&quality=90. UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Firefox/91.0
2021-08-20 09:51:03.571 Info Server: http/1.1 GET http://192.168.1.1:7070/emby/Users/71cac90c0d7e4912a3b2fc799bd5f217?X-Emby-Client=Emby Web&X-Emby-Device-Name=Firefox&X-Emby-Device-Id=TW96aWxsYS81LjAgKFdpbmRvd3MgTlQgMTAuMDsgV2luNjQ7IHg2NDsgcnY6NzAuMCkgR2Vja28vMjAxMDAxMDEgRmlyZWZveC83MC4wfDE1NzM4ODc0Nzc1NDY1&X-Emby-Client-Version=4.6.4.0. UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Firefox/91.0
2021-08-20 09:51:03.572 Debug SqliteItemRepository: Public GetItemLinks
2021-08-20 09:51:03.572 Info Server: http/1.1 Response 200 to 192.168.1.4. Time: 1ms. http://192.168.1.1:7070/emby/Users/71cac90c0d7e4912a3b2fc799bd5f217?X-Emby-Client=Emby Web&X-Emby-Device-Name=Firefox&X-Emby-Device-Id=TW96aWxsYS81LjAgKFdpbmRvd3MgTlQgMTAuMDsgV2luNjQ7IHg2NDsgcnY6NzAuMCkgR2Vja28vMjAxMDAxMDEgRmlyZWZveC83MC4wfDE1NzM4ODc0Nzc1NDY1&X-Emby-Client-Version=4.6.4.0
2021-08-20 09:51:03.576 Info Server: http/1.1 GET http://192.168.1.1:7070/emby/Items/337048/Images/Primary?maxWidth=3840&tag=92fcacd0ecc18130a8cf8fe40c5564ad&quality=90. UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Firefox/91.0
2021-08-20 09:51:03.579 Debug SqliteItemRepository: Public GetItemLinks
2021-08-20 09:51:03.580 Info Server: http/1.1 GET http://192.168.1.1:7070/emby/Items/337052/Images/Primary?maxWidth=3840&tag=5db4a0f2a06154d535f51aeda6f0c860&quality=90. UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Firefox/91.0
2021-08-20 09:51:03.580 Debug SqliteItemRepository: Public GetItemLinks
2021-08-20 09:51:08.383 Debug ImageProcessor: Image encoding to /volume1/Emby/cache/images/resized-images/4/4b4faddb-9b33-b3ed-30cb-6c7a6dfd1e0e.webp took 4811ms for /volume1/fotos/2017/2017-02-12/2017-02-12-12h58m33.jpg
2021-08-20 09:51:08.386 Info Server: http/1.1 Response 200 to 192.168.1.4. Time: 4815ms. http://192.168.1.1:7070/emby/Items/337047/Images/Primary?maxWidth=3840&tag=e2b5ce0a18dc887e1b3490211bc12c23&quality=90
2021-08-20 09:51:08.402 Debug ImageProcessor: Image encoding to /volume1/Emby/cache/images/resized-images/b/b925c086-2bd3-045f-71e3-05e5f1a76190.webp took 4822ms for /volume1/fotos/2017/2017-02-12/2017-02-12-12h58m40.jpg
2021-08-20 09:51:08.414 Debug ImageProcessor: Image encoding to /volume1/Emby/cache/images/resized-images/4/4b893ab7-0f18-120c-198f-528abd4406ae.webp took 4833ms for /volume1/fotos/2017/2017-02-12/2017-02-12-14h47m28-1.jpg
2021-08-20 09:51:08.415 Info Server: http/1.1 Response 200 to 192.168.1.4. Time: 4839ms. http://192.168.1.1:7070/emby/Items/337048/Images/Primary?maxWidth=3840&tag=92fcacd0ecc18130a8cf8fe40c5564ad&quality=90
2021-08-20 09:51:08.416 Info Server: http/1.1 Response 200 to 192.168.1.4. Time: 4837ms. http://192.168.1.1:7070/emby/Items/337052/Images/Primary?maxWidth=3840&tag=5db4a0f2a06154d535f51aeda6f0c860&quality=90
2021-08-20 09:51:09.452 Info Server: http/1.1 POST http://192.168.1.1:7070/emby/Sessions/Playing/Stopped?X-Emby-Client=Emby Web&X-Emby-Device-Name=Firefox&X-Emby-Device-Id=TW96aWxsYS81LjAgKFdpbmRvd3MgTlQgMTAuMDsgV2luNjQ7IHg2NDsgcnY6NzAuMCkgR2Vja28vMjAxMDAxMDEgRmlyZWZveC83MC4wfDE1NzM4ODc0Nzc1NDY1&X-Emby-Client-Version=4.6.4.0. UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Firefox/91.0
2021-08-20 09:51:09.453 Debug App: ReportPlaybackStopped PlaySessionId:
2021-08-20 09:51:09.454 Debug SqliteItemRepository: Public GetItemLinks
2021-08-20 09:51:09.454 Info SessionManager: Playback stopped reported by app Emby Web 4.6.4.0 playing 2017-02-12-12h58m33. Stopped at unknown ms

 

 

 

 

[Carlo 4561]

Hi, this should only happen I believe the first time you view one of the images.  After that it should be in the cache and load a lot faster.

Have you found this to be the case?

[MatthiasM 6]

Thanks for the feedback cayars.

Thats right, if the images has cached and the image processing is not longer nessesary, the load of it will be mutch more faster.

But this is not the real usecase. My opinion is that the image procession engine is not correct configured or it use weak routines for the resizing.

Best regards

Matthias

[Luke 42079]

Hi there, please attach the complete server log file. thanks.

[MatthiasM 6]

Hi Luke

I did a fresh restart of emby with debug protokoll switched to on and found some photos that needs long to resize and that are not already cached.

The example image and the whole server log ist attached.

2021-08-21 21:08:36.660 Debug SqliteItemRepository: Public GetItemLinks
2021-08-21 21:08:40.957 Debug ImageProcessor: Image encoding to /volume1/Emby/cache/images/resized-images/4/4de531d4-de9d-21b3-6109-4a4bb1959ed2.webp took 5240ms for /volume1/fotos/2009/2009-08 NOS-Kanal/2009-08-23-14h06m14.jpg
2021-08-21 21:08:40.976 Info Server: http/1.1 Response 200 to 192.168.1.4. Time: 5260ms. http://192.168.1.1:7070/emby/Items/318651/Images/Primary?maxWidth=3840&tag=471dcfab6322bef9af679bd839577a76&quality=90
2021-08-21 21:08:41.587 Debug ImageProcessor: Image encoding to /volume1/Emby/cache/images/resized-images/9/929d9b24-06e8-808a-c941-284117efd09c.webp took 4926ms for /volume1/fotos/2009/2009-08 NOS-Kanal/2009-08-23-14h05m40.jpg
2021-08-21 21:08:41.600 Info Server: http/1.1 Response 200 to 192.168.1.4. Time: 4940ms. http://192.168.1.1:7070/emby/Items/318650/Images/Primary?maxWidth=3840&tag=07f43f8a9a8637f775b299a564f64ab2&quality=90
2021-08-21 21:08:49.003 Info Server: http/1.1 POST http://192.168.1.1:7070/emby/Sessions/Playing/Stopped?X-Emby-Client=Emby Web&X-Emby-Device-Name=Firefox&X-Emby-Device-Id=TW96aWxsYS81LjAgKFdpbmRvd3MgTlQgMTAuMDsgV2luNjQ7IHg2NDsgcnY6NzAuMCkgR2Vja28vMjAxMDAxMDEgRmlyZWZveC83MC4wfDE1NzM4ODc0Nzc1NDY1&X-Emby-Client-Version=4.6.4.0. UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Firefox/91.0
2021-08-21 21:08:49.005 Debug App: ReportPlaybackStopped PlaySessionId:

 

embyserver.txt

[ebr 16184]

Where does the original image reside?  Network drive?  Possibly sleeping drive?

[jamessouth 1]

Loading and resizing a multi megapixel jpeg can take a while but 4926ms seems quite slow to me.

Looking at the CPU for the 920+ There's a lack of AVX support which will certainly limit performance however without knowing the underlying libraries used (nor having access to the original image, the posted example appears to be resized by the forum?) I cannot really comment in detail. 

I would be interested to see what performance difference there is taking WebP out of the equation though? Historically it has been slower than jpeg for both decoding and encoding. 

Image processing is my jam. I own the .NET project ImageSharp so have hefty experience in this domain.

Edited August 22, 2021 by jamessouth
Creds

[MatthiasM 6]

Gentemen, thx for your time!

@ebr the files are located local at the NAS. RAID1 2 HDDs with SSD cache active, no power save spin down while I did the test.

@jamessouth you are right, the forum engine did resize my example images, I now attach a ZIP with the origin images for your tests. The CPU do a realtime encoding of a full HD video stream, there is enough power it is a Intel Celeron J4125 4-core 2.7 GHz CPU

Best regards

Matthias

images.zip

[Luke 42079]

I would try removing the coverart plugin, then restart the server and see if that helps.

[ebr 16184]

16 hours ago, Luke said:

I would try removing the coverart plugin, then restart the server and see if that helps.

This will be an interesting test but CA completely ignores photos.

[MatthiasM 6]

Gentlemen, I did exact what you asking for - deinstall the plugin, restart emby and again proof the lag the resizing add on, no difference.

2021-08-23 17:42:30.963 Debug ImageProcessor: Image encoding to /volume1/Emby/cache/images/resized-images/5/52b6d010-767a-5e7a-65b9-69565f70f7ca.webp took 4281ms for /volume1/fotos/2009/2009-03 Neumünster/2009-03-07-17h31m55.jpg
2021-08-23 17:42:30.966 Info Server: http/1.1 Response 200 to 192.168.1.4. Time: 4286ms. http://192.168.1.222:7070/emby/Items/318368/Images/Primary?maxWidth=3840&tag=525184a69f519c2e19daa07c9b9745ed&quality=90
2021-08-23 17:42:31.103 Debug ImageProcessor: Image encoding to /volume1/Emby/cache/images/resized-images/e/e9ca8b3a-a843-89f9-13af-332f8f7af623.webp took 4422ms for /volume1/fotos/2009/2009-03 Neumünster/2009-03-07-17h32m59.jpg
2021-08-23 17:42:31.107 Info Server: http/1.1 Response 200 to 192.168.1.4. Time: 4426ms. http://192.168.1.222:7070/emby/Items/318369/Images/Primary?maxWidth=3840&tag=decff17ef9cd94acc65234d9447e9bc0&quality=90
2021-08-23 17:42:31.362 Debug ImageProcessor: Image encoding to /volume1/Emby/cache/images/resized-images/f/f047e388-9fb8-1e5c-d025-ca8d5cd5a901.webp took 4679ms for /volume1/fotos/2009/2009-03 Neumünster/2009-03-07-17h36m42.jpg
2021-08-23 17:42:31.373 Info Server: http/1.1 Response 200 to 192.168.1.4. Time: 4690ms. http://192.168.1.222:7070/emby/Items/318382/Images/Primary?maxWidth=3840&tag=82342522a4ef407cc78f4e132f949402&quality=90

I reinstall the plugin now. @ebr CA is great and I don't wanna miss it

Best regards

Matthi

[MatthiasM 6]

@ebr can you please tell me where I can find the config file for CA? I have to restore it from backup to get my old settings.

Thanks

Matthias

[Happy2Play 9780]

11 minutes ago, MatthiasM said:

@ebr can you please tell me where I can find the config file for CA? I have to restore it from backup to get my old settings.

Thanks

Matthias

The same folder the plugin is located *\programdata\plugins\configurations.

In your case it should be "Data path: /volume1/Emby/plugins/configuration"

[MatthiasM 6]

got it, thx @Happy2Play

[MatthiasM 6]

Just an idea... under normal circumstances the client will do the resize of any image that is displayed.

It is possible to turn simply off the image resize emby does?

Thanky

Matthias

[Luke 42079]

28 minutes ago, MatthiasM said:

Just an idea... under normal circumstances the client will do the resize of any image that is displayed.

It is possible to turn simply off the image resize emby does?

Thanky

Matthias

There is currently no such option, and for some apps it would lead to memory problems and crashing due to delivering image sizes that they can't handle very well. 

[Luke 42079]

On 8/22/2021 at 9:54 AM, jamessouth said:

Loading and resizing a multi megapixel jpeg can take a while but 4926ms seems quite slow to me.

Looking at the CPU for the 920+ There's a lack of AVX support which will certainly limit performance however without knowing the underlying libraries used (nor having access to the original image, the posted example appears to be resized by the forum?) I cannot really comment in detail. 

I would be interested to see what performance difference there is taking WebP out of the equation though? Historically it has been slower than jpeg for both decoding and encoding. 

Image processing is my jam. I own the .NET project ImageSharp so have hefty experience in this domain.

HI @jamessouth, for reference we use SkiaSharp on most platforms.

[jamessouth 1]

Thanks  @Luke  SkiaSharp is usually pretty nippy across most platforms. I'll run some tests locally. 

If anyone wants to experiment here's a benchmark that several of us framework developers use to race each other on, It'd be useful as a basis for experimenting and comparing the current SkiSharp code against. https://github.com/bleroy/core-imaging-playground

[Luke 42079]

10 minutes ago, jamessouth said:

Thanks  @Luke  SkiaSharp is usually pretty nippy across most platforms. I'll run some tests locally. 

If anyone wants to experiment here's a benchmark that several of us framework developers use to race each other on, It'd be useful as a basis for experimenting and comparing the current SkiSharp code against. https://github.com/bleroy/core-imaging-playground

By the way based on your comments I did some tests and found that for very large images, encoding to webp was generally about 4-5X slower. In the beta server I've changed the encoding to not use webp when the originals are greater than 1080p.

[MatthiasM 6]

@luke @jamessouththx for keeping this topic alife!

Gentlemen, processing speed will not be the problem if there was a button for generating cached images for a specific resolution and for all fotos that have no cached version - a background worker task...- may 4k or HD.

The problem starts if you wanna show fotos from the last vacation to your Mom and your image show is slow like hell

thx

Matthias

[Luke 42079]

Sure, yes, but not everyone wants to pay that up front cost all at once with extra long library scans, so even if we had that feature, it still wouldn't spare us from having to make the conversion process as quick as possible.

[nguyenf1 8]

While viewing a photo in full screen, wouldn't pre-loading the next images in the album offer some improvement?  This wouldn't help if you skip forward faster then the system can preload, but should be better than the current implementation.

[Luke 42079]

13 hours ago, nguyenf1 said:

While viewing a photo in full screen, wouldn't pre-loading the next images in the album offer some improvement?  This wouldn't help if you skip forward faster then the system can preload, but should be better than the current implementation.

It would help yes.

[ebr 16184]

14 hours ago, nguyenf1 said:

While viewing a photo in full screen, wouldn't pre-loading the next images in the album offer some improvement?  This wouldn't help if you skip forward faster then the system can preload, but should be better than the current implementation.

FYI - the Android TV app does this now (when in slideshow mode).  I'd be interested if you see any perceived improvement from it.

[MatthiasM 6]

gentlemen there is one more aspect why this is sad.

If the image preprocessing needs lets say 4500ms and the auto show next image is set to 5000 ms you will see the image for 500ms.

If the image preprocessing needs 5500ms you will not see the image.

will say the timer of the slide show runs indipendently and do not recocnise is the images showed or not.

It will be cool it there is a setting where the user can change the time how long the image will be displayed.

Or maybe better the user can change those speed interactivly by increasing or decreasing the time while looking the images.

thx

Matthias