docs(changelog): Dateinamen-Fehler richtig beschrieben (NN-NN im Kuenstlerfeld)
Die erste Fassung beschrieb einen anderen Mechanismus (doppelte Tracknummer aus dem Titel-Tag). Marcs Beispiel zeigt etwas anderes: 01-02 steht an der Stelle des Kuenstlers, die Tracknummer fehlt. trackPrefix kann diese Form nicht erzeugen, die Quelle muss also das Kuenstlerfeld so geliefert haben — dieselbe Form ist in metadata.test.js bereits als "garbage artist prefix" festgehalten. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
1 parent
871ecdd72e
commit
e8108b0a7a
1 file changed
+16
-10
+16
-10
@@ -768,16 +768,22 @@ Polish release: Android navigation and offline resilience, download accuracy for
|
||||
und ignoriert Akzente sowie Apostrophe (2.3). Ein Rest bleibt: steht derselbe Song unter einem
|
||||
**deutlich anderen** Künstlernamen (etwa vor einer Namenskorrektur), wird er weiterhin nicht
|
||||
erkannt und erneut geladen.
|
||||
- **Backend (Dateinamen)** — Doppelte Nummern im Dateinamen: `01 - Artist - 02 - Song.mp3` statt
|
||||
`01 - Artist - Song.mp3`. Der Dateiname entsteht als
|
||||
`{Tracknummer} - {Künstler} - {Titel}.{ext}` ([ytdlp.js](../backend/lib/ytdlp.js), Feld `fileBase`;
|
||||
dieselbe Form beim Umbenennen in `/api/edit-metadata`). Trägt das **Titel-Tag der Quelle schon
|
||||
eine Nummer** („02 - Song", bei Soundtracks und Sampler-Rips häufig), wird die eigene Nummer
|
||||
einfach davorgesetzt. Auffällig: die Dublettenprüfung räumt genau so etwas beim *Vergleich* bereits
|
||||
ab (`stem.replace(/^\d[\d-]*\s*[-–—]\s*/, '')` in [metadata.js](../backend/lib/metadata.js)) —
|
||||
beim *Erzeugen* des Namens fehlt diese Bereinigung. Vermutete Lösung: dieselbe Regex auf den Titel
|
||||
anwenden, bevor die Tracknummer vorangestellt wird; zu prüfen wäre, ob dabei Titel leiden, die
|
||||
legitim mit einer Zahl beginnen (etwa „700 Main Street" oder „1979").
|
||||
- **Backend (Dateinamen)** — Statt `{Tracknummer} - {Künstler} - {Titel}` entsteht gelegentlich
|
||||
ein Name der Form `NN-NN - {Titel}`, etwa
|
||||
`Rising Insane/DEATHRACE/01-02 - DEATHRACE.mp3`: an der Stelle des **Künstlers** steht `01-02`,
|
||||
und die Tracknummer fehlt ganz. Der Ordner (`Künstler/Album`) stimmt dabei, es betrifft nur den
|
||||
Dateinamen. Gebaut wird er in [ytdlp.js](../backend/lib/ytdlp.js) als
|
||||
`fileBase = {trackPrefix}{artist} - {title}` — das `01-02` muss also im **Künstlerfeld** der
|
||||
Quelle gestanden haben; `trackPrefix` kann diese Form gar nicht erzeugen (`padStart(2,'0')` auf
|
||||
eine Zahl). Dieselbe Form ist als Testfall festgehalten
|
||||
(`01-01 - Kingdom Hearts 2 - …`, [metadata.test.js:20](../backend/test/metadata.test.js)), dort
|
||||
ausdrücklich als „garbage artist prefix" — die Dublettenprüfung kommt damit zurecht, der
|
||||
Dateiname bleibt aber falsch.
|
||||
Nächster Schritt zur Eingrenzung: Tags der betroffenen Datei auslesen (`ffprobe -show_format`) und
|
||||
klären, über welchen Weg sie kam (Album-Download, Einzeltrack oder Importer) — daraus ergibt sich,
|
||||
welche Quelle das Künstlerfeld mit `NN-NN` füllt. Sinnvolle Absicherung unabhängig davon: einen
|
||||
Künstlernamen, der nur aus Ziffern und Bindestrichen besteht, verwerfen und auf den Album-Künstler
|
||||
zurückfallen, statt ihn in den Dateinamen zu übernehmen.
|
||||
- **Backend (download)** — Der Variantenfilter nutzt `\b`-Wortgrenzen, und die zählen den Unterstrich
|
||||
als Wortzeichen. Titel wie `song_instrumental_cover` oder `Easy_live` rutschen deshalb durch,
|
||||
während `Easy (Instrumental)` korrekt abgewiesen wird.
|
||||
|
||||
Reference in new issue
Block a user