v2.6.0

Summary

• Two additions: you can now follow a playlist creator to see everything else they've made, and lyrics no longer have to arrive as two files.

Added

• Click a playlist's creator to browse their other playlists (#135, requested by @alex5908). On a Deezer playlist, the creator's name under the title is now a link that opens everything else they've shared, so finding one playlist you like leads to the rest of that person's taste. Creators who keep their profile private show as plain text instead of a link, since there's nothing behind it to open. Qobuz playlists list an owner without a profile to link to, so those are unchanged.
• Retag can now backfill the copyright tag (#139). Anything downloaded before 2.5.10 has no copyright tag, and Retag couldn't repair it because it reads a different source than downloads do. Point Retag at those folders with Copyright ticked and it fills them in, no re-downloading needed. Requires a Deezer login; without one the field is skipped and everything else still retags.
• A setting to skip the plain .txt when synced lyrics are available (#141, requested by @shark0151). The app used to save both the .lrc and the .txt for the same track, which meant two files saying the same thing. Turn this on and only the .lrc is kept, with the .txt still written for tracks that have no synced version. Off by default, so nothing about your existing library changes unless you ask.

v2.5.10

Fixed

• Copyright was missing from every Deezer download (#139, reported by @lukisbaby). Deezer publishes copyright, but not on the endpoint the app was asking. The call it used for track details doesn't include the field at all, so the tag had nothing to write and silently stayed empty. It now reads the endpoint that does carry it, and only when the copyright tag is switched on, so nobody pays an extra request for a tag they don't use. Applies to both MP3 and FLAC.

v2.5.9

Summary

• MP3 downloads were being saved with no tags at all. A single malformed lyric timestamp aborted the whole tag write, so the file arrived with no title, artist, album, artwork or anything else. FLAC was never affected.

Fixed

• MP3 files downloaded with synced lyrics enabled had no tags whatsoever (#139, reported by @lukisbaby). The tag library requires a synced-lyric timestamp to be a whole number and refuses anything else. Deezer returns them as text, so the write was rejected outright, and the fallback path was rejected for the same reason, leaving the file with no tag block at all. It looked like individual fields were missing because every field was. Timestamps are now converted before use, and any line that still cannot be read is dropped rather than taking the whole file down with it. Synced lyrics are enabled by default, so this affected most MP3 downloads.

v2.5.8

Summary

• Playlist folders were saving one track's album cover instead of the playlist's own artwork, and a security pass hardened how the app writes files and logs. Downloading itself is unchanged. Covers now land correctly, and several ways a file could be left half-written are closed.

Fixed

• A playlist folder showed a random track's album cover instead of the playlist artwork. The playlist's own cover has to be fetched over the network before it can be saved, while a finished track already holds its album art in memory. With several tracks downloading at once, a track's cover reached cover.jpg first and the playlist's image then found the file already there and gave up. The playlist now claims that filename before it starts fetching. Album downloads are unaffected.
• Qobuz playlists were labelled as albums in the downloads list. The badge was fixed to "album" regardless of what had actually been queued. Deezer playlists were always labelled correctly.
• Album art and tags could be left truncated when several tracks finished at the same moment. Covers, playlist covers, artist images and tag writes now go to a temporary file and are swapped into place in one step, so a partly written file can never be read or left behind.
• A track title containing a line break could forge extra rows in errors.txt. Those fields are flattened to a single line before the file is written.

Changed

• Remote text has line breaks stripped before it reaches the app's logs, across the download, authentication and server paths, so a crafted track or playlist name cannot fake log entries.
• The build workflow pins its Bun setup action to an exact commit instead of a moving tag, so an upstream change cannot alter what runs in CI.
• Deezer share links are matched on the actual hostname rather than by searching for that text anywhere in the address, so a lookalike address is no longer accepted.

2.5.7

Summary

• Spotify changed the shape of its playlist replies, and downloads stopped working for anyone who registered a developer app recently. The app now reads both the old and the new format, and explains the one case Spotify will not let it read at all.

Fixed

• Spotify links failed with "Cannot read properties of undefined" (discussion #105, reported by @alex5908). In February 2026 Spotify renamed the fields carrying a playlist's songs. Apps registered before that change are still sent the old names and kept working, which is why this only affected people who created their Spotify credentials recently. The app now accepts either format, so both groups work.
• A playlist whose songs Spotify withholds now explains itself instead of failing strangely. The same change means a developer app only receives the contents of playlists owned by the account that authorised it; everything else arrives with the name and artwork but no songs. That is a successful reply as far as Spotify is concerned, so it used to slip past the error handling entirely. It is now recognised and explained.
• Explanations reached people syncing a playlist but not people downloading one. The messages written for 2.5.5 were only wired into the sync path, so the same underlying problem produced a clear answer in one place and a raw error in another. Both paths now use them.

Changed

• Long playlists page through Spotify's own paging links rather than a fixed address, so a future rename of the endpoint cannot break them either.

v2.5.6

Fixed

Playlist .m3u8 files were being written into the first track's album folder instead of the download root (#138)

If you download a playlist with Create playlist folder turned off, the generated .m3u8 should land in your download root. Instead it was ending up inside the album folder of whichever track happened to finish first, which made it easy to conclude no playlist file had been created at all.

All four M3U recording paths shared a single expression that fell back to the album folder whenever no playlist folder existed. That fallback is correct for album .m3u8 files (added in #121) and both kinds share one tracker, so it could not simply be removed. The tracker now knows which kind it is:

• Album M3U — still written into the album folder, unchanged
• Playlist M3U — only a real playlist folder sets the location; otherwise the download root

Affected every entry point, including the link analyzer and favourites.

Thanks to @SchwanzusLongus for the report, and particularly for tracking down where the files had actually gone — that detail identified the cause immediately.

2.5.5

Summary

• When a playlist fails to sync, the app now tells you why. Two different Spotify problems used to look identical, and neither of them explained itself. Both now say what happened and what to do about it.

Fixed

• A failed sync showed a red ERROR label and nothing else (#137). The reason was being recorded the whole time, it simply was never displayed, so there was no way to tell a Spotify restriction apart from a problem with your own settings. The explanation now appears on the playlist itself.
• Syncing one of Spotify's own playlists now explains itself. Spotify no longer lets other apps read the playlists it makes: the editorial ones such as "All Out 60s" and "Today's Top Hits", and the automatic ones such as "Discover Weekly". Spotify reports these as though the playlist does not exist, which previously surfaced as an unexplained failure. The app now recognises them and tells you to copy the tracks into a playlist of your own and sync that instead, which works. Playlists made by people were never affected.
• The Test Connection button no longer reports success when Spotify will refuse every request. Since 9 March 2026 Spotify requires the account that created your developer app to hold Spotify Premium. Spotify still hands out an access token in that situation and only refuses the actual requests, so the button was reporting a good connection to people whose every sync was going to fail. It now performs a real read before saying it worked, and explains the subscription requirement if that is what is blocking you. This affects only the owner of the developer app, not the people whose playlists you read.

Changed

• The Spotify setup instructions now state both of Spotify's restrictions up front, in the README and in the troubleshooting guide, so they are visible before you spend time on a setup that cannot work.

2.5.4

Summary

• Small text throughout the app is easier to read, in every theme. This is the same problem as the track count in 2.5.2, found everywhere else it occurs. Nothing moves and no colours change character; the greyer text simply stops being quite so faint.

Fixed

• The muted grey used for secondary text was too light on cards and panels. Labels, hints, settings descriptions and similar small text are drawn in a lighter grey so they sit behind the main text. That grey was measured against every one of the app's twenty theme and mode combinations, on all three background shades each of them uses, and it fell below the recognised minimum for readable text in four of them, on the darker card and tile backgrounds in particular. It was slightly too light before anything else was done to it, so the grey itself has been adjusted: a little darker in light mode and in the light Signal theme, a little lighter in Dracula. Every combination now clears the minimum. The other seventeen were already fine and are untouched.
• Thirty-three places were fading that text further still. On top of the grey, individual labels were being drawn at partial opacity, some as low as 30%, which took them well below readable. That extra fading has been removed. These elements are still clearly secondary, because they were already set apart by size, spacing, capitals and typeface rather than by the fading. Twelve other faded elements were left exactly as they are on purpose: the drawings on empty pages, and options that are switched off, where the fading is what tells you the option is unavailable.

2.5.3

Fixed

• Track counts now appear on New Releases, Charts and Genres. These pages never showed the TRK line, while search results and Qobuz pages did. The reason is that the Deezer feeds behind them do not include a track total: the New Releases feed returns thirteen fields per album and a track count is not one of them, and the public chart and editorial feeds leave it out as well. The app was correctly hiding a number it had never been given. It now looks the count up separately for those albums and remembers it, so the first visit to one of those pages takes a couple of seconds longer while the numbers come in and every visit after that is immediate. Nothing was removed in 2.5.2; that release made the existing counts easier to read, which is what made the pages that never had them stand out. Reported by DRAZY.

2.5.2

Fixed

• The track count on album and playlist cards is readable now. The small 109 TRK line under the artist name was being dimmed twice, a muted grey then dropped to 60% opacity, at a 9.5px size. Measured against every one of the ten themes in both dark and light mode, all twenty combinations fell below the WCAG AA minimum for text this size, the worst of them at less than half the required contrast. The extra dimming is gone and the line now sits at the same grey as the artist name above it. It stays clearly distinct because it is already set in the monospace face, smaller, uppercase and widely letter-spaced, so the hierarchy never depended on the fading. This also brings it in line with the identical TRK readout in the download panel, which was full strength all along. Reported by alex5908, with a useful observation from cisko99za that the line only appears when the service actually returns a track count, which is why some cards show it and others do not.