Player crash with EOF

[twistios]

Version of RiMusic

0.6.59

Android version

14

Tell us how you trigger this bug

1. Open RiMusic
2. Start a specific song (https://m.youtube.com/watch?v=IdlQ-rDuK_w)
3. Go back to list of songs
4. Scroll down list of songs.

What was your expectation?

The player should not stop/crash.

What more can you tell us? (Optional)

I think that the error could be related to that song but I am not sure. The song played for some time, maybe a minute, then the player crashed (not the app). I am not logged in so it rather not is the login error. The song is fully cashed. The crash happens reproducible at 1:02, so it seems like a cache error.

Logs (Optional)

2024-11-11 16:46:53:443 ERROR: PlayerServiceModern - PlayerService onPlayerError T2.m: Source error
    at T2.Q.j(SourceFile:17)
    at T2.Q.handleMessage(SourceFile:386)
    at android.os.Handler.dispatchMessage(Handler.java:102)
    at android.os.Looper.loopOnce(Looper.java:230)
    at android.os.Looper.loop(Looper.java:319)
    at android.os.HandlerThread.run(HandlerThread.java:67)
Caused by: java.io.EOFException
    at n3.l.j(SourceFile:25)
    at n3.l.l(SourceFile:29)
    at F3.d.g(SourceFile:4565)
    at f3.M.c(SourceFile:242)
    at j3.i.run(SourceFile:37)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:644)
    at java.lang.Thread.run(Thread.java:1012)

[twistios]

Details

https://github.com/user-attachments/assets/e2f82598-c4f0-4482-ae04-74d2ca148742

[twistios]

I know that probably this can be solved via deleting the cache for that song but still the underlying issue should be investigated.

[twistios]

The error is not related to scrolling the songs list as it can be seen from the video also.

[fast4x]

Interesting

[knighthat]

I think it's related #4421 #4420 which were fixed in #4425, can you compile latest code to test it?

[twistios]

The cached version has Itag 140. It was cached before the YTM login problems. Using latest code to test it is hard, as I don't know how the cache gets corrupted. So I don't know how I can know it got fixed.

[twistios]

I now think that the log is unrelated to the crash. So these seem to be two different problems. I have this suspicion because I got basicly the same crash with another song without any (useful) log output.

video 1

https://github.com/user-attachments/assets/b465b11e-8490-4f23-bc6d-ec9cfb1881a5

video 2

https://github.com/user-attachments/assets/c4485c0d-5772-4f60-87d8-c5d26bd8fd28

As it can be seen from the second video, it starts the second song after it fails. For the first song ("not fair") instead it restarted the playlist with the first song of the "all" category.

So maybe these problems are actually different problems and the log was related to the first problem.

[twistios]

I just noticed that both crash at 1:02 it seems. Pretty weird.

[CollegeTimeOhNo]

Having the exact same issue with a few different songs since getting the new update. It doesn't give any kind of information as to why, the player just disappears at a specific point for a few songs/after a random amount of songs it just ends with this update.

[fast4x]

Wait for new release, try also update the song.

[twistios]

Another song that fails with the same problem. It seems it got cached just before it crashed (as it is only 98% cached). It already crashes at 2:10 which is not the cached amount so it seems to be a cache storage problem.

[knighthat]

are you guys logged in to YT?

[twistios]

are you guys logged in to YT?

I am not. There are currently serval reasons why I am not logged in:

1. Currently I can not select my account (was possible before; I have multiple accounts in one e-mail address, so I needed to use a workaround as RiMusic can't handle multiple accounts in one address on it's own)
2. Login is kinda broken in 0.6.59 anyway

[knighthat]

Piped doesn't really know how to handle range. I was able to capture this error:

2024-11-13 13:42:59:579 ERROR: PlayerServiceModern - PlayerService onPlayerError androidx.media3.exoplayer.ExoPlaybackException: Source error
    at androidx.media3.exoplayer.ExoPlayerImplInternal.handleIoException(ExoPlayerImplInternal.java:736)
    at androidx.media3.exoplayer.ExoPlayerImplInternal.handleMessage(ExoPlayerImplInternal.java:708)
    at android.os.Handler.dispatchMessage(Handler.java:103)
    at android.os.Looper.loopOnce(Looper.java:232)
    at android.os.Looper.loop(Looper.java:317)
    at android.os.HandlerThread.run(HandlerThread.java:85)
Caused by: androidx.media3.datasource.HttpDataSource$InvalidResponseCodeException: Response code: 416
    at androidx.media3.datasource.okhttp.OkHttpDataSource.open(OkHttpDataSource.java:304)
    at androidx.media3.datasource.DefaultDataSource.open(DefaultDataSource.java:275)
    at androidx.media3.datasource.TeeDataSource.open(TeeDataSource.java:54)
    at androidx.media3.datasource.cache.CacheDataSource.openNextSource(CacheDataSource.java:802)
    at androidx.media3.datasource.cache.CacheDataSource.open(CacheDataSource.java:615)
    at androidx.media3.datasource.cache.CacheDataSource.openNextSource(CacheDataSource.java:802)
    at androidx.media3.datasource.cache.CacheDataSource.open(CacheDataSource.java:615)
    at androidx.media3.datasource.ResolvingDataSource.open(ResolvingDataSource.java:110)
    at androidx.media3.datasource.StatsDataSource.open(StatsDataSource.java:86)
    at androidx.media3.exoplayer.source.ProgressiveMediaPeriod$ExtractingLoadable.load(ProgressiveMediaPeriod.java:1045)
    at androidx.media3.exoplayer.upstream.Loader$LoadTask.run(Loader.java:421)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:644)
    at java.lang.Thread.run(Thread.java:1012)
