Conversation
|
|
I would argue for this as well. Forcing the low maxMaxBufferLength I believe would have caused apparent fixes by hiding or "patching over" large segments attempting to be appended to the buffer by stalling their addition, and getting around the fact that the back-buffer (old segments) would gobble up the buffer. It may be less apparent now from any number of tweaks or changes to Chromium since then, but I think it should be addressed and not worked around. I was still able to encounter the appending issue with the right ultra high bitrate stream. I have one merged PR in hls.js which fixes the back-buffer cause with a new eviction strategy, and another still open which fixes the massive segment issue. |
|
2 participants
In #6985 the HLS variable maxMaxBufferLength was defined to always be equal to the similarly named variable maxBufferLength. This has had the unfortunate side effect of causing Jellyfin to only buffer 6 seconds of video in advance in most situations. This is detrimental to performance on less-than-perfect network connections, e.g. ones with dropouts, high latency, etc and removes the long practiced pastime of "letting the video buffer ahead".
There are 3 variables that are relevant to this behavior:
HLS streams will attempt to fill maxBufferLength first (really should've been called minBufferLength), then will continue attempting to fill maxMaxBufferLength unless it hits maxBufferSize first.
By pinning maxMaxBufferLength to always be equal to maxBufferLength, we lose the ability to buffer longer stretches of video when there is sufficient room in the browser's cache.
Originally, #6985 was put in place to fix a bug with Chrome 138, however I am skeptical that this fixes anything at all. If you look at issues that were closed mentioning #6985, you can see many users still experiencing the crashing issues (as recent as a few weeks ago) and discussing potential fixes unrelated to this buffer setting. (#14687 #14689)
Furthermore, my own testing in Chromium 146 has shown no issues with playback restarting/failing even after reverting back to the default values for maxMaxBufferLength. My Chromium correctly halts the buffer at 60 MB and does not throw any buffer append errors. It is possible whatever happened with Chrome 138 was fixed within the last 9 months and no longer requires this fix.
Therefore, I am requesting that maxMaxBufferLength be set back to the default value and allow Jellyfin to buffer more than a measly 6 seconds of video.
Changes
Reverts #6985
Sets maxMaxBufferLength to default (600 sec)