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

[PR #5006] Fix applying chapters not fully replacing existing chapter list #4395

New Issue
Open
opened 2026-04-25 00:19:35 +02:00 by adam · 0 comments
adam commented 2026-04-25 00:19:35 +02:00
Owner
Copy Link
Copy Source

📋 Pull Request Information

Original PR: https://github.com/advplyr/audiobookshelf/pull/5006
Author: @CutSnake01
Created: 1/26/2026
Status: 🔄 Open

Base: master ← Head: fix-issue-4939

📝 Commits (1)

  • 54491ee Fix applying chapters not fully replacing existing chapter list

📊 Changes

1 file changed (+0 additions, -2 deletions)

View changed files

📝 client/pages/audiobook/_id/chapters.vue (+0 -2)

📄 Description

Brief summary

Fix bug where applying Audible chapters didn't fully replace the existing chapter list when the new list had fewer chapters.

Which issue is fixed?

Fixes #4939

In-depth Description

When applying chapters from Audible lookup, if the new chapter list had fewer chapters than the existing one, the old extra chapters were being retained. For example, going from 61 to 36 chapters would result in a hybrid list with 36 updated chapters plus 25 leftover old ones.

The bug was in the applyChapterData() function which incorrectly fell back to old chapters when the Audible chapter array was exhausted. This fallback should only happen for explicitly locked chapters, not for all remaining old chapters.

The fix removes the fallback to old non-locked chapters, ensuring the chapter list is fully replaced rather than merged with leftover old chapters.

This affects any user who:

  • Has a book with more chapters than Audible returns
  • Uses the chapter lookup feature

How have you tested this?

  1. Open a book with 61+ chapters in the chapter editor
  2. Perform Audible chapter lookup (returns ~36 chapters)
  3. Click "Apply Chapters"
  4. Verify only 36 chapters remain (not 61)
  5. Verify locked chapters are preserved if any were set

Screenshots

N/A - No UI changes, logic fix only

🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.

## 📋 Pull Request Information **Original PR:** https://github.com/advplyr/audiobookshelf/pull/5006 **Author:** [@CutSnake01](https://github.com/CutSnake01) **Created:** 1/26/2026 **Status:** 🔄 Open **Base:** `master` ← **Head:** `fix-issue-4939` --- ### 📝 Commits (1) - [`54491ee`](https://github.com/advplyr/audiobookshelf/commit/54491ee90392208b93e5b55f995424f757813766) Fix applying chapters not fully replacing existing chapter list ### 📊 Changes **1 file changed** (+0 additions, -2 deletions) <details> <summary>View changed files</summary> 📝 `client/pages/audiobook/_id/chapters.vue` (+0 -2) </details> ### 📄 Description ## Brief summary Fix bug where applying Audible chapters didn't fully replace the existing chapter list when the new list had fewer chapters. ## Which issue is fixed? Fixes #4939 ## In-depth Description When applying chapters from Audible lookup, if the new chapter list had fewer chapters than the existing one, the old extra chapters were being retained. For example, going from 61 to 36 chapters would result in a hybrid list with 36 updated chapters plus 25 leftover old ones. The bug was in the `applyChapterData()` function which incorrectly fell back to old chapters when the Audible chapter array was exhausted. This fallback should only happen for explicitly locked chapters, not for all remaining old chapters. The fix removes the fallback to old non-locked chapters, ensuring the chapter list is fully replaced rather than merged with leftover old chapters. This affects any user who: - Has a book with more chapters than Audible returns - Uses the chapter lookup feature ## How have you tested this? 1. Open a book with 61+ chapters in the chapter editor 2. Perform Audible chapter lookup (returns ~36 chapters) 3. Click "Apply Chapters" 4. Verify only 36 chapters remain (not 61) 5. Verify locked chapters are preserved if any were set ## Screenshots N/A - No UI changes, logic fix only --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
adam added the pull-request label 2026-04-25 00:19:35 +02:00
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 pull-request
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#4395
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?