Commit Graph
6 Commits
Author SHA1 Message Date
HoneyandClaude Opus 4.8 1e206e8df3 fix(web): 'Unknown Artist' download from artist page + rename itunes*→deezer* identifiers
Fix (the reported bug):
- Deezer's /artist/{id}/albums omits the artist object, so discography album cards had an
  empty artist name → the download modal fell back to the literal "Unknown Artist", which
  poisoned the yt-dlp search ("Unknown Artist <album>") and its artist/channel filter, failing
  with "Nicht eindeutig gefunden".
- deezerLookupArtistAlbums now backfills the known artist name (we're on that artist's page).
- openDlModal now defaults album cards to an ALBUM download (was always Track), so a one-click
  download no longer grabs an album as a single track named after the album.

Rename (requested cleanup, dependency-checked so nothing breaks):
- All frontend itunes* identifiers → deezer* (functions, the ItunesItem-shape field keys
  itunesData/itunesArtistId/itunesFanCount/itunesId, the itunes-album-detail route + DOM ids,
  the badge-itunes CSS class). The backend reads none of these fields, so the boundary is safe.
- Verified: build passes; route/DOM-id/CSS producer↔consumer all consistent; only the factual
  "Apple's iTunes /search 403" comments keep the historical name. SW ns-v62.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-08-01 00:31:09 +02:00
HoneyandClaude Opus 4.8 065d2f7319 feat: disambiguate same-name artists by Deezer fan count + show fans
Deezer's artist search doesn't rank by popularity, so a name collision (5 artists named
"Joji") returned a niche one first (62 fans) instead of the real Joji (559k) — the artist
page then loaded the wrong discography and owned songs didn't show as downloaded.

- api.js: _dzArtist carries fanCount (nb_fan); artist search sorts by fanCount desc.
- search.js: artist cards show the fan count as subtitle; fan count passed to the artist page.
- detail.js: pick the most-popular name match (not the first); for local Navidrome artists
  with a real collision (>=2 same-name candidates), tie-break by SONG OVERLAP — prefer the
  Deezer candidate whose top tracks actually overlap the library (each artist has different
  songs, so this nails the right person). Costs a few calls only on a collision.
- Artist hero shows "<n> Fans" (immediately for global-search artists, after match for local).
- Android: DzArtist.nb_fan + /search/artist sorted by nb_fan so the right artist is first.
- Also: web global-search "unavailable" message now says Deezer, not Apple. SW ns-v52.

Verified live against Deezer: both fan-sort and overlap select the real Joji (id 5078097).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-31 16:11:45 +02:00
HoneyandClaude Opus 4.8 a65613b5a1 fix(web): Deezer artist images + rename the search label
- Search artist cards now use the Deezer artist picture directly (Deezer artists carry
  a photo, unlike iTunes entities) instead of a null image + an extra album lookup;
  the lookup stays only as a fallback when no picture is present.
- Non-local (Deezer) artist pages: fetch the Deezer artist picture (/artist/{id}) for
  the hero photo, which was blank because getArtistImage only runs for Navidrome artists.
- Label "iTunes Künstler" → "Deezer Künstler".

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-30 22:01:59 +02:00
HoneyandClaude Opus 4.8 ccf704754a fix(web): proxy Apple charts (CORS) + clear message when Apple search is blocked
Confirmed via curl from a clean IP: Apple's iTunes /search returns 403 (blocked
server-side, likely datacenter-IP anti-scraping) while /lookup?id= still returns 200.
So the Erkunden Apple search fails through no fault of ours.

- Charts: the "most-played" RSS (rss.applemarketingtools.com) was fetched directly
  from the browser and hit CORS; proxy it via /api/itunes-charts/:kind.
- Error visibility: itunesSearch records the last outcome (HTTP status / network);
  the global-search view now shows "Apple-Suche gerade nicht verfügbar" with the
  reason (403 = Apple blocks the API, not you) instead of a blank "no results".
- iTunes proxy now forwards the upstream status code instead of always 200.

Deezer (free, no key, ~50 req/5s) is the planned search fallback; MusicBrainz is too
rate-limited (1/s) for interactive search.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-30 20:32:08 +02:00
HoneyandClaude Opus 4.8 1e242796fe feat(web+android): search play queues only the tapped song (radio fills the rest)
Playing a song from search results queued the whole result list. Now it plays only
the clicked song; Radio mode, if on, fills the rest — closer to Spotify. Both
platforms already trigger a radio top-up on the first track (web playQueue →
fillRadioQueue; Android onMediaItemTransition → checkRadioRefill), so no extra wiring
is needed. Album/playlist play still queues the full list. Bump SW cache to ns-v44.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-25 22:00:58 +02:00
HoneyandClaude Sonnet 4.6 2a2e5ea495 refactor: split views/views.js into 6 focused modules
navigation.js  — navigate(), history, closeHeaderSearch, _navGoBack
home.js        — home page, genres, album rows, loadArtists/loadAlbums, getArtistImage
detail.js      — artist/album/iTunes detail pages, quickPlay helpers, expandArtistBio
playlists.js   — playlists, playlist detail, reorder, starred, random
search.js      — local/header/global search, iTunes helpers, s_goArtist, playerBarGoX
discover.js    — new releases, recommendations (Last.fm + iTunes fallback)
views.js       — barrel re-export; all external imports unchanged

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
2026-06-07 13:50:36 +02:00