Library overhaul

[nick2000713]

Library Manager v2 — a real, Lidarr-equivalent library manager, built entirely on SoulSync's own pipeline

Update after the full lib2 cutover: this rework was honestly rougher than i expected, and @Nezreka was right to keep asking which database would actually be maintained in the future.

keeping the legacy library and lib2 alive as two equal databases made no sense. every metadata edit, enrichment result, import, repair job and media-server sync would need dual writes and permanent synchronization, and sooner or later both versions would disagree. i stopped trying to maintain both.

all active Library reads, writes, imports, enrichment and catalogue repair paths now use lib2 directly. lib2 is the main Library and the single runtime source of truth. the old tables remain only temporarily for the one-time upgrade import and as an upgrade/rollback safety boundary while this is tested on real large libraries. if that proves solid, the legacy schema can be physically removed in a later update.

this was a much larger and rougher rewrite than i originally planned, but the architecture is finally unambiguous: future Library development and maintenance happens on lib2, not on two databases at once. some older sections below describe the original opt-in/two-library phase and should be read as historical context.

Status: Draft / RFC. This is not ready to merge. I'm opening it early on purpose — to get eyes on the direction, get people testing it on their own libraries, and collect feedback before I lock in decisions that get expensive to change later. Please read the "What's still rough" section before you judge it — I tried to be brutally honest about what's missing.

---

Why I built this

SoulSync's library page has always just been a read-only mirror of whatever the media server (Plex/Jellyfin/Navidrome) reports back. No "monitor this artist," no missing-tracks visibility, no way to pick a specific release when auto-grab gets it wrong, no repair tools pointed at a single artist. It inherited every blind spot the media server has, and it couldn't do anything Lidarr does.

That always bugged me, because SoulSync already has everything a library manager needs under the hood: a real multi-source search, a download pipeline, quality enforcement, tagging, repair jobs. Lidarr has to shell out to external tools for all of that. We don't. So the actual gap wasn't "we need Lidarr's features" — it was "we need Lidarr's front end and decision layer wrapped around functionality we already have."

That's what this is. Not a reinvention of SoulSync's search/download/tag machinery — a proper Artist → Album → Track library model sitting on top of it, so you can finally manage your library the way you'd manage it in Lidarr, without needing Lidarr installed at all.

I want SoulSync's library management to be genuinely on par with Lidarr — not "good enough," actually equivalent. This PR is the first complete pass at that.

---

What it is, in one picture

Library v2 is not a second download/search/tagging system living next to the old one. It's a new front end and a new "what's monitored / what's wanted" model that talks to the same pipeline SoulSync already had:

flowchart TB
    subgraph UI["Library v2 UI (opt-in, new)"]
        A[Artist / Album / Track view]
        B[Interactive Search & Manage Tracks]
        C[Quality Profiles & Re-Tag Preview]
    end

    subgraph Bridge["Monitoring mirrors into the existing systems"]
        D[Artist monitor → Watchlist]
        E[Album/Track monitor → Wishlist]
    end

    subgraph Core["SoulSync's existing pipeline — unchanged, reused, not duplicated"]
        F[Multi-source Search]
        G[Download Orchestrator]
        H[Quality Gate + AcoustID]
        I[Tagging / Post-Processing]
    end

    UI --> Bridge --> Core
    Core -. same auto-download machinery keeps running .-> Bridge

Loading

If you never open the Library v2 page, nothing changes — it's dormant behind a feature flag. If you do open it, "Monitor this artist" doesn't invent a new download queue; it just adds the artist to the existing Watchlist, the same one the old page uses. Same for Wishlist. So the whole thing stays compatible with everything else running in the app instead of forking it.

---

Design rules I wouldn't break, even under pressure

These came out of a lot of back-and-forth with myself about where this could go wrong, and they held up through the whole build:

• Never media-server-dependent — not even for cover art. Artist/album images come from the file itself (embedded cover) first, then a metadata provider, cached to local disk. A pure SoulSync install with no Plex/Jellyfin/Navidrome attached works exactly the same as one with a media server.
• Monitoring mirrors the systems you already trust. "Monitor" on an Artist = added to the Watchlist. "Monitor" on an Album/Track = added to the Wishlist. The existing auto-scan/auto-download machinery just keeps working — Library v2 doesn't replace it, it feeds it.
• One quality-profile table, period. No shadow copy for the new UI. Every piece of the pipeline — search ranking, the AcoustID skip decision, the import quality gate, the upgrade scanner — resolves the same profile live, every time. Change a profile in Settings and it's immediately in effect everywhere, including for things Library v2 didn't queue itself.
• The database is the source of truth, not your folder layout. Every file's location is tracked per-row, so your library is reconstructable regardless of how you've organized folders.
• Reuse, don't reinvent. Search, download, tagging, repair jobs, quality logic — all the exact same code the rest of the app uses. This is a front end and a decision layer, not a parallel app.

---

Feature checklist — where it actually lands vs. Lidarr

Capability	Old Library page	Library v2	Lidarr
Read-only mirror of the media server	✅ (that's all it is)	❌ (own DB, own model)	❌
Works with zero media server attached	❌	✅	✅
Monitor artist / album / track individually	❌	✅	✅
Missing-tracks view with real titles, not just gaps	❌	✅	✅
Interactive search → pick a specific release	❌	✅ (source-aware, quality preview badges)	✅
Quality Profiles enforced at every pipeline stage	partial	✅	✅
Full discography browse + "monitor future releases"	❌	✅	✅
Re-tag preview (diff file tags vs. library metadata)	❌	✅	✅
Manage duplicate single/album versions	❌	✅	✅
Per-artist scoped repair/maintenance jobs	❌	✅ (where job-level support exists)	✅
Playlists visible in the library	separate page	basic view + trigger (see below)	✅ dedicated
Delete removes the actual files, safely	❌	🚧 DB-only for now	✅

---

What's actually done (this is the bulk of the PR)

I'm not going to paste the full internal changelog here — it's long — but the shape of it:

• Full Artist/Album/Track data model with multi-artist credit splitting, single-vs-album linking, and an importer that migrates your existing library into it without duplicating anything.
• Interactive Search & Grab with source-aware results (Soulseek slots/queue, Usenet grabs, age columns for Usenet/torrent), quality/AcoustID toggle overrides, and profile "preview badges" that tell you before you grab whether a result will meet your quality cutoff.
• Quality Profiles, for real — per-artist assignment, per-track evaluation against upgrade policy and cutoff, live-resolved everywhere instead of frozen at add-time.
• Discography browser — full provider catalog per artist, EPs section, bulk monitor/unmonitor, background re-sync job so new releases show up without you clicking anything.
• Manage Tracks — see single-vs-album duplicate pairs, unlink them, move the file to the "correct" version without touching disk.
• Re-Tag Preview — a real Lidarr-style diff table (file tags vs. library metadata) before you write anything.
• Maintenance panel wired to the existing repair jobs (metadata gap fill, unknown-artist fixer, tag consistency, rename/reorganize), scoped to the artist you're looking at where the job supports it.
• Basic Playlists integration — a read-only view of your existing mirrored playlists (source, owner, artwork, discovery/wanted/library counters) with a button that triggers the existing playlist mirror pipeline. Deliberately minimal — see below.
• All of the above verified against a real ~285-track library, plus a from-scratch Docker + Playwright pass that actually clicks through the UI in a browser rather than trusting curl/unit tests alone.

Test status at the point of writing this: ~8,200 backend tests green, ~100 frontend tests (Vitest) green, zero lint/typecheck warnings, production build clean.

---

How to try it

It's off by default. To turn it on:

features.library_v2 = true

Set it either in config/config.json (fresh installs, before the DB has a config row) or directly through the app's config store if you're on an existing install (the DB is the actual source of truth once it exists — editing the JSON file alone won't do anything on an established install). Restart the app afterward — the flag is only read at startup.

Turning it on does not touch your existing library, files, or downloads. The only side effect is that finished downloads start getting mirrored into the new Library v2 tables in the background (so the new view stays in sync even for downloads that went through the old Wishlist/Watchlist flow) — that's bookkeeping only, it never writes to disk and never changes what gets downloaded.

---

What's still rough — please read this before testing

I'd rather list these myself than have someone find them and assume I didn't notice:

• Deleting an artist/album only removes database rows — it does not delete files from disk yet. The safe-delete flow (preview what would be removed, journal it, actual recycle/unlink) is designed but not built. Don't expect "Delete" to free up disk space right now.
• Cover art has a cosmetic bug: the artwork cache always writes .jpg and serves image/jpeg regardless of what format the source image actually was. Usually harmless, occasionally shows a broken image for a non-JPEG provider result.
• Artist photos currently reuse an embedded album cover rather than always fetching a dedicated artist photo from a provider — so an artist's "photo" can end up being whatever album cover was picked, which isn't always what you'd expect. Worth a real decision before I "fix" it, since it's a deliberate fast/local choice right now, not an oversight.
• A few UI rough edges: some monitor/save actions can fail silently without a visible error; "Search Monitored" and "Search Upgrades" read as artist-scoped buttons but currently run against the whole library; the interactive search modal doesn't yet expose the same source-priority controls the rest of the app has.
• Playlists are intentionally shallow right now. You can see them and trigger the existing sync/mirror pipeline, but there's no per-playlist quality profile yet, and no resolution logic for what happens when a track is wanted through a playlist and an artist you've already set a different quality profile for. I want that (track-specific override beats artist-specific beats playlist-default, most specific wins) — but it's a genuinely complicated UX problem given we already have multiple playlist-related pages, so I'm deliberately not rushing it. It's documented and parked, not forgotten.
• Very large libraries may show their age in a couple of list/detail queries that aren't fully optimized yet (N+1 patterns in a few spots).
• Scan/Retag hold a database write-lock slightly longer than they need to while reading files off disk — mostly invisible unless you're on a slow network mount, but worth calling out.

None of these are secret landmines — they're all tracked, and none of them touch your files or your existing (non-Library-v2) workflows. But this is genuinely an early, opt-in feature, not a "flip it and forget it" one yet.

---

What I'm asking for

Try it on your actual library — especially if you're on a setup I can't easily replicate myself: very large libraries, path-mapped Docker volumes, multiple download sources (Usenet + torrent + Soulseek together), multiple user profiles, non-Plex media servers. Tell me what's confusing, what breaks, and what feels like it's missing compared to how you'd expect Lidarr to behave. I'd rather find the rough edges from real libraries now than after this becomes the default.

This has been a big chunk of work and I'm genuinely excited about it — but I also know "big chunk of work I'm excited about" is exactly the kind of PR that needs the most outside eyes before it merges, not the least. So: please poke at it. Break it. Tell me it's wrong. That's what this draft is for.

---

I screwed up — a force-push (git history cleanup) automatically closed the old PR #1025, and GitHub won't let it be reopened since then ("branch was force-pushed or recreated"). The branch/code is unchanged, only the PR container itself is gone. Here are the comments from last time so nothing gets lost:

@Nezreka (2026-07-14):

I'm excited to test this! Would this replace the entire library page or one of the views that exist in it. Standard view was nothing special but enhanced view was more library focused for manipulation

@nick2000713 (2026-07-14):

It’s still a long way from being finished, so there’s a lot missing and a lot left to implement.

The idea is that it will eventually replace both the standard library and Library Enhanced, although it’s mainly meant as a replacement for Library Enhanced for power users.

If you notice something missing, definitely let me know. There’s still plenty I want to add.

Personal note: I actually started working on this before SoulSync expanded into movies as well. Personally, I’d rather keep focusing on music for now. I feel like the movie/TV (and even YouTube) space is already covered really well by projects like Sonarr, Radarr and TubeSync, which are, in my opinion, still superior in those areas. Because of that, I haven’t really designed or optimized Library v2 with those use cases in mind.

@Nezreka (2026-07-14):

Sounds great! I'm just messing with it now, importing my library. Excited to see how it all works. Yeah you focus on anything you want to, the entire video side is very fresh with more work to be done. Music and video side are fully disconnected though so no worries you will impact anything. I've been daily driving it replacing radarr, sonarr, kometa and ytdl-sub. takes a day or so to enrich the library for the functions to work though.

@Nezreka (2026-07-14):

I'm noticing that the import is taking quite a bit without any live status. Been about 30 min without much happening but it says it is importing. I have a 320,000 track library though.

@nick2000713 (2026-07-14):

Oh Wow, definitely never tested it at 320k tracks 😅 Good news, it's not actually stuck.. the DB import itself is fast, but right after that it silently kicks off an enrichment pass that fetches tracklists + artwork per album from Spotify/Deezer, one by one. At your scale that's tens of thousands of sequential API calls, so itjust grinds for a while.

The actual bug is that none of that shows up in the UI — it just sits on "Importing…" forever with zero
indication anything's happening, even though the backend is tracking real progress under the hood. Logged it as P2-25, will get real progress reporting wired up. For now if you tail the backend logs you should see it steadily crunching through albums.

@nick2000713 (2026-07-14):

To be completely honest, the import still needs quite a bit of work. Several features from the old library haven’t been implemented yet, and not all information that was available in the old library is displayed in Library V2 yet.

If you’d like to try it, feel free to do so, but keep in mind that the import is still a work in progress.

For example, manual artist and track matching, metadata enrichment, and the detailed match overview from the old library are still on the roadmap. Some source information is not shown in Library V2 yet, but I plan to bring all of these features back.

I’m aware that the new library hasn’t reached feature parity with the old one yet, but that’s the goal. I’ll also be revisiting the import process to make it more complete and efficient.

@Nezreka (2026-07-14):

I’m aware that the new library hasn’t reached feature parity with the old one yet, but that’s the goal. I’ll also be revisiting the import process to make it more complete and efficient.

You're killing it, man. I appreciate your work. Take your time, let me know if you ever want me to pop in and check things. Moving SoulSync away from the reliance of media servers is necessary for other things planned down the line anyway.

@nick2000713 (2026-07-16):

Hey @Nezreka, I've worked on optimizing the import pipeline. It is now parallelized (for artwork, tracklists, and tag pre-caching) and runs significantly faster. Several bugs (like track-number healing and missing ReplayGain/Lyrics features after legacy import) have also been resolved. Feel free to try it out and let me know what you think..

@nick2000713 (2026-07-18):

Hey @Nezreka,

I've worked again on the import pipeline and resolved many many bugs.

Several bugs are still known... I still have problems when the artist hasn't the right metadata or has duplicate artists, but I think I have it now somewhat under control.

I also fixed the issue where newly split component artists were automatically set to monitored/watched instead of just the respective track. Now they correctly inherit the monitored status of the parent combined artist.

I would recommend to reset everything and start the import again since many many bugs are now resolved. It's better if you reset and start fresh, maybe now on a smaller library ;)

If you want, you can execute this command in the browser. This is how you can reset it, but be aware it also removes everything on your wishlist/watchlist:

(async () => {
  console.log('Hole Liste aller Künstler...');
  let page = 1;
  let allArtistIds = [];
  
  while (true) {
    const res = await fetch(`/api/library/v2/artists?page=${page}&limit=500`).then(r => r.json());
    if (!res.success || !res.artists || res.artists.length === 0) break;
    allArtistIds.push(...res.artists.map(a => a.id));
    page++;
  }
   
  console.log(`${allArtistIds.length} Künstler gefunden. Löschvorgang gestartet...`);
  
  for (let i = 0; i < allArtistIds.length; i++) {
    const id = allArtistIds[i];
    await fetch(`/api/library/v2/artists/${id}`, { method: 'DELETE' });
    console.log(`[${i + 1}/${allArtistIds.length}] Künstler mit ID ${id} gelöscht`);
  }
   
  console.log('Bibliothek vollständig geleert! Lade Seite neu...');
  location.reload();
})();

After the import and caching is done, I would recommend to manually start the "Reconcile unmapped artists" job. It resolves collaboration names into the real component artists and several other things.

Try it out and tell me what you think, thank you!

@nick2000713 (2026-07-18):

I am now working on the diverse tools that work with the old library, etc. together. For me, every feature I want and the old library had is implemented now. It's easier for me to build solely on the new library (Library v2), so I have to change/modify nearly every tool because it depends on the old library and database tables. For me to develop, it's easier to solely concentrate on Library v2 and migrate every tool over. Therefore, with the new code, the old library will be removed so it makes it easier going forward. If something is missing for you, tell me now...

And another thing is, I have found several bugs anyway and solved them in the download pipeline. Like when you approve a track in the quarantine, it would later be detected as an orphan file because the metadata after a given time weren't present so it wasn't written in the database. Such bugs and several others are also resolved because I stumbled upon them. @Nezreka

@Nezreka (2026-07-19):

Okay, I'm starting to understand this better now that I've got it running on a test library. My big question: what happens to the artist-detail pages?

Right now those are the only thing that lets me pull up an artist's full discography for artists I don't own yet — as far as I can tell Library v2 only works on artists already in my library, so I want to understand how that "find an artist I have nothing by and start monitoring them" flow survives once the old library is gone.

I'll be honest, this is getting a little big lol — scope mostly. But I'm willing to see it through and test as much as you need but also it's early and I haven't seen the full picture yet. I just want us on the same page about what's getting replaced (a page goes away) vs. rewritten (same page, new plumbing underneath) before it gets expensive to change.

@nick2000713 (2026-07-19):

Thanks for testing it so thoroughly. And don't worry, we absolutely don't have to rush this. I completely agree that before something this big gets merged, the architecture has to be right. I'd rather take more time now than end up with something we regret later.

The reason this became much larger than I originally expected is that I started Library V2 as an opt-in feature. Because of that, I introduced separate database tables instead of replacing the existing ones. That worked fine at first, since Library V2 was just a new view sitting on top of what already existed. But once I actually started testing it against a real library, I kept running into background jobs that quietly assumed a track could only ever live in the old tables. As one example: the lyrics-fetch job resolved a track's file path through the old library tables, and once tracks could also exist purely in Library V2's own tables, that same resolver silently returned wrong paths for V2-only tracks. I fixed that, and a few days later hit the exact same class of bug independently in the ReplayGain job, because it had its own separate copy of similar path-resolution logic. And it wasn't just those two — there are 33 separate repair/maintenance tools (quality scanning, tagging, cover art, orphan detection, and so on) that all made the same old-tables assumption in one place or another. At that point I basically had two choices:

• keep both libraries alive and write synchronization between the old and new tables for every one of those tools, or
• migrate the tools to Library V2 directly.

I chose the second option because synchronization is much more error-prone than having a single source of truth, and because fixing the same class of bug over and over, one tool at a time, wasn't sustainable. In hindsight, that's also why this PR grew much more than I originally anticipated.

I understand your concern about the artist pages, but I don't think anything you're actually worried about is being removed — this is a wording problem, not a scope problem. To be clear about what's actually going away: it's only the old Library page itself. Search, Discover, the artist-detail page, Watchlist, and Wishlist are separate pages and none of them are being touched by this migration.

Given that, I have to admit I'm not fully sure I still see the problem — you can already search for an artist you don't own today, open their page, browse their discography, and add them to the Watchlist or download straight from there, all without that artist ever being in the library. That flow doesn't sit on the page I'm removing, so it keeps working exactly as it does now. If there's a specific part of it you're worried about beyond the wording, let me know and I'll take a closer look.

The old Library page itself is essentially replaced by Library V2, so I don't see much value in keeping two versions of the same thing around. Everything else stays as is for now.

Also, while working on this I stumbled across a surprising number of unrelated bugs in the existing pipeline. Some of those fixes probably don't even belong in this PR and could be split into separate pull requests to make this one easier to review.

On top of that, the playlist view — we can strike that entirely from scope. I'm not attached to it and it's not something I need in this PR.

[nick2000713]

@Nezreka, i worked through all your points now and honestly this became alot rougher than i expected xD.. you were right to keep asking which database we actually want to maintain in the future. keeping legacy and lib2 alive as two equal libraries makes no sense.. every import, metadata edit, enrichment result and repair job would need to be synced forever, and sooner or later both databases would disagree again.

so i stopped treating lib2 as an optional second library. lib2 is now the main Library and the source of truth for normal runtime. the old tables are only kept for the first upgrade import and as a temporary safety/rollback boundary. i want to remove them in a later update, but only after this survived another real test on your 9gb database.

i also thought alot about why not just put everything back into legacy.. but the old model simply does not fit anymore. one legacy track has one artist_id and one file_path. it cannot properly represent multiple credited artists, multiple files/qualities for one recording, single↔album relationships or mappings from several media servers. to keep legacy i would basically have to rebuild its schema and rewrite every query and worker anyway, while still carrying all those old assumptions. lib2 already models these things properly, so one controlled migration to lib2 is much safer than permanent translation between two libraries.

about the problems you found:

• migration stuck at 5/7 · 71%: the server now starts first and the large migration continues in the background. it logs the real stage and counter every 30 seconds, including when the counter did not move, so it should finally be possible to see the difference between slow and stuck
• all the database is locked errors: enrichment workers and the automation engine are paused while the migration owns the writer, then only the workers that were running before are resumed. the large passes commit in batches instead of one huge transaction
• the WAL growing and getting slower: the migration checkpoints the WAL between batches, so it should not just grow from 85mb to 135mb while throughput keeps dropping
• restart making it worse: progress is stored with a real resume checkpoint. after a restart it should continue the matching stage instead of blocking database init or starting the complete catalogue walk again
• no enrichment in lib2: your reading of resync_entity_from_legacy was right at the time.. it existed but was not reliably wired into all worker paths. i moved the provider enrichment to lib2 instead of depending on that bridge forever. artwork, genres, bios, provider ids and provider payloads now end up on the lib2 entity
• native-only artists getting less enrichment: migrated artists and artists created from featured credits, wishlist/watchlist or discography now use the same native lib2 enrichment path. not having a legacy row should no longer create a second class of "matched" artist with less data
• /api/library/artists reading legacy: the active Library API/UI now read and write lib2. the old compatibility response is projected from lib2 too, so metadata edits and enrichment should not disappear depending on which endpoint reads them
• which tables are the final ones: lib2_track_artists and lib2_track_files stay for exactly the reason you mentioned. and lib2_artists, lib2_albums and lib2_tracks are now the maintained catalogue, not temporary copies beside another active library
• mbid_mismatch_detector: it is now an active lib2 job, not a retired job whose findings get deleted at worker startup

i added a ratchet test for this too.. normal production Library code is not allowed to add new reads or writes to the legacy artist/album/track tables. the one-time upgrade reader is counted separately, so we cannot quietly start depending on legacy again later.

the media-server behaviour is also clearer now:

• imports always create/update the local lib2 row and do not wait for Plex/Jellyfin/Navidrome to be online
• a media server does not create the Library anymore. after a successful scan it only adds its own recognition mapping to the existing entity
• the Library shows a small server/check badge when a server recognised the artist/album/track
• a failed or interrupted refresh keeps the last good mappings. they are only replaced after the server was read successfully
• SoulSync DB metadata is not silently pushed into Plex/Jellyfin. the server benefits when SoulSync writes the actual file tags and the server scans the file again

i merged the newest dev too and checked the conflicts one by one so we keep the fixes from there. manual artwork now has a real lock in lib2 and survives provider/server refreshes, the new thumbnail cache is connected to the active lib2 page, genre enrichment scans lib2, reorganize keeps repair findings on the new path and i fixed a crash in the automatic native enrichment sweep that only showed up when starting the real app.

the final merge is f7496e8f0 and includes dev through bbf21fd18. no rebase, no force push and no replaced history. the PR is clean/mergeable now and none of our guide/issue/status markdown files are part of its diff.

if you have the time i would realy like you to test these painful cases again:

1. upgrade the same pre-lib2 database and check that the server/UI comes up while migration is still running
2. watch the new counters and WAL through the huge track stage
3. restart once during migration and check that it resumes without duplicate or missing rows
4. compare enrichment on one migrated artist and one native-only wishlist/featured artist
5. edit metadata and artwork, then run enrichment/refresh and confirm the values still stay
6. import while the media server is offline, then scan it later and check that the badge appears without a duplicate Library row
7. interrupt a media-server refresh and confirm the previous mappings/badges remain
8. have a look at reorganize findings, genre enrichment and mbid_mismatch_detector

i ran everything before pushing:

• backend: 15307 passed, 3 skipped, 2 deselected
• webui: 325 files / 6724 tests passed
• browser e2e: 30 passed, 8 skipped
• production build, ruff, format and type/lint checks passed
• lib2 legacy/native ratchet: 17 passed

the tests are clean now, but your database is still the test that matters most because it is on a completely different scale than mine.. so pls tell me anything that looks stuck, missing, duplicated or just behaves differently. even one weird provider or badge is useful and i will dig into it..

thx again for pushing on this.. the rewrite was rough, but your question about which database we actually maintain was the right one and the architecture is alot clearer now..

[nick2000713]

@Nezreka Quick update since the last message:

• Ported Reassign to a different artist to Library V2 and tested it live in the browser.
• Kept the branch in sync with dev — just merged your latest 7 commits (concurrent-downloads fix, post-processing queue
  fix, preferred-version matching, Navidrome path resolution, per-item quality-profile filter, radio-edit detection). All
  conflicts resolved, full test suite green after the merge.
• Kept fixing real bugs found by actually using the app against my own library: permanent file deletion, AcoustID scan
  status not updating live, a few missing-count/history display issues.

No urgency on a reply, just wanted to keep you posted that I'm tracking what you implement upstream, and making sure it lands in Library V2 too...

[nick2000713]

@Nezreka synced with dev again (up to 250f7f9), conflicts all resolved on my side.

also ported the new work over to library v2 here, metasync export and the expired cleaner queries and soul_id_path. i'll keep doing that with every sync, it just means the PR keeps growing a bit each round.

i'll keep doing it, but the PR gets bigger the longer this goes on.. splitting it isn't really an option anymore either, the cutover is one piece since i ported every worker...da