Skip to content

Avoid writing unknown track and disc totals#6655

Open
Tsuizxgo wants to merge 3 commits into
beetbox:masterfrom
Tsuizxgo:fix-unknown-track-disc-totals
Open

Avoid writing unknown track and disc totals#6655
Tsuizxgo wants to merge 3 commits into
beetbox:masterfrom
Tsuizxgo:fix-unknown-track-disc-totals

Conversation

@Tsuizxgo
Copy link
Copy Markdown

@Tsuizxgo Tsuizxgo commented May 19, 2026

Description

Fixes #6194.

This PR fixes how beets represents unknown tracktotal and disctotal values.

When tracktotal or disctotal is unknown, beets may store it internally as 0. Previously that value could surface as 00 in library/template output and could be written into audio file tags, producing metadata like track 1/0 or disc 2/0.

This change treats 0 totals as unknown at the field type level for tracktotal and disctotal. Those fields now normalize 0 to None, format as empty in library output such as beet info --library, and naturally omit/clear the corresponding media tags when writing files.

The actual track and disc numbers are still written and formatted normally.

To Do

  • Documentation. This is a bug fix in existing behavior and does not add or change any user-facing command or config option.
  • Changelog. Added an entry to docs/changelog.rst.
  • Tests. Added regression coverage for formatting, beet info --library, field normalization, and file writing.

@Tsuizxgo Tsuizxgo requested a review from a team as a code owner May 19, 2026 06:30
@codecov
Copy link
Copy Markdown

codecov Bot commented May 19, 2026

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 72.62%. Comparing base (fc9c02a) to head (8a1b010).
⚠️ Report is 122 commits behind head on master.

Additional details and impacted files
@@            Coverage Diff             @@
##           master    #6655      +/-   ##
==========================================
+ Coverage   72.44%   72.62%   +0.18%     
==========================================
  Files         160      162       +2     
  Lines       20690    20824     +134     
  Branches     3272     3294      +22     
==========================================
+ Hits        14989    15124     +135     
- Misses       4976     4978       +2     
+ Partials      725      722       -3     
Files with missing lines Coverage Δ
beets/dbcore/types.py 97.20% <100.00%> (+0.60%) ⬆️
beets/library/fields.py 100.00% <ø> (ø)
beets/library/models.py 87.67% <ø> (+0.65%) ⬆️

... and 85 files with indirect coverage changes

🚀 New features to boost your workflow:
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@ShimmerGlass
Copy link
Copy Markdown
Contributor

hey @Tsuizxgo! thank you for your contribution :)

When tracktotal or disctotal is unknown, beets may store it internally as 0

Do you know if this always happens or is it a bug in metadata source(s) ?

@Tsuizxgo
Copy link
Copy Markdown
Author

hey @Tsuizxgo! thank you for your contribution :)

When tracktotal or disctotal is unknown, beets may store it internally as 0

Do you know if this always happens or is it a bug in metadata source(s) ?

Thanks for checking!

It does not necessarily mean that the metadata source explicitly returns 0.

Tracktotal and disctotal are PaddedInt fields in beets, and their null/default value is effectively 0. So if a media file or metadata source does not provide a total value, that missing value can end up represented as 0 inside the beets item/library model. And this bug happened at this time. If the tracktotal and disctotal are not 0, the bug would not happen.

@ShimmerGlass
Copy link
Copy Markdown
Contributor

Your change sets those tags back to None if they are 0, which is certainly better than what we have today.

However this fix is at the last stage: when we write tags. If my understanding is correct things like beet info, using $disctotal, etc. will continue to report 0 when they shouldn't.

their null/default value is effectively 0.

I think that's our core issue here. If we fixed this default value we wouldn't need special handling for these fields, and everything should report None/empty, including the tags.

Wdyt? Would you have time to look into that?

Copy link
Copy Markdown
Author

Tsuizxgo commented Jun 1, 2026

Thanks for the guidance. I updated the PR to address the underlying model-level behavior instead of only changing the final tag-writing step.

The new version adds a nullable padded integer type for tracktotal and disctotal, so 0 is normalized to None for those total fields. That means library/template output such as beet info --library now shows the totals as empty rather than 00, and file writing naturally omits/clears those media tags without a write-specific special case.

I also added regression coverage for:

  • formatting unknown totals as empty,
  • beet info --library not reporting 00,
  • writing files without tracktotal/disctotal set to 0,
  • the new nullable padded integer type behavior.

Focused local test run:

BEETSDIR=/private/tmp/beets-test-config UV_CACHE_DIR=/private/tmp/uv-cache uv run pytest test/test_types.py test/test_library.py test/plugins/test_info.py
# 190 passed, 2 skipped

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Disable writing "0" to music files for total tracks/discs when values aren't available

2 participants