v1.6.1: parallel provider search — fixes the very long wait on lyrics finding (#9) - #10
Merged
Merged
Conversation
#9) Lyrics search could take ~10 minutes when a song was only available on a provider late in the chain: providers were tried strictly sequentially, each stacking retries and 20s network timeouts before the next one even started. - SmartLyricsMatcher.search now fans out to every enabled provider concurrently; requests within one provider stay sequential and politely delayed, so per-provider rate limiting is unchanged. - Results are collected in the user's configured priority order, keeping the old auto-accept early-stop semantics; providers cancelled mid-flight are reported via onSkipped so the UI shows them as untried, not failed. - Hard 25s wall-clock budget per provider (and for the plain-lyrics and last-resort fallbacks) so a hung host can never stall the search. - Faster retry backoff (500ms base) and tighter Ktor timeouts (12s request / 6s connect). - Version bump 1.6.0 -> 1.6.1 (versionCode 161) + release notes. Fixes #9 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01E85xwceLkGtvj5E2qiYTDd
…calize The rescue path walked its cleaned queries and both canonicalize endpoints strictly sequentially, so slow hosts stacked up inside the new per-provider time budget and could leave it with nothing to score. Each query now runs concurrently with its own budget (partial results are still scored on timeout), and iTunes/Deezer are queried simultaneously. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01E85xwceLkGtvj5E2qiYTDd
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #9 — lyrics search could take ~10 minutes when a song was only available on a provider late in the chain (e.g. QQ Music), because providers were tried strictly one after another, each stacking retries and 20s network timeouts before the next one even started.
What changed
All providers are queried at the same time
SmartLyricsMatcher.searchnow fans out one concurrent job per enabled provider. Requests within one provider stay sequential with the polite inter-request delay, so per-provider rate limiting is completely unchanged — only the waiting overlaps. Total search time is now roughly the fastest provider that has the lyrics, not the sum of every slow one before it.Priority order and early stop preserved
Results are collected in the user's configured provider order (Settings → Provider order), so the same match wins as before when several providers find the song. The auto-accept early stop still works: once the chain-so-far holds an auto-accept hit, lower-priority providers still in flight are cancelled (already-finished ones are merged for free as extra manual-search suggestions). Cancelled providers are reported via a new
onSkippedcallback so the per-provider dropdown shows them as untried, not failed.Hard time budget per provider
Each provider gets a 25s wall-clock budget (
MatchConfig.providerTimeoutMs) — a hung host is skipped instead of stalling the search. The same budget now bounds the plain-lyrics fallback and the last-resort rescue, which run after a failed search and could otherwise re-create the long wait.Faster retries and tighter network timeouts
Last-resort rescue parallelized too
Its cleaned queries now run concurrently (each with its own budget, partial results still scored on timeout), and
LastResortAPI.canonicalizequeries iTunes and Deezer simultaneously instead of back-to-back.Release
RELEASE_NOTES.mdrewritten for v1.6.1; CI publishes the signed APK release automatically from the version bump.Testing
:app:compileDebugKotlinand the full JVM unit test suite (:app:testDebugUnitTest) pass — 70 tests. Two live-network LRCLib tests flaked under rate-limiting when the whole suite ran back-to-back and pass in isolation (the documented procedure in their own header comment).LastResortMatchTestconfirms the parallelized rescue path still rescues garbled filenames end-to-end against real providers.🤖 Generated with Claude Code
https://claude.ai/code/session_01E85xwceLkGtvj5E2qiYTDd
Generated by Claude Code