mirror of
https://github.com/advplyr/audiobookshelf.git
synced 2026-05-30 23:40:40 +02:00
[Bug]: server crash after starting playback in browser #1421
Assignees
adam (Adam Melkus)
Clear assignees
adam (Adam Melkus)
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: starred/audiobookshelf#1421
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 @Alistair1231 on GitHub (Sep 28, 2023).
Describe the issue
I switched from my phone to the PC, after I pressed play, the server crashed. Local and Direct playback both work on Android v0.9.66-beta
Here is my docker-compose.yml
Here is the ffprobe result of the file that caused it
Here is the log with the crash
After a restart of the container, it still doesn't want to play but didn't crash
This was my third try
Steps to reproduce the issue
Audiobookshelf version
v2.4.3
How are you running audiobookshelf?
Docker
@advplyr commented on GitHub (Sep 28, 2023):
Thanks for the detailed info. If you have a chromium browser can you try playing on there? Firefox seems to have issues with some m4b but either way there is a bug here with the server crash.
@advplyr commented on GitHub (Sep 29, 2023):
Can you enable debug logs? It looks like the crash you got was a race condition. Have you gotten the crash again after that?
@Alistair1231 commented on GitHub (Sep 30, 2023):
Oh, I totally missed that option. I enabled it now. Firefox seems to indeed be misbehaving. Edge works fine, here are the logs:
Playing from Edge (after successful playback, I enabled debug logs and refreshed to see if anything weird shows up)
Playing from Firefox
The crash only happened once so far. I will keep Debug logs enabled for now, in case it happens again. The playback issue happened every time I tried to start it. I used scrcpy to get my phone audio to my PC instead as a workaround.
@advplyr commented on GitHub (Oct 1, 2023):
When I looked through your logs and the source code I could see this was a race condition so it may be rare that the crash occurs.
As a side note, you may be having this issue with firefox because of poorly encoded Audible audio files. This is described in https://github.com/advplyr/audiobookshelf/issues/1872#issuecomment-1627663667 and another related issue #172.
An in depth breakdown of this is here: https://rentry.co/n4ost
@Alistair1231 commented on GitHub (Oct 1, 2023):
Mmh. The script on that rentry post did indeed seem to fix the issue. I can play the file now in Firefox. But if it is a malformed file, why would it only be an issue in Firefox and not Edge? Also, shouldn't the server fall back to transcoding if Direct Play fails?
Ok, I will keep the debug logging enabled for now.
@advplyr commented on GitHub (Oct 1, 2023):
Something about the codec. Chromium based browsers like Edge have a better decoder then Firefox I guess.
If direct play fails it falls back to transcoding that's correct. However, the transcoder fails because of the bad file. I had written a specific edge case to catch this based on a specific error and then force re-encode it to AAC, but that specific error message is not the same every time I guess. You can see my attempt at force re-encoding this issue here https://github.com/advplyr/audiobookshelf/blob/master/server/objects/Stream.js#L343
I don't know how we would check for that issue with ffmpeg. It would be much better if audible didn't give these bad files
@Alistair1231 commented on GitHub (Oct 1, 2023):
Well now that I know that, I know I can try a chromium browser, when something like this happens again. I don't know if I will want to manually fix the file every time.
Very true. 😄
I see. I tried that now. The error just says "Ffmpeg Err "ffmpeg exited with code 1:" instead of giving a proper error like in the other example.
But since I figured that any time ffmpeg just gives an Error 1, it might make sense to transcode, I simply removed the rest of the error in the check like this:
then I simply mounted the file into the container in my docker-compose.yml
After trying to play the file again this is the log. It did work, it took a bit, since the server is slow but it got there
Is that a change that would make sense as a pull request? If this somehow interferes with something we can also just leave it as it is. This seems to be quite the rare issue. At least I only ever encountered it once so far. Maybe I was lucky.
@advplyr commented on GitHub (Oct 1, 2023):
I think that makes sense to implement if you want to put in a PR. The more important check there is the
isAACEncodablewhich would make sure we aren't trying to transcode an mp3 to AAC.It will be quite a bit slower reencoding to AAC but at least it will play
@Alistair1231 commented on GitHub (Oct 2, 2023):
Should this be closed then? The race condition crash wasn't found and fixed, but the issue that presumably caused it was.
@advplyr commented on GitHub (Oct 3, 2023):
Yeah I think so. We can re-open if this crash surfaces again
@advplyr commented on GitHub (Oct 29, 2023):
Fallback to forcing AAC is added in v2.5.0