From e8108b0a7a122f7fcb9065245709594fefb409f0 Mon Sep 17 00:00:00 2001 From: marc Date: Sun, 6 Sep 2026 23:46:47 +0200 Subject: [PATCH] docs(changelog): Dateinamen-Fehler richtig beschrieben (NN-NN im Kuenstlerfeld) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 --- CHANGELOG.md | 26 ++++++++++++++++---------- 1 file changed, 16 insertions(+), 10 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index e678363..13b22f0 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -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.