mirror of
https://github.com/jellyfin/jellyfin.git
synced 2026-07-16 05:43:54 +03:00
Extreme Buffering via Jellyfin without Transcoding, none at all via VLC #6467
Reference in New Issue
Block a user
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 @ToasterUwU on GitHub (Nov 16, 2024).
This issue respects the following points:
Description of the bug
Context needed:
Im not entirely sure how to explain this the most straightforward way, so bear with me.
When my files get transcoded and change to a significant extend, I get extreme buffering in Jellyfin on any and all players. There is no bottleneck anywhere, no CPU or RAM or IO or Network restrictions that would make the video buffer.
I tried to find an infrastructure issue for the last 2 hours, and realized now that it has nothing to do with my infrastructure.
The fix is using the refresh metadata button. For some reason I don't even remotely understand, that fixes the playback entirely.
Some before and after numbers:
Reproduction steps
What is the current bug behavior?
Playback is extremely slow for no reasonable reason.
What is the expected correct behavior?
Playback should only buffer when any part of the Infrastructure (CPU, RAM, IO, Network) cant keep up.
Jellyfin Server version
10.10.0+
Specify commit id
No response
Specify unstable release number
No response
Specify version number
10.10.1
Specify the build version
10.10.1
Environment
Jellyfin logs
FFmpeg logs
Client / Browser logs
No response
Relevant screenshots or videos
No response
Additional information
I was hesitant to make this Issue, since I thought "Maybe there is just a scheduled task to do this", but I checked, and there either isn't one or there is one but its named in a way that I don't recognize as the same thing "Refresh Metadata - Scan for new and updated files" does.
@ToasterUwU commented on GitHub (Nov 16, 2024):
Update: Only like 15 minutes after the refresh button and playback test, it is back to being extremely slow. I havent changed anything and it still is broken in the exact same way. Interestingly enough it keeps buffering at the exact same spot on the episode i tried watching. I assume thats because its cached and just replayed from cache or something, but i dont actually know. It loads forever when starting playback, plays the same 20 seconds fine each time, than starts the endless buffering.
When i try to play the exact same file directly from the exact same location (My NAS) via something like VLC, i have not even a single second load time and not a single buffering session.
I have absolutely no idea why this issue is a thing. There is not a single restrictions in the hardware, otherwise i would see it in my system monitor software, and at the same time direct play via sshfs and vlc works flawlessly.
@ToasterUwU commented on GitHub (Nov 16, 2024):
I just noticed that i have an error text next to the "Scan Media Library" Scheduled Task. I checked the log and found the following, not sure if its actually relevant and how i would fix it.
@ToasterUwU commented on GitHub (Nov 16, 2024):
I fixed the .db file using this method: https://stackoverflow.com/a/5316540
The Scan Library task is taking forever, but without errors. It probably didnt run for a while without failing.
I will go to bed for now, this seems to be a few hours process.
I will write another comment tommorow when i know if that fixed/changed anything.
@ToasterUwU commented on GitHub (Nov 17, 2024):
Ok, i waited for that to finish and tried a lot of things after, but its always the same. Jellyfin buffers while nothing is bottlenecking it, while the same file can be played with VLC flawlessly. Refreshing the Metadata doesn't seem to help anymore either, it was probably a fluke.
@ToasterUwU commented on GitHub (Nov 17, 2024):
Another note worthy thing is that it gets less bad with less load on the infrastructure, meaning if I turn everything off it still buffers, but only for like 2-3 seconds instead of 30 seconds. But like I also mentioned multiple times, not a single thing is utilized to 100% even remotely.
Remuxing or even Direct Playing a Video with 3.5 Mbps and sending it over a mostly unused Gigabit ethernet cable shouldn't be an issue, even if the infrastructure was used to nearly 100%
@ToasterUwU commented on GitHub (Nov 17, 2024):
Sorry guys, turns out my SSD Cache on my NAS was doing really really weird things, and my system monitoring tool didn't recognize that as system load, even though it is in the real world...
My bad, sorry for the wall of text.