Wondarr 0.1.17

Wondarr no longer fills a song AcoustID does not know with another artist's song of the same title, and Remove file… on the song page takes a wrong file away. Also in this release: the fixes from a code review of the whole project. Update by pulling :0.1 (or :0.1.17), from ghcr.io/wulfftech/wondarr or wulfftech/wondarr on Docker Hub.

Upgrading from 0.1.16:

• No database migration.
• With auth: none, open Wondarr by a local name, or allow yours. Wondarr now answers the web UI under auth: none only for an IP address, localhost, a name without a dot, or one ending in .local, .lan, .home.arpa or .internal. If you open it by another name, add that name to server.allowed_hosts, or turn off Only answer local host names under Settings → General → Security. With auth: forms nothing changes.
• Files already in your library are not checked again. A song AcoustID did not know may hold someone else's song of the same title: its File tab shows no verified fingerprint. Use Remove file… on its page to take the file away, and Wondarr looks for the song again.

Added

• Remove file… on the song page takes a wrong file away from its song. The file and its lyrics file go to the recycle bin, the song is missing again so the next search looks for it, and the download it came from is blocklisted for the song unless you untick that. The dialog can start a search straight away. A reference library's file, or a copy adopted from one, is never removed. The API is DELETE /api/v1/song/{id}/file?blocklist=true.

Changed

• With auth: none, Wondarr answers the web UI only when it is opened by a local name. Otherwise a page on the internet could point its own domain at your Wondarr (DNS rebinding), read the API key from /initialize.json and use the whole API. A local name is an IP address, localhost, a name with no dot, one ending in .local, .lan, .home.arpa or .internal, or a name in server.allowed_hosts; any other name gets a short page saying which name was used and what to do. If you run with auth: none and open Wondarr by a name that is not local (such as wondarr.ad.example.com), add that name to server.allowed_hosts or turn off Only answer local host names under Settings → General → Security (server.require_local_host: false; the switch shows only with auth: none). Tools that send the API key (Prowlarr, autobrr and the like) work under any name, and forms and external are unchanged.

Fixed

