Wondarr 0.1.9

Reference libraries forgive a few bad MP3 frames, and the usenet indexer pause from 0.1.8 now covers grabs and pushed releases too. Update by pulling :0.1 (or :0.1.9).

Upgrading from 0.1.8:

• No database migration, no new settings.
• Reference files that were "unreadable" get another look on the next scan. A file that plays through but has a few bad frames (at most about 20 lines of decode errors, with at least 98 % of it decoding) is now identified and, in adopt mode, adopted like any other. Downloads are checked as strictly as before.
• A grab from an indexer that is pausing NZB downloads ends that song's search run. Nothing is blocklisted; the song is searched again later.

Changed

• Dependencies updated: Quartz.Extensions.Hosting 4.5.1 (4.4 code runs unchanged; no schema change).
• The repository no longer carries internal planning and research notes; public docs no longer cite them.

Fixed

• Soulseek no longer searches for a pseudo-album as if it were an album. The "artist + album" query was skipped only for an album literally titled "Singles", so a Singles album you had renamed, or the library-wide compilation album, still cost a wasted search (it never picked a wrong file). The query is now left out whenever the song's album is a pseudo-album by kind, whatever its title; a real album that happens to be titled "Singles" is searched. A search request that carries no kind (one stored by an older version) keeps the old title check. YouTube builds no album query, so it is unchanged. No migration.
• A grab no longer asks an indexer that is cooling down for an NZB, and a refusal during a grab starts the cool-down. Only searches knew the cool-down. A grab of a post whose NZB was not kept in memory still downloaded it, and when the indexer answered 429 or 403 (or its limit message) the grab failed without cooling the indexer down, so the next search spent more downloads. Now such a grab fails at once, without a request, with "indexer is cooling down until time after refusing NZB downloads", and the post is not blocklisted: the post is fine, the indexer is resting. The grab run for that song ends there, as it does for any failure that is the source's own bad moment, instead of failing the indexer's remaining posts one by one; the song's own backoff tries again. A refusal during a grab starts the cool-down exactly as a search's does. A post whose NZB is kept is grabbed as before. A pushed release names no indexer row, so it has no cool-down. No migration.
• A grab and a search that need the same NZB at once download it once. The searches already shared one download per post; a grab now joins it (or is joined by a search, or by another grab) instead of making a second request against the indexer's daily quota. No migration.
• A pushed usenet release is no longer retried on a 429. The link of a pushed NZB is an NZB download like an indexer's, so a spent quota is answered once instead of being retried. Pushed torrents are retried as before. No migration.
• A failed NZB download is retried once, after at most 5 seconds. This covers a 5xx, a 408, a dropped connection and a timeout. A 502 or 503 with a long Retry-After used to be waited out inside the retry handler, held the search or the grab until the 30-second request timeout and ended as "The indexer could not be reached.", with no status; now the download is asked a second time after the shorter of the header and 5 seconds, and a second 5xx is reported as the indexer's own answer ("The indexer answered 503."). Before, a download could be asked three times. Searches and capability requests are retried as before. No migration.
• A reference file with a few bad MP3 frames is scanned instead of being left unreadable. The decode check treated any ffmpeg error as "does not decode", which is right for a download (a damaged one is replaced) but not for your own files: the live check left Eddie Grant - Electric Avenue.mp3 (6 bad frames) and Supertramp - Give A Little Bit.mp3 (1 bad frame) unreadable, although both play to the end. A reference scan now puts up with a file that fails the strict decode when ffmpeg, told to skip past bad frames, writes at most 20 error lines (a bad frame is two or three) and gets through at least 98 % of the length ffprobe measured; it then goes on to identification like any other file, the scan logs "decodes with N errors … scanned anyway", and the file's row says "Decodes with N errors" until identification replaces it. A file with more damage than that, a damaged file that also ends early, and a file with no audio stream stay unreadable. Downloads, imports, conversions and upgrades are as strict as before. Adopt mode copies such a file as it lies. An unreadable file that now passes is picked up by the next scan without being touched. So that such a file can be fingerprinted too, the fingerprint step now has a second try: fpcalc reads a file straight through and gives up at the first bad frame, so when it cannot fingerprint the start of a file, Wondarr cuts the same window out with ffmpeg (which skips bad frames) and fingerprints that. A file fpcalc could read is fingerprinted exactly as before. No migration.

Image: docker pull ghcr.io/wulfftech/wondarr:0.1.9 (linux/amd64, linux/arm64)