Fix #542: audiobook total size = sum of per-file sizes#738
Open
Paelsmoessan wants to merge 1 commit into
Open
Conversation
…ti-file aware) Audiobook.FileSize was only ever set to the primary (alphabetically-first) file's size during rename, or left null, never the sum. Multi-file audiobooks showed a too-small size, and un-organized ones showed none (detail view hides null). Derive the total from the already-correct per-file sizes at read time instead of relying on the stale scalar: - New IAudiobookFileRepository.GetTotalSizesByAudiobookIdAsync (SUM grouped by audiobook), mirroring GetCountsByAudiobookIdAsync, for the list view (its format summaries carry no Size). - AudiobookDtoFactory and LibraryQueryWorkflow.MapDetails sum the loaded Files. Nothing sorts/filters by FileSize in SQL, so in-memory/aggregate derivation is safe. Adds a multi-file sum test to AudiobookDtoFactoryTests. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
An audiobook's total size (
Audiobook.FileSize) is wrong. For multi-file audiobooks it shows only one file's size (a 15-part, ~70 MB book displays ~4.7 MB), and for books that were never organized it shows nothing at all.Root cause
FileSizeis a stored scalar that is only ever set to the primary (alphabetically-first) file's size during rename (UpdateAudiobookPathSummary), or left null. It is never the sum of the audiobook's files. The per-file sizes (AudiobookFile.Size, from the filesystem) are already correct; only the aggregate is wrong.Fix
Derive the total from the already-correct per-file sizes at read time, instead of relying on the stale scalar:
IAudiobookFileRepository.GetTotalSizesByAudiobookIdAsync(SUM grouped by audiobook), mirroringGetCountsByAudiobookIdAsync, for the list view (its format summaries carry no size).AudiobookDtoFactoryandLibraryQueryWorkflow.MapDetailssum the loadedFiles.Nothing sorts/filters by
FileSizein SQL, so in-memory/aggregate derivation is safe. No migration and no re-scan needed (per-file sizes are already stored).Tests
Adds a multi-file sum test to
AudiobookDtoFactoryTests(three files summed, not the primary file nor the stale scalar). Verified live: a 15-part book that showed ~4.7 MB now shows its correct ~70 MB total, and a previously blank book now shows its size.Closes #542.
🤖 Generated with Claude Code