You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If you use the API to initialize an M4B conversion of a library item, it does not check if the current item is already being encoded - if you send the request twice, ABS initializes ffmpeg twice, trying to access the same files (you can watch this very easily because both threads try to update the percentage done on the ABS interface), eventually crashing the server when the second thread tries to access the files.txt file locked by the first process.
This leads to a complete server crash.
What did you expect to happen?
The API should be thread aware and deny a request if an encoding is already in progress / just let the process continue instead of spawning a second encoder.
Steps to reproduce the issue
Start encoding a Library item via the API
Send the same command a second time while the encoding is ongoing
Audiobookshelf version
v2.12.3
How are you running audiobookshelf?
Windows Tray App
What OS is your Audiobookshelf server hosted from?
Windows
If the issue is being seen in the UI, what browsers are you seeing the problem on?
As a note - there is a docker tool on the docker hub called abs-autoconverter that uses the API to watch the library for multi-track files to automatically trigger a conversion to m4b using the API. This is run via cron at set intervals (since there seems to be no way in the API to check the progress of an encode), and if a book takes longer than expected to encode, the tool will send an encode request for the same book again and this will trigger the server trash.
What happened?
If you use the API to initialize an M4B conversion of a library item, it does not check if the current item is already being encoded - if you send the request twice, ABS initializes ffmpeg twice, trying to access the same files (you can watch this very easily because both threads try to update the percentage done on the ABS interface), eventually crashing the server when the second thread tries to access the files.txt file locked by the first process.
This leads to a complete server crash.
What did you expect to happen?
The API should be thread aware and deny a request if an encoding is already in progress / just let the process continue instead of spawning a second encoder.
Steps to reproduce the issue
Audiobookshelf version
v2.12.3
How are you running audiobookshelf?
Windows Tray App
What OS is your Audiobookshelf server hosted from?
Windows
If the issue is being seen in the UI, what browsers are you seeing the problem on?
None
Logs
Additional Notes
No response
The text was updated successfully, but these errors were encountered: