Qobuz integration: pick engine library (qobuz-cli vs streamrip vs defer)

[Salem874]

Context

Issue #266 evaluated SpotiFLAC for Tidal / Qobuz / Amazon Music and rejected it on three grounds: architecture mismatch (Wails GUI, not subprocess-friendly), third-party proxy authentication (shared credentials, not user credentials), and reliability of those proxies. The closing comment explicitly left the door open for credential-based CLI tools that fit MeedyaDL's existing GAMDL/votify subprocess pattern.

vitiko98/qobuz-dl was suggested as one such candidate. After research, the picture is more nuanced — the library qualifies on architecture but is functionally unusable as-is. Two viable alternatives surfaced. This issue captures the choice for an owner decision.

Candidate evaluation

vitiko98/qobuz-dl (the original suggestion)

Dimension	Verdict
Architecture	Python CLI, pip-installable, subprocess-invokable — matches MeedyaDL pattern
Authentication	User-supplied email + password — user-credentials-first (passes #266 criteria)
PyPI	v0.9.9.10, last release 2023-03-26
Upstream maintenance	Functionally abandoned — last code commit 2023-08-21, 163 open issues, 10+ open PRs spanning 2023→2026 unmerged
Current status	BROKEN on all accounts — Qobuz disabled email/password login server-side in April 2026 (#329, #333). Stock pip install qobuz-dl does not work today. Community token-auth PRs (#282, #306, #334) exist but unmerged.
License	GPL-3.0

Verdict: do not integrate as-is. Shipping it would deliver a non-functional engine.

HongYue1/qobuz-cli (modern alternative)

Dimension	Verdict
Architecture	Python CLI, pip-installable, asyncio-based
Authentication	Supports both token-based AND email/password auth out of the box (latter would still need the April-2026 server-side fix from upstream)
PyPI	qobuz-cli v0.0.2, released 2026-06-06 — eight days of public history at audit time
Upstream maintenance	Active (new project)
Current status	Works on accounts with token auth
License	GPL-3.0-or-later

Pros: clean per-service mapping; current; modern. Cons: v0.0.2 with eight days of history — token-stability across releases unknown.

nathom/streamrip (multi-service alternative)

Dimension	Verdict
Architecture	Python CLI, pip-installable, async
Authentication	User credentials per service (Qobuz / Tidal / SoundCloud / Deezer)
Upstream maintenance	Active (4.7k stars, last push 2026-04-21)
Current status	Also affected by April-2026 Qobuz auth break (#954); actively triaging
License	GPL-3.0
Coverage	Qobuz + Tidal + SoundCloud + Deezer in one engine

Pros: battle-tested; would simultaneously deliver multiple future MeedyaDL milestones (Qobuz + Tidal + SoundCloud) in a single engine integration, paying back the per-service milestone cost amortised. Cons: larger CLI surface to parse; multi-service config inside one subprocess is awkward for MeedyaDL's per-service settings model (PerServiceSettings).

Licence implication (both candidates)

Both candidates are GPL-3.0. Same constraint flagged in the licence-obligations notes for get_iplayer (M8 prep). Subprocess invocation is "mere aggregation" so MeedyaDL's MIT code stays clean, BUT the offline-installer build path (bundle_engines=true in release.yml Step 8.5) would need to ship complete corresponding source (or a three-year written offer) alongside the binary. Default tiny-installer path (pip-install on first launch) is unaffected.

Decision options

Option	Trade-off
A — Integrate qobuz-cli for a focused Qobuz milestone (post-YouTube, M11+ territory)	Cleanest per-service mapping; lowest design complexity; lowest token-stability confidence (8 days public history)
B — Integrate streamrip and amortise across Qobuz + Tidal + SoundCloud	Best ROI on integration work; more complex per-service settings plumbing; commits to multi-service in one engine before YouTube is even done
C — Defer until upstream stabilises	Honest about the April-2026 Qobuz auth break still being upstream-side; revisit when either candidate publishes a year of stable releases

Value/effort

• A (qobuz-cli): ~1 milestone (M11 or later). Mirrors the votify integration cost almost exactly.
• B (streamrip): ~1 milestone for the engine + ~0.5 per added service. Possibly the right answer if Tidal is wanted within 6 months.
• C (defer): zero engineering cost, no roadmap movement. Lowest risk.

Owner question

Pick one of A / B / C. Decision pending — labelled for consideration per the standing-practice memory.

Cross-links

• Supersedes the Qobuz portion of Evaluate Tidal, Qobuz & Amazon Music integration via credential-based CLI tools #266 (which was rejected on its specific SpotiFLAC proposal, not on the Qobuz target).
• Related to the multi-service architecture work tracked under Multi-service UI polish: queue + settings + sidebar (OnTheSpot-inspired, codebase-verified) #911.