[CRASH] - app crash scrobbling when connection switch from WiFi to mobile

[MarcoMura85]

Description

When scrobbling trought a songs, if the connection switches from WiFi to mobile (and viceversa) the app crashes

Steps to Reproduce

1. Play a track
2. Force a connection switch
3. Scroll to another point of the track
4. See the crash

Environment

• Android device: pixel 9
• Android OS version: 19
• App version: 4.20.0
• App variant: goole play services

Crash Logs/Stack trace

java.lang.ArrayIndexOutOfBoundsException: length=1; index=-1
at ka2.e(r8-map-id-c5d7a1059cec11ad1857975b59ab19de094b2b382895e558dcf20fd3cb8e2be7:121)
at c43.n(r8-map-id-c5d7a1059cec11ad1857975b59ab19de094b2b382895e558dcf20fd3cb8e2be7:38)
at ka2.y(r8-map-id-c5d7a1059cec11ad1857975b59ab19de094b2b382895e558dcf20fd3cb8e2be7:283)
at fa2.run(r8-map-id-c5d7a1059cec11ad1857975b59ab19de094b2b382895e558dcf20fd3cb8e2be7:21)
at android.os.Handler.handleCallback(Handler.java:1095)
at android.os.Handler.dispatchMessageImpl(Handler.java:135)
at android.os.Handler.dispatchMessage(Handler.java:125)
at android.os.Looper.loopOnce(Looper.java:269)
at android.os.Looper.loop(Looper.java:367)
at android.os.HandlerThread.run(HandlerThread.java:139)

Reproducibility

Not always but frequent following steps

[eddyizm]

Hi @MarcoMura85
I'm still trying to replicate this to get the stack trace. Question for you.
What are the timings you use, between your steps? I suspect I am going to fast, perhaps, and thus can't get it to crash.
The other thing is, what back end are you using?

[MarcoMura85]

Hi @eddyizm
My backend is Navidrome 0.62.0.

About timings its hard to say, after switching the connection I try to go to the unbuffered parte of the track pretty soon..

If could help, I am available to install a tempus version with more debug info

[eddyizm]

OK that makes sense. I was just testing but my filed are downloaded/synced so it's not buffering against the server.
The prerelease apks have full debug info.

Although I was trying the same thing on the emulator but it really is not a good comparison for real world devices, especially with connection issues.

[tvillega]

@eddyizm I ran the following:

$ANDROID_HOME/cmdline-tools/latest/bin/retrace app/build/outputs/mapping/tempusRelease/mapping.txt stack_error_transcript.txt 

Now the log is de-obfuscated:

java.lang.ArrayIndexOutOfBoundsException: length=1; index=-1
at androidx.media3.exoplayer.source.ProgressiveMediaPeriod.selectTracks(ProgressiveMediaPeriod.java:329)
at com.cappielloantonio.tempo.util.TranscodingMediaSource$TranscodingMediaPeriod.restoreTracks(TranscodingMediaSource.kt:281)
at com.cappielloantonio.tempo.util.TranscodingMediaSource$TranscodingMediaPeriod.onPrepared(TranscodingMediaSource.kt:239)
at androidx.media3.exoplayer.source.ProgressiveMediaPeriod.maybeFinishPrepare(ProgressiveMediaPeriod.java:896)
at android.os.Handler.handleCallback(Handler.java:1095)
at android.os.Handler.dispatchMessageImpl(Handler.java:135)
at android.os.Handler.dispatchMessage(Handler.java:125)
at android.os.Looper.loopOnce(Looper.java:269)
at android.os.Looper.loop(Looper.java:367)
at android.os.HandlerThread.run(HandlerThread.java:139)

[tvillega]

Here the array goes out of bounds:

tempus/app/src/main/java/com/cappielloantonio/tempo/util/TranscodingMediaSource.kt

Lines 274 to 286 in ee87e39

	private fun restoreTracks() {
	val selections = lastSelections ?: return
	val flags = lastMayRetainStreamFlags ?: return
	val childStreams = arrayOfNulls<SampleStream>(activeWrappers.size)
	val streamResetFlags = BooleanArray(activeWrappers.size)
	currentPeriod.selectTracks(selections, flags, childStreams, streamResetFlags, 0)
	for (i in activeWrappers.indices) {
	activeWrappers[i]?.childStream = childStreams[i]
	}
	}

[eddyizm]

@eddyizm I ran the following:

$ANDROID_HOME/cmdline-tools/latest/bin/retrace app/build/outputs/mapping/tempusRelease/mapping.txt stack_error_transcript.txt 

Nice! We need to add that to our bag of tricks, maybe even a contributor or dev file.

[tvillega]

Added in #823 (=