Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Android App Laggs when watching Photo folder #858

Open
ghost opened this issue Feb 25, 2020 · 7 comments · Fixed by #907
Open

Android App Laggs when watching Photo folder #858

ghost opened this issue Feb 25, 2020 · 7 comments · Fixed by #907
Labels
enhancement Improve existing functionality or small fixes

Comments

@ghost
Copy link

ghost commented Feb 25, 2020

Hello,
i noticed today when i watched my photos on my phone, that the phone was extremly lagging and need extremly much time to load my photos.

The only thing i can find in the log is:
[2020-02-25 20:18:27.510 +00:00] [INF] Getting image size for item "Photo" "/media/****.jpg"
[2020-02-25 20:18:32.324 +00:00] [WRN] HTTP Response 200 to "192.168.1.1". Time (slow): 0:00:02.0143251. "http://sub.domain.com/Items/***/Images/Primary?tag=53945fae259f872bcdbab281986eec13&quality=90"

Jellyfin Server with Docker 10.4.3 and Android 0.9.9

@dkanada dkanada transferred this issue from jellyfin-archive/jellyfin-android-original Feb 26, 2020
@ghost
Copy link
Author

ghost commented Mar 9, 2020

As it looks like same problem with Jellyfin 10.5.0

@heyhippari
Copy link
Contributor

Hopefully, #907 should improve memory usage and loading times a lot.

It's should be heading to 10.5.1, so when the Android app updates their web version to 10.5.1, you should notice an improvement.

@ghost
Copy link
Author

ghost commented Mar 23, 2020

Hopefully, #907 should improve memory usage and loading times a lot.

It's should be heading to 10.5.1, so when the Android app updates their web version to 10.5.1, you should notice an improvement.

I tested it on my android app and the problem persists with 10.5.2 but as you wrote the android app needs an update.

But i testet it also in the webbrowser to open my picture folder but the performance is sadly still really bad. Maybe i can provide some logs?
I opened an folder with 100 pictures and it needs a minute to load and i also hear the drives are spinning^^

Maybe i can provide some logs?

@heyhippari
Copy link
Contributor

A bit more is needed to properly close this :)

Basically, we lazy load images when the page is loaded. Meaning we first load the structure, show it, then load the images in the background while you can browse.

The current lazy loading module, which we inherited from Emby, doesn't unload images when they leave the viewport. This means that images will load once and never be unloaded from memory.

This is very much not optimal and is slated for a rewrite at some point.

I'm reopening this and tagging it as enhancement, to reflect the work left on this.

@heyhippari heyhippari reopened this Mar 23, 2020
@heyhippari heyhippari added the enhancement Improve existing functionality or small fixes label Mar 23, 2020
@ghost
Copy link
Author

ghost commented Mar 23, 2020

Thanks ;)
Now i understand why the pictures loading is getting slower and slower.

One thing i doesnt exactly understand, wouldnt it be possible to cache a small version of the pictures in the cache? Because as i see, the files are loaded every time from the hard drive or am i wrong?
I notice this because i use a ssd with the docker files and every time i access a folder (also same folder again) the images are loading from the hard drive?

@JustAMan
Copy link
Contributor

JustAMan commented Apr 2, 2020

I wonder if this would be at least partially addressed by #967

@heyhippari
Copy link
Contributor

It helps a little with the viewer, but what we really need is an overhaul the lazyloader, so that it unloads images when they leave the viewport.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Improve existing functionality or small fixes
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants