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

Stall when going to next episode, often followed by crash #2800

Closed
AlexKalopsia opened this issue May 28, 2023 · 14 comments · Fixed by #3958
Closed

Stall when going to next episode, often followed by crash #2800

AlexKalopsia opened this issue May 28, 2023 · 14 comments · Fixed by #3958
Labels
bug Something isn't working

Comments

@AlexKalopsia
Copy link
Contributor

Describe the bug

JF running on a Synology DS918+ 16Gb RAM.

It's been some weeks now that the client goes in some form of total stall when the "Next episode" countdown ends, or when I manually try and make it go to the next episode. Media being played here is 1080p H264 SDR, with audio Dolby Digital+ 5.1

I can see from my desktop dashboard that the client is in Direct Play ("The source file is entirely compatible with this client, and the session is receiving the file without modifications.").

In general, the few times when it works, moving from one episode to the other is also incredibly slow, so I believe there might be something fishy happening.

image

Logs

Client crash: https://hastebin.com/share/kefotoxato.php
Server log: https://hastebin.com/share/kaqasasuqi.csharp

Application version

0.15.9

Where did you install the app from?

Sideloaded APK

Device information

Amazon Fire Stick 4K Max

Android version

Fire OS

Jellyfin server version

10.8.10

@AlexKalopsia AlexKalopsia added the bug Something isn't working label May 28, 2023
@MattFryer
Copy link

I've been having this same issue for a while now. Both the fire TV app and side loaded android TV apps do the same. But the browser, mobile and webOS versions work perfectly. I've tried on various generations of fire TV stick including the latest 4K Max. If I force stop the app or wait until it crashes and open it again, its back to working perfectly although it normally loses a large portion of my progress through the episode. Happy to provide additional logs from my side if it will help with identifying the issue.

@AlexKalopsia
Copy link
Contributor Author

That's somewhat comforting to hear, we also got in the habit of doing the clear cache / clear data routine, but it's been really frustrating

@nielsvanvelzen
Copy link
Member

From the provided logs it looks like the server becomes unresponsive causing the app to crash. Some of the requests take a minute to respond, this is not good.
Not much I can do on the client side for this.

@MattFryer
Copy link

As I'm running the server on my NAS it probably is underpowered for sure and so I initially thought this might be causing the issue but it does work perfectly on other clients. Maybe the android/fireTV client has a shorter timeout waiting for a response?

When I get the chance I'll spin Jellyfin up on a more powerful box and see if it improves things.

@AlexKalopsia
Copy link
Contributor Author

For what is worth this also occurs when the media is in direct play and no transcoding is happening. I do get the feeling that the truth is somewhere in the middle, since I do detect very high drive utilization, but as @MattFryer above says I have no issue on other clients, so it's a bit unclear

@nielsvanvelzen
Copy link
Member

nielsvanvelzen commented May 30, 2023

The app uses a timeout of 30 seconds. If no response is ready after that it will fail. Most places in the app can safely deal with this (ignore/show warning/go back etc.) but some places will hard-crash the app as we have no way to deal with a bad response.

Other clients behave differently on this matter, for example; the mobile app always safely handles bad responses because it was completely written from scratch, the web client doesn't specify timeouts and will happily wait for minutes.

edit: it might help to use different drives for the Jellyfin data and the actual media. As these problems probably arise from database read/writes.

@jellyfin-bot
Copy link
Contributor

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 master branch, 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.

@AlexKalopsia
Copy link
Contributor Author

This is still happening, a bit unclear if @nielsvanvelzen latest reply suggest that it's smething that will be looked at?

@MattFryer
Copy link

MattFryer commented Nov 9, 2023

edit: it might help to use different drives for the Jellyfin data and the actual media. As these problems probably arise from database read/writes.

@nielsvanvelzen I finally got around to moving the Jellyfin config to a USB pen drive I attached to my NAS to test this and it seems to have improved things drastically. Not only is it no longer crashing the android client constantly but the general performance of things like marking shows as complete seems to have improved. A rubbish old USB pen drive being so much better compared to a RAID5 NAS volume makes absolutely no sense to me however. My gut says there has to be something weird going on with Jellyfin for this to be the case as all other apps I have hosted on my NAS run like a dream with their data and media on the same RAID volume/pool.

Edit: It could also be possible that there is something weird going on with Synology Docker I guess.

@hundredfire
Copy link

I would like to know if there is any update on this? I have the same issue while running jellyfin on a separate drive than my media folders on a 2-bay synology NAS (they're set up as JBOD, no RAID)

@BJ24
Copy link

BJ24 commented Apr 18, 2024

Hi,
I've been having this issue for more than a year I would guess. I am running docker on a Synology also. Run many other docker's and vms without issue. Wondering if anyone has explored this more.

@Zodsmar
Copy link

Zodsmar commented Apr 24, 2024

Hey,

I have also been experiencing the same issue.

https://www.reddit.com/r/jellyfin/comments/10fgzky/jellyfin_for_android_tv_freezes_and_ultimately/

My log is basically identical to this reddit post.

Jellyfin.Server.Middleware.ResponseTimeMiddleware: Slow HTTP Response from

@jellyfin-bot
Copy link
Contributor

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 master branch, 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.

@hundredfire
Copy link

Still happening regularly on my Synology NAS-hosted jellyfin server (latest version)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants