mirror of
https://github.com/jellyfin/jellyfin.git
synced 2026-01-23 23:20:51 +01:00
no thumbnails = Jellyfin unusable as photo album #1091
Labels
No labels
area:database
awaiting-feedback
backend
blocked
breaking change: web api
bug
build
ci
confirmed
discussion needed
dotnet future
downstream
duplicate
EFjellyfin.db
enhancement
feature
future
github-actions
good first issue
hdr
help wanted
invalid
investigation
librarydb
live-tv
lyrics
media playback
music
needs testing
nuget
performance
platform
pull-request
question
regression
release critical
requires-web
roadmap
security
security
stale
support
syncplay
ui & ux
upstream
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: starred/jellyfin#1091
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @gvhagopian on GitHub (Nov 28, 2019).
Describe the bug
I have about 6,000 jpeg images that I've scanned from negatives. They are about 15 MB each. I stored each roll of film in its own folder, so there are 200 folders in my image library. Jellyfin's approach to this problem apparently is to load 200x15MB worth of image files into the browser's memory when viewing the library. This completely schlongs the browser and the network connection. Even if I just open one folder, it still barely works because it loads the full sizes of every image in the folder into browser memory, even though it only shows 100KiB worth of that data in the thumbnails.
To Reproduce
Expected behavior
Jellyfin should have processed the images and created a database of different versions of each image, or even just a database of thumbnails would be a huge improvement. It should also only load thumbnails for the subdirectories in that library that are currently scrolled into view.
System (please complete the following information):
@JustAMan commented on GitHub (Nov 28, 2019):
I would classify this more as a feature request than a bug. We accept feature requests here: https://features.jellyfin.org/
@leepan8 commented on GitHub (Dec 26, 2019):
It looks that emby has support for thumbnail images that has the expected behavior described above.
@JustAMan commented on GitHub (Jan 10, 2020):
What Emby has or has not is irrelevant, we're completely separate.
@Nickbert7 commented on GitHub (Jan 10, 2020):
It worked in the past
With version 10.3.7 the images get served scaled:
On 10.4.3 I get the full images:
@Nickbert7 commented on GitHub (Jan 21, 2020):
Could it be caused by this PR? https://github.com/jellyfin/jellyfin-web/pull/512
@dkanada commented on GitHub (Jan 21, 2020):
I believe this has already been reverted on master for the list views.
@Nickbert7 commented on GitHub (Jan 21, 2020):
Also with the current jellyfin-web master I get the big files:
I cannot test it with the full nightly builds as I get another error if I scan the photo library:
I just tested a few old versions and it has to be something between 10.4.0 and 10.4.1
@Nickbert7 commented on GitHub (Jan 27, 2020):
Also for the list view (if you mean the list of all movies) the full posters are getting transferred. It takes over 30 MB to scroll through the first 100 movies.
If I go on to the movies 100 - 200 we are already over 70 MB:
@ferferga commented on GitHub (Feb 5, 2020):
Could you please see how much time does JavaScript execution takes for you?
Open developer tools in your browser (F12 normally) > Performance > Record. Reproduce the laggy stuff. Stop recording and see how much time did your browser take to process JavaScript. Attach an screenshot please.
@Nickbert7 commented on GitHub (Feb 5, 2020):
This is how it looks if I open an album in my photo library (web version is from the current nightly)
@ferferga commented on GitHub (Feb 5, 2020):
@Nickbert7 what about in movies/music and so on linraries? You both seem to have in common something I didn't expect when making the PR and they are photo libraries (I have none). DSLR or scanned photos have poor compression/quality ratio algorithms and they are definitely needed there. Posters from TMDB usually come with a really good compression algorithm. My fault for not thinking in that edge case.
Something server side should be applied, but also I'm thinking in making a plug-in that automatically runs a scheduled task to optimize media image's of metadata.
Modern browsers are really good showing many huge photos, the problem is that 15 MB/photo is too much. Also, the scripting we inherited from emby chogs things a lot (try it yourself, load the same amount of images in a HTML and check how much quicker it is with the same amount of photos than jellyfin).
@Nickbert7 commented on GitHub (Feb 5, 2020):
In the movie library it is not such bad
Here can you see how it looks like at the moment:
https://imgur.com/a/NlilNmZ
@JustAMan commented on GitHub (Mar 12, 2020):
This should probably be somewhat resolved by https://github.com/jellyfin/jellyfin-web/pull/907
@stale[bot] commented on GitHub (Jul 10, 2020):
This issue has gone 120 days without comment. To avoid abandoned issues, it will be closed in 21 days if there are no new comments.
If you're the original submitter of this issue, please comment confirming if this issue still affects you in the latest release or nightlies, or close the issue if it has been fixed. If you're another user also affected by this bug, please comment confirming so. Either action will remove the stale label.
This bot exists to prevent issues from becoming stale and forgotten. Jellyfin is always moving forward, and bugs are often fixed as side effects of other changes. We therefore ask that bug report authors remain vigilant about their issues to ensure they are closed if fixed, or re-confirmed - perhaps with fresh logs or reproduction examples - regularly. If you have any questions you can reach us on Matrix or Social Media.