docs: Entwurf fuer die Konzert-Meldungen im Backlog festhalten

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
marcandClaude Opus 5 committed 2026-09-25 17:56:17 +02:00
1 parent 7879e37a7b
commit 1366ec3832
1 file changed
+19 -2
+19 -2
View File
@@ -1319,8 +1319,25 @@ Polish release: Android navigation and offline resilience, download accuracy for
Daten liegen schon vor (`POST /api/artist-releases`), es fehlt der Vergleich „was ist seit Daten liegen schon vor (`POST /api/artist-releases`), es fehlt der Vergleich „was ist seit
deinem letzten Besuch dazugekommen" und der Eintrag in der vorhandenen Benachrichtigungsglocke deinem letzten Besuch dazugekommen" und der Eintrag in der vorhandenen Benachrichtigungsglocke
(wahlweise Push). (wahlweise Push).
- **Konzert-Meldungen:** die vorhandene **Ticketmaster**-Anbindung wiederverwenden und melden, - **Konzert-Meldungen:** die vorhandene **Ticketmaster**-Anbindung wiederverwenden und zeigen,
wenn ein gefolgter Künstler in der Nähe spielt. Bewusst zurückgestellt — erst die Neuheiten. wann gefolgte Künstler spielen. Bewusst zurückgestellt — erst die Neuheiten. Der Entwurf steht
aber schon (25.9.2026):
- **Ein Einstieg, zwei Reiter**, kein zweiter Knopf in der Favoriten-Kopfzeile. Neuheiten und
Konzerte sind dasselbe Thema; zwei Knöpfe drängeln sich, und man muss sich merken, welcher
was zeigt. Die Zeitleiste bekommt oben *Neu erschienen* / *Konzerte*, die Tages-Chips
(90/30/365) gelten nur für die Neuheiten.
- **Nicht in eine gemeinsame Liste mischen.** Veröffentlichungen liegen in der Vergangenheit,
Konzerte in der Zukunft. Chronologisch gemischt stünde „heute" mittendrin und man wüsste nie,
ob man gerade vorwärts oder rückwärts liest.
- **Ort erst später, dann per `.env` im Backend** (Land, optional Stadt und Umkreis). Fürs
Erste reicht, was die API von sich aus liefert — die Abfrage sucht heute weltweit
(`/api/events/:artist`, `keyword=`, `size=20`, nach Datum sortiert).
- **Offene Schwachstelle: die Abfrage läuft über den Namen, nicht über eine ID.** Dieselbe
Falle wie bei der Deezer-Zuordnung — „TPR" oder „MORE" treffen als Stichwort alles Mögliche.
Ticketmaster hat dafür `attractionId`; die einmal pro Künstler auflösen und zwischenspeichern,
so wie die Deezer-IDs.
- Aufwandsseite unkritisch: eine Anfrage pro Künstler, im Backend gecacht wie die Releases. Bei
50 Künstlern und sechs Stunden Haltbarkeit bleibt das weit unter Ticketmasters Tagesgrenze.
- **Android** — Playlist drag-and-drop / sort order - **Android** — Playlist drag-and-drop / sort order
- **Android** — Artist page iTunes fallback (for artists not in Navidrome) - **Android** — Artist page iTunes fallback (for artists not in Navidrome)
- **Android** — Romaji / Japanese sort support - **Android** — Romaji / Japanese sort support