RE-KORD 5.2

Downloads

Platform	Server (hub + client)	Client only
Windows x64 (portable, no install)	RE-KORD-Server-5.2.0-windows-x64.zip — extract and run RE-KORD Server.exe	RE-KORD-Client-5.2.0-windows-x64.exe
Linux x64	RE-KORD-Server-5.2.0-linux-x64.AppImage / .deb	RE-KORD-Client-5.2.0-linux-x64.AppImage / .deb
Linux headless (NAS, servers)	RE-KORD-Server-5.2.0-linux-x64-headless.tar.gz — run ./run.sh	—
Android (arm64, 8.0+)	—	RE-KORD-Client-5.2.0-android-arm64.apk
Docker (amd64, arm64)	ghcr.io/creiv/re-kord:5.2.0 (or latest)	—

The Server packages include yt-dlp, its JavaScript engine (QuickJS), cloudflared and ffmpeg.
Verify downloads with SHA256SUMS. Updating from 5.0 or 5.1: install the new version over the
old one; your data is kept. Full guide:
Installation.

Fixes from GitHub issue #99 and working YouTube downloads: a bundled JavaScript engine for
yt-dlp, tags and covers written into downloaded files, a clearer Studio download flow,
the "To fix" quality list, podcast and Android playback fixes. Hubs and clients 5.0, 5.1
and 5.2 work together; nothing in the database needs migrating.

New

• Studio downloads get tags and a cover. Downloaded files had no tags and no picture:
  the library knew artist, album and title only from the folders. The hub now writes title,
  main artist (not "Artist - Topic"), album and album artist (from the destination folder,
  not the playlist title "Album - …"), track number and total in release order, disc, release
  date and genre into every file the download saved, with the item's thumbnail as the cover,
  cropped to a centred square (16:9 video thumbnails) and kept at most 1200 px. Album
  downloads also save cover.jpg in an album folder that has none; an existing cover is never
  replaced. Video titles lose "(Official Video)", "[HD]" and a leading "Artist - ". Only the
  files of the run are written: files already in the folder are left alone (yt-dlp's own
  --embed-metadata would rewrite them too), and nothing but the audio and cover.jpg lands
  in the library. A WebM download has its Opus stream copied (no re-encode) into .opus so
  it can carry tags. Admin panel, Library › Embedded metadata: "Incorpora tag e copertina
  nei file scaricati" (on by default). The Studio log reports what was written.