Caused by: androidx.media3.datasource.DataSourceException
    at androidx.media3.datasource.okhttp.OkHttpDataSource.open(OkHttpDataSource.java:301)
    ... 13 more

Here's the error androidx.media3.datasource.HttpDataSource$InvalidResponseCodeException: Response code: 416 which means 416 Range Not Satisfiable. Can be solved by clear cache of this song and let it play from the beginning

[twistios]

@knighthat I think the error you captured is not exactly the one that I had. Mine is an java.io.EOFException which is more specific than what yours can be at max (java.io.IOException) Mine also is an java.io.IOException but it is shown as more specific already.

[knighthat]

it could've been that Piped or Invidious sent back an error but ExoPlayer misinterpreted it as song's data and tried to parse it. Anyway, have you removed the cache and replayed the song?

[twistios]

I have cleared the cache (via update song) for one of the songs where it was reproducible and this song played fine. I guess this error is not song-specific anyway, it is some kind of situation/random event dependant problem.

[twistios]

https://github.com/user-attachments/assets/0350ebc0-16c4-473a-8e16-ffb5d14b3e72

As it can be seen in the video, it gets recovered by clearing the cache (obviously, the problem can not be reproduced for this song anymore).

[knighthat]

this problem is pretty much known to me, I even mentioned it in #4166. For the time being, songs can only be played/download from the beginning with Piped API. If your song is half-cached, it will crash.

You can re-produce this by start a fresh song, when it starts caching, turn of WIFI or any other internet connectivity > close app and open it again > starts playing the song. If the song isn't fully cached, it will crash at where cached content ends

[twistios]

I got a new error for another song.

2024-11-14 17:17:28:668 DEBUG: MainApplication - Log enabled at /data/user/0/it.fast4x.rimusic/files/logs
2024-11-14 17:19:02:318 ERROR: PlayerServiceModern - PlayerService onPlayerError T2.m: Source error
    at T2.Q.j(SourceFile:17)
    at T2.Q.handleMessage(SourceFile:386)
    at android.os.Handler.dispatchMessage(Handler.java:102)
    at android.os.Looper.loopOnce(Looper.java:230)
    at android.os.Looper.loop(Looper.java:319)
    at android.os.HandlerThread.run(HandlerThread.java:67)
Caused by: j3.l: Unexpected IllegalStateException: No valid varint length mask found
    at j3.i.run(SourceFile:137)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:644)
    at java.lang.Thread.run(Thread.java:1012)
Caused by: java.lang.IllegalStateException: No valid varint length mask found
    at F3.f.c(SourceFile:38)
    at F3.d.g(SourceFile:3786)
    at f3.M.c(SourceFile:242)
    at j3.i.run(SourceFile:37)
    ... 3 more

What even is an "Unexpected IllegalStateException"?

[knighthat]

same error different wording, basically Piped sends back some gibberish and ExoPlayer tries to parse it as if it's song's data.

All of them are Source error which means that the response from server isn't what ExoPlayer expects

[twistios]

It is another one of these songs that look like they are fully cached. So it is some garbage at the end I guess, based on your argument @knighthat.

[knighthat]

I don't think the cache correctly reports actual data stored. Your comment here is an example, it says 98% but only about 4/5 of that contains actual data.

To my understanding, SimpleCache doesn't have any kind of data integrity verification. Correct me if I'm wrong but I think even when server sends back error response, SimpleCache will cache it too.

Another example to my theory, the song is cached to 100% even before you finish the song

[fast4x]

I think that is caused by buffering error ..

[twistios]

@knighthat I can prove that it does fully cache before the song has ended. See this video:

Video

https://github.com/user-attachments/assets/dadd4afd-fc45-429d-a1aa-38e7412f0fef

The player crashes at the beginning (nothing is cached and connectivity is disabled).

[knighthat]

I'm confused, what are you trying to prove here?

The player will crash, that is intentional, or it will crash the whole app.

In previous comment, I mentioned that SimpleCache does not verify data it received from the server. Meaning, even when the server sends garbage, it'll cache it as long as it can parse the data.

The cache works just fine as long as the response is actual song's data. If any corruption happens during the caching process, unless it's catastrophic, no error or warning is thrown, until ExoPlayer tries to play corrupted part and throw error.

Last part is is my own opinion and my understanding of SimpleCache. Correct me if I'm wrong

[twistios]

Another example to my theory, the song is cached to 100% even before you finish the song

@knighthat I was talking about this part and wanted to show that this also happens with correct behavior that it caches 100% before it is fully played.

It is possible that SimpleCache does not check data integrity.

Also, I think that the player should not crash, but instead show an error and give the user the possibility to continue with other songs of the playlist as currently it clears the queue. If the player has to crash, then the player can maybe instead be automaticly restarted with the queue and prevent direct playback.

About errors while caching: if we can not do anything about that, we should at least catch it at some point instead of a crash (with no other feedback than in the debug log).

[knighthat]

Please feel free to pickup where I left off HERE.

Atm, player will crash with exception "No Such Element" because the return of HttpFetcher#asyncMultiRequestGetFirstValid is null. This is because either responses from all Piped/Invidious servers are failed or no internet connectivity.

[twistios]

https://github.com/user-attachments/assets/08fc231b-a7d7-4734-8220-73d2d3f5d0a6

I got a new variant today. After restarting the app, it was broken in the "normal way" again (and the queue songs loaded).

[hennibadger16]

Still crashing on 0.6.60 😞