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 88.23529% with 6 lines in your changes missing coverage. Please review.
✅ Project coverage is 74.68%. Comparing base (162913f) to head (4e60f86).
✅ All tests successful. No failed tests found.

Files with missing lines	Patch %	Lines
beetsplug/tidal/__init__.py	88.23%	4 Missing and 2 partials ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #6744      +/-   ##
==========================================
+ Coverage   74.61%   74.68%   +0.06%     
==========================================
  Files         163      163              
  Lines       20852    20893      +41     
  Branches     3289     3294       +5     
==========================================
+ Hits        15559    15603      +44     
+ Misses       4540     4536       -4     
- Partials      753      754       +1     

Files with missing lines	Coverage Δ
beets/importer/tasks.py	91.16% <ø> (ø)
beetsplug/tidal/__init__.py	89.38% <88.23%> (+3.97%)	⬆️

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

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

[arsaboo]

@semohr Excellent. Updated the other parts of the code. Everything is green.

[semohr]

Neat I will have another iteration at it tomorrow. Mainly tests and docs as I have not checked these in detail yet but than we should be good to go 👍

[arsaboo]

@semohr and @snejus, aside from the popularity issue, everything else should be addressed. I have kept both album and track popularity for now (but can update it if it is a blocker).

[semohr]

Lets get rid of the unrelated changes please 😆

[arsaboo]

Lets get rid of the unrelated changes please 😆

Most of the changes are to prevent the build from failing. Notice they are material changes, just reorganization to ensure that line length is less than 80.

[snejus]

@arsaboo are you going to undo unrelated changes or shall I commit that instead?

[arsaboo]

@arsaboo are you going to undo unrelated changes or shall I commit that instead?

It will be great if you can do it. I am stepping out for a few and will complete the remaining issues.

[semohr]

Thanks for the discussions and progress here!

[arsaboo]

Thanks, @semohr and @snejus, for patiently working on this and all the discussions.