[Bug]: Chapter playback in Edit Chapters plays from the wrong time position #2314

Closed
opened 2026-04-25 00:06:01 +02:00 by adam · 7 comments
Owner

Originally created by @Ithu123 on GitHub (Oct 15, 2024).

What happened?

When adding a Chapter to the audiobook (doesen't matter if it happens automatically or manually) the "Listen from beginning of chapter" plays from the wrong time. As far as i can tell, the delay gets greater for chapters later in the book. I cant tell (yet) if it is due to more time passing or more chapters added.

What did you expect to happen?

Correct replay at the correct location at the beginning of the chapter.

Steps to reproduce the issue

  1. add a chapter to an audiobook
  2. "Listen from beginning of chapter"
  3. compare to real time of the audiobook, via the player

Audiobookshelf version

v. 2.15.0

How are you running audiobookshelf?

Docker

What OS is your Audiobookshelf server hosted from?

Linux

If the issue is being seen in the UI, what browsers are you seeing the problem on?

Firefox

Logs

No response

Additional Notes

No response

Originally created by @Ithu123 on GitHub (Oct 15, 2024). ### What happened? When adding a Chapter to the audiobook (doesen't matter if it happens automatically or manually) the "Listen from beginning of chapter" plays from the wrong time. As far as i can tell, the delay gets greater for chapters later in the book. I cant tell (yet) if it is due to more time passing or more chapters added. ### What did you expect to happen? Correct replay at the correct location at the beginning of the chapter. ### Steps to reproduce the issue 1. add a chapter to an audiobook 2. "Listen from beginning of chapter" 3. compare to real time of the audiobook, via the player ### Audiobookshelf version v. 2.15.0 ### How are you running audiobookshelf? Docker ### What OS is your Audiobookshelf server hosted from? Linux ### If the issue is being seen in the UI, what browsers are you seeing the problem on? Firefox ### Logs _No response_ ### Additional Notes _No response_
adam added the bug label 2026-04-25 00:06:01 +02:00
adam closed this issue 2026-04-25 00:06:01 +02:00
Author
Owner

@nichwall commented on GitHub (Oct 15, 2024):

Is this with all books or only certain books? This sounds like a problem with the bitrate in the file.

@nichwall commented on GitHub (Oct 15, 2024): Is this with all books or only certain books? This sounds like a problem with the bitrate in the file.
Author
Owner

@Ithu123 commented on GitHub (Oct 15, 2024):

I tried testing that, but the chapter wouldnt even play. I switched to Chrome and to my surprise I had no problems there at all. Same chapter, same button playing from two diffrent times on two diffrent browsers.

@Ithu123 commented on GitHub (Oct 15, 2024): I tried testing that, but the chapter wouldnt even play. I switched to Chrome and to my surprise I had no problems there at all. Same chapter, same button playing from two diffrent times on two diffrent browsers.
Author
Owner

@nichwall commented on GitHub (Oct 15, 2024):

What container and codec are you using? Do you have any logs from the playback failing, like the ffmpeg command running or failing?

Edit: or from playing from the wrong spot

@nichwall commented on GitHub (Oct 15, 2024): What container and codec are you using? Do you have any logs from the playback failing, like the ffmpeg command running or failing? Edit: or from playing from the wrong spot
Author
Owner

@advplyr commented on GitHub (Oct 15, 2024):

I'm not sure if you when you say adding a chapter you mean adding a new audio file or you are editing the embedded chapters in the audio file.
If you are using mp3 files then this is usually because the audio files are variable bitrate (VBR). The other less common issue is the audio file has the wrong duration in the metadata.

https://github.com/advplyr/audiobookshelf/issues/3465#issuecomment-2380888018
https://github.com/advplyr/audiobookshelf/issues/850

@advplyr commented on GitHub (Oct 15, 2024): I'm not sure if you when you say adding a chapter you mean adding a new audio file or you are editing the embedded chapters in the audio file. If you are using mp3 files then this is usually because the audio files are variable bitrate (VBR). The other less common issue is the audio file has the wrong duration in the metadata. https://github.com/advplyr/audiobookshelf/issues/3465#issuecomment-2380888018 https://github.com/advplyr/audiobookshelf/issues/850
Author
Owner

@Ithu123 commented on GitHub (Oct 17, 2024):

I am editing the chapters via the webpage (see screenshot), I assumed those are stored in the database. The pattern i observe seems to be:
On Firefox (131.0.3 (64-Bit)) :

  • It does not play long (like 10 hrs in my case) m4b files (just keeps loading).
  • It plays long mp3 files from the wrong startingpoint
  • It plays chapters generated on multiple mp3 (like form digitized CDs) correctly
  • It seems to play shorter mp3 files correctly or almost correctly.

I would provide logs, but none of this shows in the logs on debug level.

It does seem to be a browser related issues, as on Chrome it works just fine.

additionally:
I checked the mp3 file i was testing with ffmpeg -i and this is the result:
ffmpeg version 6.0-full_build-www.gyan.dev Copyright (c) 2000-2023 the FFmpeg developers built with gcc 12.2.0 (Rev10, Built by MSYS2 project) configuration: --enable-gpl [...] libavutil 58. 2.100 / 58. 2.100 libavcodec 60. 3.100 / 60. 3.100 libavformat 60. 3.100 / 60. 3.100 libavdevice 60. 1.100 / 60. 1.100 libavfilter 9. 3.100 / 9. 3.100 libswscale 7. 1.100 / 7. 1.100 libswresample 4. 10.100 / 4. 10.100 libpostproc 57. 1.100 / 57. 1.100 [mp3 @ 0000026da51a11c0] Estimating duration from bitrate, this may be inaccurate Input #0, mp3, from 'Audio Track 1.mp3': Duration: 11:17:42.60, start: 0.000000, bitrate: 128 kb/s Stream #0:0: Audio: mp3, 44100 Hz, stereo, fltp, 128 kb/s At least one output file must be specified

I interpred this as a CBR mp3-file?

@Ithu123 commented on GitHub (Oct 17, 2024): I am editing the chapters via the webpage ([see screenshot](https://github.com/user-attachments/assets/498f3b98-dd94-450f-b0ed-1d5d62be9293)), I assumed those are stored in the database. The pattern i observe seems to be: On Firefox (131.0.3 (64-Bit)) : - It does not play long (like 10 hrs in my case) m4b files ([just keeps loading](https://github.com/user-attachments/assets/ff31d05d-67ee-4242-93aa-bb183ecf3dd6)). - It plays long mp3 files from the wrong startingpoint - It plays chapters generated on multiple mp3 (like form digitized CDs) correctly - It seems to play shorter mp3 files correctly or almost correctly. I would provide logs, but none of this shows in the logs on debug level. It does seem to be a browser related issues, as on Chrome it works just fine. additionally: I checked the mp3 file i was testing with `ffmpeg -i` and this is the result: `ffmpeg version 6.0-full_build-www.gyan.dev Copyright (c) 2000-2023 the FFmpeg developers built with gcc 12.2.0 (Rev10, Built by MSYS2 project) configuration: --enable-gpl [...] libavutil 58. 2.100 / 58. 2.100 libavcodec 60. 3.100 / 60. 3.100 libavformat 60. 3.100 / 60. 3.100 libavdevice 60. 1.100 / 60. 1.100 libavfilter 9. 3.100 / 9. 3.100 libswscale 7. 1.100 / 7. 1.100 libswresample 4. 10.100 / 4. 10.100 libpostproc 57. 1.100 / 57. 1.100 [mp3 @ 0000026da51a11c0] Estimating duration from bitrate, this may be inaccurate Input #0, mp3, from 'Audio Track 1.mp3': Duration: 11:17:42.60, start: 0.000000, bitrate: 128 kb/s Stream #0:0: Audio: mp3, 44100 Hz, stereo, fltp, 128 kb/s At least one output file must be specified` I interpred this as a CBR mp3-file?
Author
Owner

@advplyr commented on GitHub (Oct 18, 2024):

I don't think you can reliably check if the audio file is VBR with ffmpeg like that but I could be wrong. One easy way I check is I play the audio file in VLC media player, open up the codec statistics and if the Content bitrate changes while playing it is VBR.
If it stays the same it is CBR. I've noticed when seeking around or just starting it takes a second to get the correct bitrate, after a second it stays the same.

image

@advplyr commented on GitHub (Oct 18, 2024): I don't think you can reliably check if the audio file is VBR with ffmpeg like that but I could be wrong. One easy way I check is I play the audio file in VLC media player, open up the codec statistics and if the `Content bitrate` changes while playing it is VBR. If it stays the same it is CBR. I've noticed when seeking around or just starting it takes a second to get the correct bitrate, after a second it stays the same. ![image](https://github.com/user-attachments/assets/9c41dbf7-05f7-4cb3-a6b2-2ad2955eb5c5)
Author
Owner

@Ithu123 commented on GitHub (Oct 24, 2024):

So i checked that and the Input Bitrate changes, but the contend bitrate stays the same.

@nichwall I am running the official docker container via docker-compose. docker-compose logs does not show anything related, as well as the protocol. Any other logs i should check?

@Ithu123 commented on GitHub (Oct 24, 2024): So i checked that and the `Input Bitrate` changes, but the `contend bitrate` stays the same. @nichwall I am running the official docker container via docker-compose. `docker-compose logs` does not show anything related, as well as the protocol. Any other logs i should check?
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/audiobookshelf#2314