Skip to content

Conversation

@gcoppola19
Copy link

Fixes 6092

Add a media field for album, when a user runs beets fields, media will be listed for album. This way, media of album can be kept track of.

Documentation. (If you've added a new command-line flag, for example, find the appropriate page under docs/ to describe it.)
Changelog. (Add an entry to docs/changelog.rst to the bottom of one of the lists near the top of the document.)
[x ] Tests.
test_media_field.py

@gcoppola19 gcoppola19 requested a review from a team as a code owner November 8, 2025 19:26
Copy link
Contributor

@sourcery-ai sourcery-ai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey there - I've reviewed your changes and they look great!


Sourcery is free for open source - if you like our reviews please consider sharing them ✨
Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.

@henry-oberholtzer
Copy link
Member

Hi Grace! Thanks for the PR and your interest in contributing to Beets!

We currently have the media field provided by the Item class, which represents an individual song or track, which currently can be queried on an album level, and allows support for albums to have tracks from different media types (e.g. tracks from both CD and DVD ripped to digital file).

If there's a use case that isn't addressed by the current implementation, more context & background for the issues this addresses would be appreciated!

Thanks!

@endcredits33
Copy link

Hi @henry-oberholtzer, I created the original issue. The context here is when you run certain queries at album level, $media is not provided as it is not an album level field.

For example, running beet ls -af '$albumartist - $album ($media)' label:Nonplus gives:

Actress - Harrier ATTK / Gershwin ($media)
Actress - Machine And Voice ($media)
ASC - Nothing Is Certain ($media)
ASC - Nothing Is Certain LP Sampler ($media)
ASC - Porcelain / Focus Inwards ($media)
Barry Manalogue - Analogue / Koyo Front ($media)

@arsaboo
Copy link
Contributor

arsaboo commented Nov 12, 2025

@endcredits33 indeed, because media for an album does not always make sense. What would you expect if one of the tracks is vinyl and the other track is DVD-ripped?

@henry-oberholtzer
Copy link
Member

@endcredits33 @gcoppola19 Ah, I see! I missed that.

I could see the album level query returning a list of the distinct media types from its tracks? I assume we never have albums without at least one Item.

@endcredits33
Copy link

@endcredits33 indeed, because media for an album does not always make sense. What would you expect if one of the tracks is vinyl and the other track is DVD-ripped?

Is this a common occurence? I think generally most releases tend to have a single media type. At the moment we're not displaying media at all for albums just because some releases may contain several types.

@henry-oberholtzer
Copy link
Member

I think we need to be able to account for those instances, even if they're rare, and it should be possible to through DB queries.

@gcoppola19
Copy link
Author

gcoppola19 commented Nov 12, 2025

@henry-oberholtzer @endcredits33 Can I work on implementing this? Where for an album, it would list all media types of the songs in the album?

@arsaboo
Copy link
Contributor

arsaboo commented Nov 12, 2025

I don't see the value of doing this. Have you tried album_fields?

@endcredits33
Copy link

Couldn't we make the same argument about other fields, e.g label, genre, catalog number? These can vary across the same release (anecdotally more often than media) and yet they are included as album level fields.

@gcoppola19
Copy link
Author

I wanted to implement it so that if a user wants to see the media types of songs in an album, it lists all the types, and made test cases to test if there was one media type, none, or multiple. Let me know if it needs any chances in functionality, I hope it's helpful!

@codecov
Copy link

codecov bot commented Dec 8, 2025

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 67.94%. Comparing base (2bd77b9) to head (401b51f).
✅ All tests successful. No failed tests found.

Additional details and impacted files
@@            Coverage Diff             @@
##           master    #6152      +/-   ##
==========================================
+ Coverage   67.93%   67.94%   +0.01%     
==========================================
  Files         137      137              
  Lines       18677    18683       +6     
  Branches     3155     3157       +2     
==========================================
+ Hits        12688    12694       +6     
  Misses       5324     5324              
  Partials      665      665              
Files with missing lines Coverage Δ
beets/library/models.py 87.20% <100.00%> (+0.02%) ⬆️
beetsplug/discogs.py 71.14% <100.00%> (+0.36%) ⬆️
🚀 New features to boost your workflow:
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

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.

4 participants