what's changed
a reliability patch, all of it from one contributor's bug report. the theme: a run that saved nothing was able to look like a run that worked.
fixed
- a failed run no longer reports success. the counter ticks once per finished track whether it passed or failed, so a playlist where every track failed read
Songs downloaded 66 of 66, the one-time star prompt fired off that number, and the honestDone! N track(s) failedstatus got overwritten a moment later by a genericScraping completed.. the counter now subtracts failures and names them, the star prompt only fires when something actually landed, and the final status is left alone. - flac, m4a, opus and wav could silently overwrite same-titled tracks. filenames were composed with a hardcoded
.mp3while the file landed with its real extension, so the exists-check and the resume manifest both looked for a path that never exists on those formats. that quietly disabled the same-title collision guard for everything except mp3: two different songs called "Home" resolved to one file and the second overwrote the first. it also made crash recovery re-download an entire folder. fixed and verified across every format with real downloads. - FFmpeg is checked before a run starts. missing FFmpeg used to surface as a download that just failed; the app now stops up front with the install command for the platform you are actually on, and looks where the windows package managers put their shims. the downloadable builds bundle FFmpeg and never touch any of this, so this is for running from source.
not changed, on purpose
the youtube matcher. it is byte-identical to 2.4.1 and its selection behaviour was diffed against the previous release before shipping, because a change there trades silently: the file downloads, the tags look right, and the audio is a different song.
all three of these were found and diagnosed by @urgorri in #100, whose commit is preserved in this release. the filename bug in particular had been shipping since 2.3.0 and it took reading the code properly to catch. thank you.
verifying this release: every asset is covered by SLSA build L3 provenance - gh attestation verify <asset> --repo sunnypatell/sunnify-spotify-downloader, or check checksums.txt with sha256sum -c.
install via homebrew (macos):
brew tap sunnypatell/sunnify https://github.com/sunnypatell/sunnify-spotify-downloader
brew install --cask sunnifyfull changelog: v2.4.1...v2.4.2
⭐ if sunnify saved you time, star the repo - stars are how people find it.
attestations from this build
direct links to each attestation generated by the workflow run that produced these binaries (sigstore-signed, public-good rekor log entry, SLSA build L3 via the release-build.yml reusable workflow):
- build provenance: Sunnify-Windows.exe
- build provenance: Sunnify-Windows-CLI.exe
- build provenance: Sunnify-Linux
- build provenance: Sunnify-macOS.zip
- build provenance: Sunnify-macOS-Intel.zip
- sbom attestation for the binaries
- build provenance for the source tarball
the *.sigstore.json assets attached above are the same attestations as offline-verifiable bundles. these get auto-refreshed on every release re-build, so the links above always correspond to the binaries currently attached to this release.