starred/audiobookshelf
1
0
Fork 0
mirror of https://github.com/advplyr/audiobookshelf.git synced 2026-05-30 23:40:40 +02:00
Code Issues 1.0k Packages Projects Releases 10 Wiki Activity

[Bug]: Chapter Editing Causes Desync with Audio #2709

New Issue
Closed
opened 2026-04-25 00:09:46 +02:00 by adam · 3 comments
adam commented 2026-04-25 00:09:46 +02:00
Owner
Copy Link
Copy Source

Originally created by @FatHobbit4291 on GitHub (Apr 8, 2025).

What happened?

I paused at 12:10:20, made some edits to the chapter times and then resumed. The player resumed at 12:10:20, but the audio was further into the story by a couple of minutes. The chapter times were only changed by a few seconds.

The audio file is a .mp3. It had a .cue to assign chapters, but I deleted it thinking that was the issue. Re-scanned without the .cue file and the issue persisted. I have only had this issue on this file.

What did you expect to happen?

I expected for the audio to resume at the same time. The audio at a specific timestamp should not be affected by changing chapters. Even if progress was tracked by the chapter progress instead of overall progress, the change should not have been multiple minutes.

Steps to reproduce the issue

  1. Play a longer audio book
  2. Pause at a specific timestamp
  3. Edit chapters
  4. Resume playing. Note timestamp and what the audio was doing (ie where you were in the story)

Audiobookshelf version

2.20.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?

None

Logs

Additional Notes

No response

Originally created by @FatHobbit4291 on GitHub (Apr 8, 2025). ### What happened? I paused at 12:10:20, made some edits to the chapter times and then resumed. The player resumed at 12:10:20, but the audio was further into the story by a couple of minutes. The chapter times were only changed by a few seconds. The audio file is a .mp3. It had a .cue to assign chapters, but I deleted it thinking that was the issue. Re-scanned without the .cue file and the issue persisted. I have only had this issue on this file. ### What did you expect to happen? I expected for the audio to resume at the same time. The audio at a specific timestamp should not be affected by changing chapters. Even if progress was tracked by the chapter progress instead of overall progress, the change should not have been multiple minutes. ### Steps to reproduce the issue 1. Play a longer audio book 2. Pause at a specific timestamp 3. Edit chapters 4. Resume playing. Note timestamp and what the audio was doing (ie where you were in the story) ### Audiobookshelf version 2.20.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? None ### Logs ```shell ``` ### Additional Notes _No response_
adam added the bug label 2026-04-25 00:09:46 +02:00
adam closed this issue 2026-04-25 00:09:46 +02:00
adam commented 2026-04-25 00:09:46 +02:00
Author
Owner
Copy Link
Copy Source

@advplyr commented on GitHub (Apr 8, 2025):

I'm not sure I understand. Do you have the audio file open in the player at the time you are editing?

The chapter editor doesn't edit the audio file at all, it only edits the chapters in Abs. Abs doesn't use CUE files at all.

My first guess is this is a VBR audio file which is why the audio player plays at different places in the file for the same timestamp and doesn't have to do with the chapter editor.

@advplyr commented on GitHub (Apr 8, 2025): I'm not sure I understand. Do you have the audio file open in the player at the time you are editing? The chapter editor doesn't edit the audio file at all, it only edits the chapters in Abs. Abs doesn't use CUE files at all. My first guess is this is a VBR audio file which is why the audio player plays at different places in the file for the same timestamp and doesn't have to do with the chapter editor.
adam commented 2026-04-25 00:09:46 +02:00
Author
Owner
Copy Link
Copy Source

@FatHobbit4291 commented on GitHub (Apr 8, 2025):

I'm not sure I understand. Do you have the audio file open in the player at the time you are editing?

The chapter editor doesn't edit the audio file at all, it only edits the chapters in Abs. Abs doesn't use CUE files at all.

My first guess is this is a VBR audio file which is why the audio player plays at different places in the file for the same timestamp and doesn't have to do with the chapter editor.

I will try re-encoding the audio file with a constant bitrate to see if that fixes the issue.

@FatHobbit4291 commented on GitHub (Apr 8, 2025): > I'm not sure I understand. Do you have the audio file open in the player at the time you are editing? > > The chapter editor doesn't edit the audio file at all, it only edits the chapters in Abs. Abs doesn't use CUE files at all. > > My first guess is this is a VBR audio file which is why the audio player plays at different places in the file for the same timestamp and doesn't have to do with the chapter editor. I will try re-encoding the audio file with a constant bitrate to see if that fixes the issue.
adam commented 2026-04-25 00:09:47 +02:00
Author
Owner
Copy Link
Copy Source

@FatHobbit4291 commented on GitHub (Apr 8, 2025):

Final edit. I just re-downloaded the file and now it works fine. My guess is the audio file was messed up.

I re-encoded the audio file in Audacity to make sure it was a constant bitrate.

Image

I am now having a different issue. It seems that the android app and the web player are de-synced. I will have them both at the same timestamp and the audio is about 3 minutes apart in the story. They both show the same time and time remaining, but they are not together. To get them to be at the same audio, the Android app is at 12:30 and the web player is at 12:27

Edit: After further looking into this it appears there is an issue with the Android app being behind of everything by a few minutes. Playing the audio file natively in VLC at 12:27:00 gives the same audio as the web player at the same time. Downloading from the app and playing in the default audio player on Samsung gives the same audio as the web player and the file in the library.

@FatHobbit4291 commented on GitHub (Apr 8, 2025): Final edit. I just re-downloaded the file and now it works fine. My guess is the audio file was messed up. I re-encoded the audio file in Audacity to make sure it was a constant bitrate. ![Image](https://github.com/user-attachments/assets/662ab019-2744-4d2b-8954-73097bd9fdbc) I am now having a different issue. It seems that the android app and the web player are de-synced. I will have them both at the same timestamp and the audio is about 3 minutes apart in the story. They both show the same time and time remaining, but they are not together. To get them to be at the same audio, the Android app is at 12:30 and the web player is at 12:27 Edit: After further looking into this it appears there is an issue with the Android app being behind of everything by a few minutes. Playing the audio file natively in VLC at 12:27:00 gives the same audio as the web player at the same time. Downloading from the app and playing in the default audio player on Samsung gives the same audio as the web player and the file in the library.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
authentication
backlog
bug
chapter editor
config-issue
ebooks
encoding/embedding
enhancement
help wanted
listening sessions & progress
planned
possible plugin
progress sync
pull-request
Mirrored from GitHub Pull Request
 sorting/filtering/searching
unable to reproduce
upload
users & permissions
waiting
No Label bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam (Adam Melkus)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/audiobookshelf#2709
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?