-
Notifications
You must be signed in to change notification settings - Fork 14
Performance of large recordings view with tvscraper images #74
Description
When loading the recordings (especially the flat view) view with many recording loading the full sized images (just to display an 80px preview) takes a considerable amount of time. Although delayed loading is used, once I use the scrollbar most of the images load and put the WiFi interface to full load for a minute (with well used downtown WiFi channels at prime time). In the test case (no flat view) there are roughly 150 visible lines and about 100 distinct images. With an average size of ~500k we are talking about 50MB and about 10 times more browser memory for the uncompressed data.
Even with wired network the UI image load is quite slow. Larger images (> 1MB?) take more than one second in the HTTP request. This limits the throughput. No idea why.

The situation improves significantly when the images are in the browser cache. But even in this case it remains sluggish.
I would recommend to reduce the thumbnails at the server side. Maybe pass up to 160 pixel to the client to have some headroom for high DPI displays.
I had a rough look where this could be implemented. The content component seems to map directly to the tvscraper cache directory.
The most simple solution might be to store only reduced images in this cache. But I don't know whether this data is required with high quality for other purposes. Tvscraper also could store the original images and the thumbnails in the cache. But due to the browser cache it might not be necessary to keep the reduced image derivatives at the server.
Another option might be an additional URL parameter in the content component in order to request a thumbnail instead of the original image.
All options probably require an additional library dependency. Or are there any image scaling functions included in the vdr core?