Avoid writing unknown track and disc totals

[Tsuizxgo]

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.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 75.65%. Comparing base (6f8d55d) to head (db15156).

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #6655      +/-   ##
==========================================
+ Coverage   75.63%   75.65%   +0.02%     
==========================================
  Files         162      162              
  Lines       20820    20833      +13     
  Branches     3298     3299       +1     
==========================================
+ Hits        15747    15762      +15     
+ Misses       4292     4291       -1     
+ Partials      781      780       -1     

Files with missing lines	Coverage Δ
beets/dbcore/types.py	97.20% <100.00%> (+0.15%)	⬆️
beets/library/fields.py	100.00% <ø> (ø)
beets/library/models.py	87.76% <ø> (ø)

... and 1 file 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]

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]

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]

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?

[Tsuizxgo]

Hi @ShimmerGlass, sorry for the ping.

I updated the PR to address the field-type-level approach you suggested. tracktotal and disctotal now use a nullable padded integer type, so unknown totals are normalized/formatted as empty values instead of only being handled at the final tag-writing stage.

I also added coverage for the new type behavior, formatted output, beet info --library, and media tag writing. The recent conflicts should be resolved now as well.

When you have time, could you please take another look? Thanks!

[Tsuizxgo]

Hi @semohr, sorry for another ping, specifically on #6655.

I just merged the latest master into this branch again and resolved the docs/changelog.rst conflict caused by the recently merged replace PR. The PR is now updated at db15156ca, and the branch should be ready for checks/review again.

This PR is part of my course open-source contribution assignment, and the bonus deadline is today, so I am a bit anxious about the timing. I completely understand that maintainers are busy and that merge decisions should follow the project’s normal review process. If you happen to have time to take another look today, I would really appreciate it.

Thank you!