diff --git a/CHANGELOG.md b/CHANGELOG.md index f61281a..c5b58db 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -3,6 +3,9 @@ All notable changes to NovaSonic are documented here. Format follows [Keep a Changelog](https://keepachangelog.com/en/1.0.0/). Versioning: two-part `MAJOR.MINOR` — each release bumps the minor (features and fixes together). +Die Android-App zählt eigenständig weiter (mehrere APKs pro Release). Welche das waren, steht in einer +**Android:**-Zeile direkt unter der Release-Überschrift — die Einträge darunter beschreiben nur noch, +*was* sich geändert hat, nicht in welchem APK. --- @@ -72,8 +75,9 @@ Versioning: two-part `MAJOR.MINOR` — each release bumps the minor (features an ## [2.5] — 2026-09-10 +**Android:** 1.8 (versionCode 11) — Sprung vom Album zum Künstler. + ### Added -- **Android 1.8 (versionCode 11)** — enthält den Sprung vom Album zum Künstler (siehe unten). - **Vom Album zum Künstler springen (Web + Android)** — in der globalen Suche führte ein Album bisher in eine Sackgasse: der Künstlername darunter war reiner Text. Wer von dort zum Künstler wollte, musste zurück und neu suchen. Der Name ist jetzt anklickbar und öffnet dieselbe @@ -105,39 +109,40 @@ Versioning: two-part `MAJOR.MINOR` — each release bumps the minor (features an ## [2.4] — 2026-09-06 +**Android:** 1.4 (versionCode 7) → 1.7 (versionCode 10). 1.4 brachte Warteschlangen-Wiederherstellung +und die Streitpunkte im Duell, 1.6 machte das Wiederherstellen rein lokal und damit sofort, 1.7 leert +den Cache nach einem Update selbst. + ### Added -- **Android 1.7 (versionCode 10): Cache räumt sich nach einem Update selbst auf** — im `cacheDir` +- **Cache räumt sich nach einem Update selbst auf (Android)** — im `cacheDir` liegen Coils Bildspeicher (Cover) und heruntergeladene APK-Updates. Blieb dort nach einer neuen Version etwas Altes liegen, half nur „Cache leeren" von Hand in den Systemeinstellungen — nichts, das man einem normalen Nutzer erklären möchte. Beim ersten Start nach einem Versionswechsel wird der Cache jetzt einmalig geleert; im laufenden Betrieb passiert nichts, sonst wären die Cover bei jedem Start neu zu laden. **Offline-Downloads sind nicht betroffen**, die liegen unter `filesDir/offline` und damit außerhalb des Caches. -- **Android 1.6 (versionCode 9): Warteschlange ist sofort da** — bisher wurden nur die Song-Ids - gesichert und beim Start **einzeln nacheinander über das Netz** nachgeladen. Das dauerte Sekunden, - klappte mal und mal nicht und ohne Verbindung gar nicht. Jetzt liegen die vollständigen Songs als - JSON im Gerätespeicher — das Wiederherstellen ist ein rein lokaler Lesevorgang, wie im Web. Preis: - zwischenzeitlich geänderte Titel oder Cover zeigen bis zum nächsten Abspielen den alten Stand. - Zusätzlich sichert `MusicService.onTaskRemoved` die Warteschlange, wenn die App aus den letzten - Apps gewischt wird — dabei feuert `onIsPlayingChanged` nicht zuverlässig, genau dieser Fall ging - vorher verloren. Protokoll unter dem Tag `NsQueue` (`adb logcat -s NsQueue`). - **Service-Worker-Cache versioniert sich beim Bauen selbst** — die Cache-Version stand handgepflegt als `ns-v78` in `sw.js` und wurde beim Ausliefern zuverlässig vergessen. Da die Aktivierung nur Caches mit *abweichendem* Namen löscht, blieb der alte bestehen und Nutzer mussten den Browsercache von Hand leeren. Ein Vite-Plugin setzt die Version jetzt aus der Bauzeit (`ns-JJJJMMTThhmmss`), der alte Cache räumt sich beim ersten Start selbst ab. Die Quelldatei bleibt unverändert. -- **Android 1.4 (versionCode 7)** — erste Version mit Warteschlangen-Wiederherstellung und den - Streitpunkten im Duell. Hinweis fürs Testen: der gespeicherte Zustand entsteht erst mit dieser - Version, direkt nach der Installation ist die Leiste also noch leer — einmal abspielen, App - schließen, wieder öffnen. -- **Zuletzt Gehörtes überlebt den Neustart (Web + Android)** — Android sicherte bisher nur den - letzten Song, ohne Warteschlange: die Now-Playing-Leiste blieb nach dem Öffnen **leer, bis man - einmal auf Play drückte**. Jetzt merken sich beide Plattformen Warteschlange und aktuellen Titel - und stellen sie beim Start wieder her — Android **vorbereitet, aber nicht abgespielt**, damit - einen die App beim Öffnen nicht überfällt; läuft schon etwas, passiert nichts. Der Titel beginnt - von vorn: die Sekunde im Titel wird bewusst **nicht** gespeichert, das spart dauerndes Schreiben - während der Wiedergabe. Gesichert werden nur Song-Ids, weil Titel und Cover sich durch - Metadaten-Bearbeitung ändern können; verschwundene Titel werden übersprungen. +- **Zuletzt Gehörtes und Warteschlange überleben den Neustart (Web + Android)** — Android sicherte + bisher nur den letzten Song, ohne Warteschlange: die Now-Playing-Leiste blieb nach dem Öffnen + **leer, bis man einmal auf Play drückte**. Jetzt merken sich beide Plattformen Warteschlange und + aktuellen Titel und stellen sie beim Start wieder her — Android **vorbereitet, aber nicht + abgespielt**, damit einen die App beim Öffnen nicht überfällt; läuft schon etwas, passiert nichts. + Der Titel beginnt von vorn: die Sekunde im Titel wird bewusst **nicht** gespeichert, das spart + dauerndes Schreiben während der Wiedergabe. + - Der erste Anlauf (1.4) sicherte nur Song-Ids und lud sie beim Start **einzeln nacheinander über + das Netz** nach: das dauerte Sekunden, klappte mal und mal nicht und ohne Verbindung gar nicht. + Seit 1.6 liegen die vollständigen Songs als JSON im Gerätespeicher, das Wiederherstellen ist ein + rein lokaler Lesevorgang wie im Web. Preis: zwischenzeitlich geänderte Titel oder Cover zeigen + bis zum nächsten Abspielen den alten Stand. + - `MusicService.onTaskRemoved` sichert die Warteschlange auch, wenn die App aus den letzten Apps + gewischt wird — dabei feuert `onIsPlayingChanged` nicht zuverlässig, genau dieser Fall ging + vorher verloren. Protokoll unter dem Tag `NsQueue` (`adb logcat -s NsQueue`). + - Hinweis fürs Testen: der gespeicherte Zustand entsteht erst ab dieser Version, direkt nach der + Installation ist die Leiste also noch leer — einmal abspielen, App schließen, wieder öffnen. - **Streitpunkte im Musik-Duell (Web + Android)** — gemeinsame Künstler, sortiert nach dem größten **Ungleichgewicht** statt nach der Summe: wo einer 120 Plays hat und der andere 3. Ein Balken @@ -148,6 +153,12 @@ Versioning: two-part `MAJOR.MINOR` — each release bumps the minor (features an ## [2.3] — 2026-09-04 +**Android:** versionCode 3 → 1.3 (versionCode 6). versionCode 3 lieferte den Alben-Tab-Fix aus und +erstmals das Scroll- und Suchgedächtnis der Künstlerseite (2.2 enthielt den Code, das damalige APK +war älter); 1.1 brachte Teilen-Link, Songlöschen, Playlist aus dem Import und die Duell-Anzeigetafel; +1.2 und 1.3 nahmen die Adressen aus den Einstellungen in den Build. Alle mit demselben Debug-Schlüssel +signiert, Updates laufen also in-place und App-Daten bleiben. + ### Fixed - **YT-Music-Suche war praktisch tot** — `getYtmVideoUrls` verwarf die komplette Trefferliste, sobald irgendwo ein Kanal-Eintrag (`browse/UC…`) auftauchte, samt der bereits gesammelten Song-URLs. An @@ -228,18 +239,17 @@ Versioning: two-part `MAJOR.MINOR` — each release bumps the minor (features an mutiert, um unter Windows das Neuaufbauen der Medienkachel zu vermeiden. Über MPRIS kam davon nichts an: Plasma-Widgets zeigten dauerhaft den zuerst gespielten Titel. Bei echtem Titelwechsel wird jetzt ein neues `MediaMetadata` zugewiesen, sonst weiter in-place (Cover-Nachladen). -- **Android 1.3 (versionCode 6): keine Adressen mehr eintippen** — Navidrome-, Backend- und +- **Keine Adressen mehr eintippen (Android)** — Navidrome-, Backend- und Scrobble-Adresse kommen als Vorgabe aus dem Build (`-PnovasonicNavidrome=` / `-PnovasonicBackend=` / `-PnovasonicScrobble=`, gepflegt in `scripts/.env.release`). Sie greifen, wenn im Gerätespeicher nichts steht; die Felder in den Einstellungen bleiben sichtbar und überschreibbar, damit ein Umzug am Gerät korrigierbar ist statt per neuem APK. Beim ersten Start ist nur noch **Benutzer und Passwort** einzugeben — Zugangsdaten werden bewusst *nicht* eingebacken, die gehören pro Person. -- **Android 1.2 (versionCode 5)** — die Web-Adresse ist keine Einstellung mehr, sondern kommt aus +- **Die Web-Adresse ist keine Einstellung mehr (Android)** — sie kommt aus `BuildConfig.SHARE_HOST`, also aus **derselben** Angabe (`-PnovasonicHost=…`), die ohnehin für die App-Links ins Manifest wandert. Damit gibt es keine vierte Adresse zu pflegen, „Teilen" ist immer sichtbar, und ein- und ausgehende Links können nicht mehr auseinanderlaufen. -- **Android 1.1 (versionCode 4)** — erste Version mit Teilen-Link, Songlöschen, Playlist aus dem - Import und Duell-Anzeigetafel. Wichtig für den In-App-Updater: er vergleicht den `versionCode` aus +- **Falle beim Veröffentlichen** — der In-App-Updater vergleicht den `versionCode` aus der Gitea-Release-Beschreibung mit dem der installierten App. Wird die Version nicht angehoben **oder** die Beschreibung nicht mitgepflegt (etwa beim Hochladen von Hand statt über `npm run publish-apk`), meldet die App korrekt „kein Update" — obwohl ein neues APK bereitliegt. @@ -286,12 +296,6 @@ host), and the scroll memory from 2.2 finally behaves on the Alben tab. an album discarded the position the ViewModel had correctly kept. Scrolling to the top now happens in `LibraryViewModel.setAlbumSort()`, on a real sort change only. -### Changed -- **APK release at versionCode 3** — carries the Alben-tab fix above and, for the first time in a - published build, the artist-page and "Alle anzeigen" overlay scroll/search memory (2.2 shipped the - code, but the release APK predated it). Signed with the established debug key, so it installs - in place over versionCode 2 and app data survives. - --- ## [2.2] — 2026-08-22