• "In libreria" badges in Studio (issue #99): Esplora results, an artist's releases and
  Scopri tiles that match an album or track of the library (title and artist, ignoring
  accents, punctuation, "Deluxe", "Remastered", "- EP", "- Single", featuring) are marked,
  and the download confirmation offers Skip or Download anyway.

• Cookie status in Settings and in the admin panel's Integrations: file present and
  valid, last update, number of cookies and how many are for YouTube/Google.

• "To fix" list from the quality alerts (issue #99): the Quality alerts tile and the
  rows of Library quality on Home open a dialog with one tab per issue (albums without
  cover, albums without metadata, tracks without metadata, folders with loose tracks) and
  a button on each item: Cover and Metadata open Studio with that album already
  picked, Edit opens the track editor, Open album its page. Counts update as you
  fix things.

Changed

• Docker image on the GitHub Container Registry: ghcr.io/creiv/re-kord (amd64 and
  arm64, tags latest, the version and the release tag) is built and published at every
  release tag (thanks to @303inmyheart for the workflow). docker-compose.yml now pulls it,
  so the compose file alone is enough; building locally is still possible.
• Podcasts on Home no longer start by themselves (issue #99). Tapping a show in the
  Podcasts & news card opens its page; if you left one of its episodes halfway, it asks
  Continue "…"? with Continue (from where you left it) and Open the podcast. Live
  stations still play at once, and the play buttons of episode rows still play.
• "Show in Recent" removed (issue #99): podcast listens no longer appear in Recent,
  and the podcasts "⋯" menu, which only held that switch, is gone (Refresh is always a
  button).

Fixed

• Singles downloaded into an album folder were all "01 - …". A single now takes its own
  track number when the site gives one, otherwise the folder's next number after its last
  track (05 - Title next to 01–04); existing files are still never overwritten.

• YouTube downloads work out of the box again. YouTube now refuses yt-dlp unless it can
  run JavaScript ("The page needs to be reloaded", or "Sign in to confirm you're not a bot"
  even with cookies). The server packages and the Docker image now bundle QuickJS-ng
  (qjs, MIT, about 2.5 MB) as yt-dlp's JavaScript runtime, and the hub passes it to every
  yt-dlp run (downloads, track counts, previews, podcast pages). A deno, node (22+) or bun
  already installed is preferred (about twice as fast), also found where a desktop app's
  PATH does not look (~/.deno/bin, ~/.bun/bin, nvm's newest node,
  /usr/local/bin, /opt/homebrew/bin). The yt-dlp strip in Studio, Settings › System
  and the admin panel's Diagnostics show the runtime in use, or warn when there is none;
  the Studio sign-in hint says so too. REKORD_YTDLP_JS_RUNTIME still overrides the choice
  (none turns it off).

• Studio downloads, found while testing with real cookies. Explore search shows
  artists again (the top result and the Artists shelf were dropped, so Releases was out of
  reach from a search) and no longer lists podcast shows and episodes as albums and songs. A
  Scopri single sent to the Download tab before a folder was picked no longer has its link
  marked incompatible. With valid cookies and no JavaScript runtime, the failure now points
  at the runtime instead of asking to re-export the cookies, and Open Settings from the
  cookie hint lands on Library › Integrations, where the cookies are uploaded. A track
  count, preview or podcast lookup that is abandoned (dialog closed, timeout) now stops
  yt-dlp itself: the PyInstaller launcher was killed but yt-dlp went on as an orphan and
  could leave its copy of the cookies behind.

• YouTube cookies are wiped, not just deleted. Remove cookies (Settings and the admin
  panel), the per-run copies handed to yt-dlp, and the previous file replaced by an upload, a
  write-back or a backup restore are now overwritten with zeros and synced before they are
  unlinked, since they hold a live account session. Best effort: hard links and symlink
  targets are left alone, and a read-only location only gets the delete attempt.

• Plurals in counted strings (it/en/de): "1 album · 1 brani" under an artist, "Scaricare
  i brani…" when confirming a single track, "1 cookies", "1 rimossi" and similar now agree
  with the count, in the client and in the admin panel (.one / .other keys picked with
  Intl.PluralRules; the admin panel gets the same tp() helper as the client).

• Studio mode switches: the Classico / Esplora and Locale / Web labels are clickable
  (each picks its own mode) and keyboard accessible, not only the small switch between them.

• Admin › Integrations no longer shows the Discogs token as configured on a fresh hub:
  the hub reported Discogs as configured whether or not a token was set; now only a token
  from the environment or saved in the panel counts.

• Android: play from the car or Bluetooth with the phone locked (issue #99). A PLAY from
  the car, a headset or the lock screen now puts the media service in the foreground and
  takes the CPU and Wi-Fi locks at once, inside the window Android allows, and then hands
  the command to the player, which gets 15 s to answer (45 s while the app is starting)
  instead of 3 s. A service restarted by the car button no longer drops out of the
  foreground straight away, and the last track is kept so the car can resume it after the
  system stopped the service. If the app itself was closed, Android does not let it start
  from the background: the notification then offers Open RE-KORD to resume.

• Android Auto and car head units: the app is now a media browser service with a
  Resume item for the last track, and declares itself to Android Auto; the system's
  media controls can resume it too.

• Podcasts: "Update failed (Source unreachable)" after a refresh (issue #99). A feed
  answering "not modified" to the hub's conditional request (the usual answer when nothing
  new is out, as with Apple Podcasts shows) was taken for a failure, so the card showed the
  error while keeping the previous episodes. The hub now also retries a fetch hit by a
  network hiccup, a timeout or a brief server error (twice, within the time a list waits),
  finds the feed of an Apple Podcasts or Spreaker page from its address, and moves a source
  saved as a yt-dlp page (because Apple's lookup failed when it was added) to its feed as
  soon as that answers.

• Studio › Download: confirm at once, visible loading (issue #99). Downloading an album
  or playlist used to wait up to half a minute for yt-dlp to count its tracks, with no
  sign of life and a button that queued a new request at every click. The confirmation now
  opens immediately and the track count fills in when it arrives ("unknown" if it fails or
  takes too long); the button shows a spinner and refuses duplicates. Esplora searches,
  release lists and Scopri show spinners or placeholder rows, and errors appear next to
  the action (with a copy in the log) instead of at the bottom of the pane.

• Scopri › Download opens the same confirmation as the Download tab, on the folder
  picked there, instead of only filling in the link.

• Download progress between the form and the log (issue #99): the progress card no
  longer sits at the top of the pane; it follows the form, precedes the log and stays at
  the bottom of the screen while you scroll (mobile included).

• YouTube cookies (issue #99): yt-dlp rewrites the cookie file when it exits, so
  concurrent runs raced on it and a read-only file (Docker :ro, REKORD_YTDLP_COOKIES)
  failed. Each yt-dlp run now gets a private copy (mode 600, removed afterwards); only a
  successful download saves the refreshed cookies back into the uploaded file, never into
  one set by the environment. Podcast pages read through yt-dlp use the cookies too. An
  upload is validated before it replaces the current file (JSON exports and empty files
  get their own message) and is stored with mode 600. A download stopped by YouTube's
  sign-in or age check says so in the Download tab, with a hint and a link to Settings.

• Track editor: genre list (issue #99). The picker offered ten fixed genres instead of
  the library's, and genres were matched by spelling only: "R&B" and "Rhythm & Blues"
  became two chips (shown as "R&B · R&B"), "Hip-Hop" was offered for a track already
  tagged "Hip Hop" and then dropped silently on save, a pasted "Pop; Jazz" became one chip,
  and placeholders like "Unknown" or "8" were accepted. The editor now works like the album
  page: the library's genres (plus the starter list), one chip per genre whatever the
  spelling, a pasted list split on any separator, and a note when the genre is already
  there. Long lists no longer risk a duplicate-key error.

• Playing row equalizer (issue #99): the active track row animates again while music
  plays, like 5.0 legacy, and rests on the static equalizer glyph when paused. Only the
  first listing of the playing track moves (and the Smart Radio tile); on Linux it changes
  pose once per second together with the sidebar icon, so it costs no extra frames.

• Quality alerts count the same everywhere (issue #99): the hub and the client now share
  one definition of each issue, always restricted to the account's library selection. A
  track tagged only with a placeholder genre ("Unknown", "Music", "8") counts as without
  metadata; an album with a release date, label or country counts as having metadata.

Known issues

• Android: a play sent from a car or a Bluetooth device after the app has been paused in the
  background for more than about 10 minutes may not start; open RE-KORD from the
  notification or the media player to resume. Plays within 10 minutes of a pause work with
  the screen locked.
• YouTube can refuse yt-dlp from some networks ("Sign in to confirm you're not a bot") even
  with a JavaScript engine; uploading cookies exported from a signed-in private window
  usually solves it.