• A song AcoustID does not know is no longer filled with another artist's song of the same title. Such a file passed on its length alone, and same-titled songs are everywhere: on one install, 11 of 16 files imported that way were someone else's (Artur's "Wonderland" for The Saddle Club's, a Deep House "Money (Can't Buy)" for "Money Can't Buy"). The file now has to name the song's artist in its artist or album-artist tag, or failing those in its file name. One that names another artist is refused and the next candidate is tried; one that names no artist at all is imported marked for review, or refused with acoustid.strict on. The same applies when no AcoustID key is set. Files already in your library are not re-checked.
• One word of an artist's name no longer counts as the artist. "Penny To The Grave" by The Miles Away Club passed for The Saddle Club's "When the Penny Drops" on the word "club". A candidate now needs the whole name, or a shorter form of it that adds no other words, such as "Beethoven" for Ludwig van Beethoven.
• A file on a compilation path that names another artist is no longer downloaded. On a "Various Artists", "VA", "OST" or soundtrack path, a file whose title matched the song's in full skipped the artist check, even when its own name named someone else (18 The Cryan Shames - Sugar and Spice.flac). Each one was downloaded and then refused by its fingerprint.
• The same wrong file from another Soulseek user is skipped. When AcoustID identifies a download as a different recording, its folder and file name are blocklisted for the song too, so the same rip shared by someone else is not downloaded again. The entry shows on Activity → Blocklist and can be removed there.
• A search whose every download was refused now counts as fruitless. Any grab reset the re-search wait, so a song whose downloads were all refused, or failed to import, was searched again at the shortest interval and downloaded more wrong files. Such a run now lengthens the wait like a search that found nothing.
• A file that fails tagging is skipped for a week, and the log says so. It ended the run as before, but the next search grabbed the same file again, three times in two days on one install, and nothing above Debug level said why. The failure is now a Warning, and that one file is blocklisted for the song for 7 days.
• An MP3 import no longer prints a stack trace to the log. Stripping the old tags asked the tag library to remove a tag system MP3 does not have; it carried on, but printed "The method or operation is not implemented" with its stack trace on every MP3.
• An email the mail server turns away for now is sent again. A temporary refusal (an SMTP 4xx reply, such as greylisting or a rate limit) is retried once after 20 seconds. Two immediate notifications were lost to a 450 that way.
• Settings → YouTube saves a 44.1 or 48 kHz sample rate. Choosing either answered 400 and nothing was saved, and a rate already stored showed as "Keep", so saving any other field on the page reset it. The page now sends and reads the rate as a number.
• Interactive search runs once per open. It re-ran the Soulseek search whenever the queue changed or the connection reconnected, which swapped the results out from under you and spent the shared search budget, and a grab waited for that re-run before it finished. Opening the search runs it once.
• A song's page shows a blocklisted item and a grab at once. Removing an item with "blocklist" on the song page's Queue & blocklist tab left the Blocklist table below it saying "Nothing is blocked", and a grab from the song's interactive search left no "grabbed" row in its History tab, until you left the tab and came back. Both lists now refresh straight away.
• Changing a reference library's folder keeps its songs. After remounting a share at a new path, every song the library owned still pointed at the old one: a file you then deleted never freed its song, and Adopt skipped everything. The owned songs' paths now move with the folder, and a file that is not at the new path goes through the usual wait for a missing file.
• A song with a second copy of its recording keeps a file. Skipping a reference file, accepting a different song for it, or a rescan finding that it belongs to another song could leave a song that had a second copy of the recording with no file at all. The song's file now follows the second copy.
• A reference file overwritten with a broken copy no longer keeps its song for good. When the file is still unreadable on a later scan and was last written more than 24 hours ago, the song lets go of it. That is the wait a missing file gets, so a copy still in progress, or one failed check, does not count. The song follows a second copy of the recording if there is one, and is wanted again if not.
• A pasted or synced list no longer stops at a bad line. A Deezer track with an ISRC in an odd shape (hyphens, or too short), or a line that was the all-zero MusicBrainz id, left the list due and failing at the same line every run. A hyphenated ISRC is cleaned up before the lookup and an invalid one skips the ISRC lookup. The all-zero id is reported as not supported. Any line a lookup refuses is marked failed and the rest of the list carries on.
• An upgrade or a renamed download that was in flight when Wondarr stopped is picked up on restart. An automatic upgrade that replaced a song's file at the same path, with Wondarr stopped before it saved, was never recorded: a second download was grabbed and filed over it, and the song never showed the upgrade. A YouTube download renamed to .ogg (Opus container set to ogg) and stopped mid-check made the restart look for the old .opus name, fail the import and download the song again, leaving the .ogg behind. Restart recovery now recognises the upgraded file and records it, and the rename is saved straight away so the import resumes from the renamed file.
• An import whose finished download cannot be removed keeps the library copy. When the downloads folder was on a different file system and Wondarr could not delete the finished download after copying it into the library (the file was busy, or Wondarr could not write to the download folder), the import failed and left an untracked copy in the library that Plex scanned. Wondarr now records the copied file as the song's, keeps it in place and leaves the replaced file in the recycle bin. A half-written copy left that way is deleted and the download kept.
• A replaced file stays in the recycle bin for import.recycle_bin_cleanup_days. When Wondarr could not set the time on a replaced file it moved there (the library files belong to another user), the next daily Housekeeping deleted that file within a day. The recycle bin now replaces such a file with its own copy, so the retention starts when it was recycled. If that copy fails too, the log says the file may be removed at the next cleanup.
• One stuck sign-in no longer blocks everyone else. Two slow or half-sent POST /login requests took both password-check slots and made every other sign-in, the owner's included, fail with "Wondarr is busy checking other sign-ins". Only the password check itself is now limited to two at a time, and a login form over 8 KB is refused (413).
• A page number far past the end returns an empty page. For example ?page=2147483647 made the API behind the Logs page (/api/v1/log) answer 500, and the other lists returned page 1's rows. The page number in the response is capped at 2147483.
• The slskd webhook refuses any request that carries a proxy header. That is X-Real-IP, Forwarded, Via and the rest, not only X-Forwarded-For. A reverse proxy on the Wondarr host could otherwise let internet traffic past the loopback check.
• The Docker health check follows a changed port. With server.port in config.yml or APP__SERVER__PORT set to anything but 1077, the container showed unhealthy for ever though Wondarr was running, so depends_on: service_healthy and health badges treated it as down. The check now uses the port you set (the environment variable first, then config.yml) and, with a specific bind_address, probes that address.
• A Usenet post with a huge file subject no longer fails the whole song search. A subject thousands of characters long (a broken or hostile indexer) made the file-name regex time out; the timeout was not caught, so the search lost the candidates other sources had found, a grab of that post failed on every retry (spending the indexer's daily NZB quota each time), and a pushed release answered 500. Subjects over 512 characters are now read as having no file name, and a timeout while reading an NZB counts that release as unreadable. The search keeps its other results.
• A Usenet download that SABnzbd saved under another name is imported. A Windows SABnzbd replaces characters the file system forbids, such as ? or :, so Wondarr found nothing in the finished folder, deleted the job and its folder, and did not blocklist the post, so the next search downloaded it again. Wondarr now looks for the song in the finished folder with the matcher before giving up, and imports it when found. When the folder holds audio but not the song, the item fails and the post is blocklisted.
• A Soulseek file name with a long or foreign-script number no longer drops the search. A 10-or-more-digit number between dashes (a catalogue number or timestamp, as in Artist - 9999999999 - Title.mp3), or a year or track number written in another script's digits (Arabic-Indic, for example), made the file-name parser throw. That dropped every candidate of the search query it came back for, and could fail a torrent grab or a reference-library scan. Such a number is now read as plain text, not a track number.
• An automatic search no longer stops at Soulseek when every file is from a peer on cooldown. When every acceptable-looking file came from a peer with two failures in 24 hours, YouTube and the indexers were never asked, and the song ended "no acceptable candidate" with a longer wait. The peer's standing is now taken into account before deciding whether to ask the next source.

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