Extract filename ID tokens into tags and backfill missing per-platform custom config#3
Merged
Merged
Conversation
…ames parse_template previously only recognized %title%, %artist%, %artists%, and stripped every other placeholder into an unnamed catch-all. That meant templates like `%artists%-%title%-%version%-%beatport_track_id%` could never populate a Beatport track ID tag that platform matchers could pick up. - parse_template now promotes any identifier-safe %name% into a named capture, so downstream code sees them in `Regex::captures`. - load_file always runs the filename regex when a template is provided (not only when title/artist are missing) and merges every named capture other than title/artists into `info.tags` under the uppercased key. ID3 tags on the file still win over filename-derived tags. With this, files whose names encode the Beatport track ID in the tail segment land BEATPORT_TRACK_ID in info.tags, which beatport.rs already checks in its "Fetch by ID" path. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
When the frontend hands us a TaggerConfig with an empty `custom` map,
every platform's match_track fails immediately on `get_custom("beatport")?`
with "Missing beatport custom config!" — before any actual tagging can
start. Runtime logs confirm this happens even when settings.json has the
custom map populated (the frontend isn't shipping it on tag start).
Fill in defaults from custom_default() at the top of Tagger::tag_files so
platforms stay functional regardless of what the frontend sends. Existing
per-platform values in `custom` are preserved via HashMap::entry.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
TX-RX
force-pushed
the
fix-beatport-filename-id
branch
from
July 8, 2026 17:49
374a837 to
09c50a5
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Two small changes that together let filename-encoded platform IDs (e.g. Beatport track ID as a trailing filename segment) actually flow through to the platform matchers.
1.
+ 'parse_template' +promotes arbitrary+ '%name%' +placeholdersBefore:
+ 'parse_template' +only recognized+ '%title%' +,+ '%artist%' +, and+ '%artists%' +. Every other placeholder got replaced by an unnamed+ '(.+)' +catch-all, so+ 'load_file' +never saw a named capture for it and couldn't populate anything in+ 'info.tags' +.After: identifier-safe placeholders become named captures. Legacy templates with spaces in placeholder names still fall through to the old catch-all path unchanged.
2.
+ 'load_file' +always runs the filename regex and merges extras into tagsBefore: filename parsing only ran when the file was missing a title or artist tag.
After: the regex always runs when a template is configured. Title/artist behavior is unchanged (still only overridden when missing). Any other named captures —
+ 'beatport_track_id' +,+ 'beatsource_track_id' +, etc. — get uppercased and merged into+ 'info.tags' +via+ 'entry().or_insert()' +, so existing ID3 tags still win on collision.Beatport's
+ 'match_track' +already checks+ 'info.tags.get("BEATPORT_TRACK_ID")' +in its "Fetch by ID" path, so this immediately gives us direct-ID lookup for any filename that encodes the ID.3.
+ 'Tagger::tag_files' +backfills missing per-platform custom configsRuntime logs show that the frontend sometimes ships a
+ 'TaggerConfig' +with an empty+ 'custom' +map even when+ 'settings.json' +has the platform blocks populated. That trips+ 'get_custom("beatport")?' +with "Missing beatport custom config!" before anything can happen. This fills in defaults from+ 'TaggerConfig::custom_default()' +at the top of+ 'tag_files' +— existing per-platform values are preserved via+ 'HashMap::entry' +. Not a fix for the underlying client-side bug (that lives in+ 'client/src/scripts/onetagger.ts' +), but a hard guard so the backend stays usable regardless.Test evidence
Regex validated against real filenames — 23/23 test files parse correctly with the template
+ '%artists%-%title%-%version%-%beatport_track_id%' +(validation script tested standalone).Ordering
This can merge before or after #1 (PR 523 backport) — they touch different files.