tidal: Add flexible attributes and tidalsync command for popularity data

[arsaboo]

This PR adds six typed flexible attributes to the Tidal plugin that are populated during album/track imports, and introduces a new beet tidalsync command to refresh popularity data post-import.

cc: @semohr

Flexible Attributes (item_types)

• tidal_track_id, tidal_album_id, tidal_artist_id — INTEGER fields for Tidal entity IDs.
• tidal_track_popularity, tidal_alb_popularity — INTEGER (0–100) normalized popularity scores.
• tidal_updated — DATE timestamp of last sync.

Import population

• _get_album_info() and _get_track_info() pass the new fields through to AlbumInfo / TrackInfo, which store them as flexattrs on the item.
• _popularity() helper normalizes float/int/None from the Tidal API.

Reimport support

• All Tidal fields added to REIMPORT_FRESH_FIELDS_ITEM so they refresh on reimport.

beet tidalsync command

• Iterates library items, looks up each track by tidal_track_id, and updates tidal_track_popularity + tidal_updated.
• --force/-f — re-fetch even if data already exists.
• --write/-w — write updated tags to media files.
• Accepts an optional query to filter items (e.g., beet tidalsync artist:Miles).

Documentation & Tests

• Attribute reference table and command usage examples in
  docs/plugins/tidal.rst.

• Flexattr assertions in existing tests, new TestPopularity and
  TestTidalsync test classes.

• 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.)

• Tests. (Very much encouraged but not strictly required.)

[codecov]

Codecov Report

❌ Patch coverage is 66.21622% with 25 lines in your changes missing coverage. Please review.
✅ Project coverage is 74.54%. Comparing base (60047df) to head (b85e5ec).
✅ All tests successful. No failed tests found.

Files with missing lines	Patch %	Lines
beetsplug/tidal/__init__.py	66.21%	18 Missing and 7 partials ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #6744      +/-   ##
==========================================
+ Coverage   74.52%   74.54%   +0.01%     
==========================================
  Files         162      162              
  Lines       20818    20882      +64     
  Branches     3295     3315      +20     
==========================================
+ Hits        15515    15566      +51     
- Misses       4547     4555       +8     
- Partials      756      761       +5     

Files with missing lines	Coverage Δ
beets/importer/tasks.py	90.95% <ø> (ø)
beetsplug/tidal/__init__.py	82.73% <66.21%> (-2.68%)	⬇️

... 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.

[semohr]

It looks like we're now storing the same track ID twice in the database: track_id and tidal_track_id.
Summoning @snejus ;) What's our preferred approach here? Should we consolidate these?

**same for artist_id

[arsaboo]

I am not sure we can consolidate. All the other plugins (bandcamp, spotify, etc. store bandcamp_album_id, spotify_album_id as flexattrs). Until we can make musicbrainz completely optional, I feel we keep them for consistency with the plugin ecosystem pattern (other metadata plugins store their own *_id flexattrs), but we should get @snejus's input.

Also makes queries like tidal_track_id unambiguous without needing to know which standard field maps to which source.

[semohr]

Sorry about the iterative comments. Im coming back to this whenever I have time or thought about something ;)

I just noticed that albums on tidal also have popularity values. I would vote we make popularity work for both tracks and albums (currently it only works for tracks, right?). Maybe a general tidal_popularity flex attribute could work?

---

I'm also able to make some changes if you feel like it gets too much give me a headsup 😨

[arsaboo]

Sorry about the iterative comments. Im coming back to this whenever I have time or thought about something ;)

I just noticed that albums on tidal also have popularity values. I would vote we make popularity work for both tracks and albums (currently it only works for tracks, right?). Maybe a general tidal_popularity flex attribute could work?

I'm also able to make some changes if you feel like it gets too much give me a headsup 😨

We have tidal_album_popularity to be explicit and avoid any confusion. Updated the parsing based on your comments.

Please don't worry about it. Happy to work with you on this and get this merged. Thanks for all your guidance, and by all means, feel free to improve upon it.

[semohr]

We have tidal_album_popularity to be explicit and avoid any confusion. Updated the parsing based on your comments.

Im not entirely sure how the best UX should look like here tbh. Both variants (with and without prefix) come with tradeoffs 🤔

[arsaboo]

We have tidal_album_popularity to be explicit and avoid any confusion. Updated the parsing based on your comments.

Im not entirely sure how the best UX should look like here tbh. Both variants (with and without prefix) come with tradeoffs 🤔

We are not currently exposing popularity information in UI. This is mostly for the DB so that we can use it for other smart things (playlists)

[semohr]

We are not currently exposing popularity information in UI. This is mostly for the DB so that we can use it for other smart things (playlists)

I mean the query syntax with UX. The question is whether users should have separate fields per entity, such as:

beet ls tidal_album_popularity:5..20

or a single generic field whose meaning depends on the search scope, for example:

beet ls tidal_popularity:5..50 -a

The latter is shorter and more flexible, but the former is more explicit and consistent across entity types.

[arsaboo]

We are not currently exposing popularity information in UI. This is mostly for the DB so that we can use it for other smart things (playlists)

I mean the query syntax with UX. The question is whether users should have separate fields per entity, such as:

beet ls tidal_album_popularity:5..20

or a single generic field whose meaning depends on the search scope, for example:

beet ls tidal_popularity:5..50 -a

The latter is shorter and more flexible, but the former is more explicit and consistent across entity types.

I would (strongly) prefer the former, just to be explicit.

[semohr]

@arsaboo Just enhanced the sync logic a bit. Make sure to pull ;) Please have a look! Am mostly happy with the changes but ofcourse if you see something or have a better idea, lets discuss.