Playback occasionally fails to start

[octylFractal]

Describe The Bug Playback occasionally fails to start.

Steps To Reproduce

1. Go to my home page, /web/index.html#!/home.html
2. Try to play a file. The exact file does not appear to matter, this happens to any item.
3. Loading spinner pops up and loops forever.

Expected Behavior The video begins playing.

Logs None appear, however the following is noted in my browser's network console:

{
    "type": "https://tools.ietf.org/html/rfc7231#section-6.5.1",
    "title": "One or more validation errors occurred.",
    "status": 400,
    "traceId": "00-7204c81af14d45e4853426681978c43c-c49680ccb5a14a97-00",
    "errors": {
        "maxStreamingBitrate": [
            "The value \u00272400000000\u0027 is not valid."
        ]
    }
}

System (please complete the following information):

• Platform: Arch Linux
• Browser: Chrome
• Jellyfin Version: 10.8.10

Additional Context This can be worked around by reloading the page with the network console open, even without Disable Cache checked. Force reloading without that fails to fix the issue. This makes me think it is some kind of timing issue.

[MidnightRising]

From the error, looks like maxStreamingBitrate can occasionally be 'null' (a null character in between to apostrophes). Just a sanity check before I take a look, can you set your max streaming bitrate to something and then set it back, and see if that clears any weird null state?

[octylFractal]

I'll try it, but the problem is intermittent so I'll report back if it doesn't happen again in a week.

[octylFractal]

It appears that fixed the issue, I haven't experienced it since. Should this be left open to add code for recovering from a bad state?

[MidnightRising]

Honestly really happy to hear it worked for you!

Agreed that this state should be handled better, but there's the question of how to actually recover from this. If it can't read the value (for whatever reason), should it set it to default? Set it to the last valid value (I'm thinking this? Though I'm not sure the best way to store that)? From there I'm wondering how we handle different error states.

Definitely something to leave open but it might take some noodling for how to best handle this.

[jellyfin-bot]

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.

[nagisa]

I can confirm that I have seen this problem on a very recent install. Random flac files would refuse to play, both on the web interface and tauon music box. If one client would fail to play a track, so would the other. And once a track appeared unplayable it would remain so seemingly indefinitely (i.e. the issue is not spurious.) In my case this was only affecting some, not all, files however.

I then copied over an exemplar from devtools as curl to see what it returned:

#curl 'https://jellyfin.home.kazlauskas.me/Audio/07fe5be09b8c830c576c4931126e2fd9/universal?UserId=<snip>&DeviceId=<snippit>&MaxStreamingBitrate=2800000000&Container=opus%2Cwebm%7Copus%2Cmp3%2Caac%2Cm4a%7Caac%2Cm4b%7Caac%2Cflac%2Cwebma%2Cwebm%7Cwebma%2Cwav%2Cogg&TranscodingContainer=ts&TranscodingProtocol=hls&AudioCodec=aac&api_key=<nah>&PlaySessionId=<eyes>&StartTimeTicks=0&EnableRedirection=true&EnableRemoteMedia=false' -H 'User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:122.0) Gecko/20100101 Firefox/122.0' -H 'Accept: audio/webm,audio/ogg,audio/wav,audio/*;q=0.9,application/ogg;q=0.7,video/*;q=0.6,*/*;q=0.5' -H 'Accept-Language: en-US,en;q=0.5' -H 'Accept-Encoding: gzip, deflate, br, identity' -H 'DNT: 1' -H 'Sec-Fetch-Dest: audio' -H 'Sec-Fetch-Mode: cors' -H 'Sec-Fetch-Site: same-origin' -H 'Range: bytes=0-' -H 'Connection: keep-alive' -H 'TE: trailers'
{"type":"https://tools.ietf.org/html/rfc7231#section-6.5.1","title":"One or more validation errors occurred.","status":400,"traceId":"00-7c910d7562b7035184937dc267b7df12-f0c4e1a1911af2a3-00","errors":{"maxStreamingBitrate":["The value \u00272800000000\u0027 is not valid."]}}

I then went to the settings in the web client and fiddled with the Music Quality > Internet quality setting setting it to 2Mbps instead of the previous Auto. The playback on the affected files then started working again.

Note that the request contains &MaxStreamingBitrate=2800000000 so it seems like it might be a check on the permissible range of bitrates on the backend side? I don't see any 'null's from what I can tell.

UPDATE: I'm still seeing tracks failing to play in Tauon despite the setting, but which ones are affected is still seemingly random.