maxrave-dev / maxrave-dev/SimpMusic

Playback stops permanently with 00:00 / NA:NA at track transition after a brief network loss (broken since v1.0.4)

Open
#2,239 7 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Kotlin
Stars
11.4k
Forks
599
Avg merge
3d 18h
Merged PRs (30d)
7

Description

Duplicate Check
  • I confirm I searched for existing reports and found no duplicates.
Describe the Bug

When the network drops briefly while a song is playing (very common while moving around with the phone: leaving Wi-Fi range, mobile signal blips), the current song keeps playing fine from its buffer. But when it ends, the next track fails instantly with "Source error": the player shows position 00:00 and duration NA:NA, and playback stops permanently. It does not recover even if the network came back minutes before the transition.

This is a different bug from #2022 / #2233. Same visible symptom (music stops mid-queue), different cause: this one is triggered by a short network loss and kills playback at the next track transition.

Root cause (verified in logcat, details below): CrossfadeExoPlayerAdapter precaches upcoming tracks in background ExoPlayers. If the stream URL resolution fails during a network blip, that precached player dies silently (STATE_IDLE with playerError set) but stays in the precachedPlayers map.

Affects all versions since v1.0.4, which introduced CrossfadeExoPlayerAdapter and its precache mechanism (no playerError check existed in any version).

Steps to Reproduce
  1. Play a queue (autoplay/radio) on Android.
  2. While a song is playing, cut the network for ~10 seconds (toggle airplane mode, or walk out of Wi-Fi range). Timing: the cut must overlap the moment the app precaches the next track, which happens right after a track transition.
  3. Restore the network. The current song keeps playing normally.
  4. Wait for the song to end.
  5. The next track shows 00:00 / NA:NA and playback stops. Play/pause does not recover it.
Expected Behavior

A short network loss should not kill playback. If a precached player failed, the app should prepare the track again at transition time (the network may be back), and if it is still offline it should surface a retryable error instead of stopping silently on a dead player.

App Version

1.5.1

Android Version

Android 16

Device Model

Samsung Galaxy S23 (SM-S911B)

Custom ROM
  • I am using a custom ROM
Log / Error Details

Full logcat available. Key sequence (same app process across both captures):

The precache player for the upcoming track dies during the network blip, 4 resolve attempts then a permanent error:

18:11:31.142 E Stream: Error: Unable to resolve host "music.youtube.com": No address associated with hostname
18:11:31.142 E Stream: Failed to resolve stream URL for qeMFqkcPYcg
... (3 more retries: 31.287, 32.337, 34.393)
18:11:34.405 E ExoPlayerImplInternal: Playback error
18:11:34.405 E ExoPlayerImplInternal:   androidx.media3.exoplayer.ExoPlaybackException: Source error
18:11:34.405 E ExoPlayerImplInternal:   Caused by: java.io.IOException: Failed to resolve stream URL for qeMFqkcPYcg

Network is back at 18:15:10 (the next precache resolves fine), but the dead player is never re-prepared. Eight minutes after it died, it is swapped in as the current player and the session reports its stored error 4 ms later:

18:19:17.295 D CrossfadeExoPlayerAdapter: Using precached player for qeMFqkcPYcg
18:19:17.296 D CrossfadeExoPlayerAdapter: State: PREPARING -> PLAYING (playWhenReady=true)
18:19:17.297 D DelegatingForwardingPlayer: Delegate swapped successfully
18:19:17.300 D MediaSessionService: ... playbackState=PlaybackState {state=ERROR(7), position=0, buffered position=0, ... error=Source error}

Possible fix directions:

  • At swap time, if the cached player has playerError != null (or is idle), release it and fall back to the existing fresh-player path.
  • Attach an error listener to precache players so a failed one is evicted from precachedPlayers, allowing re-precache when the network returns.
  • Consider adding ERROR_CODE_IO_NETWORK_CONNECTION_FAILED (2001) to the retryable codes in onPlayerError (the comment mentions it but the condition omits it).

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with CrossfadeExoPlayerAdapter and trace how precachedPlayers are created, swapped, and handled by onPlayerError. Reproduce the network-loss transition and verify that a failed or idle cached player is not reused, that the track can be prepared again when connectivity returns, and that continued offline failure produces a retryable error.

Written by the indexing model from the issue text.

Assessment

Tech stack
android, kotlin
Domain
mobile
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
72/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.