finamp
finamp copied to clipboard
jmshrv
Songs randomly stop playing and advance to the next in the playlist [iOS]
I have been having this problem on iOS for quite awhile, and it has gotten to the point where it is starting to become annoying.
Occasionally, a song that I am listening to will stop playing in the middle and advance to the next in the playlist. This occurs about 1 time per 45 minute album, so it is not catastrophic, but it is annoying. There is nothing wrong with the song, because if I click to replay it, it generally works fine.
I note that I generally listen to flac files with direct streaming, but that my wifi network is fast so I don't think that this is a buffering issue. I'm happy to help debug this, if you give me some pointers as to what I should look for.
Commenting to add that this is happening to me on the Android app as well while playing a playlist. Playing 320kbps mp3s direct. Not sure yet how to replicate it, seems to be random.
Here are some logs from my jellyfin server at the approximate time an instance of the error happened. Not sure if relevant but closest I could find, maybe the lost WebSocket connection?
EnableAudioPlaybackTranscoding: True
[2022-07-22 15:31:36.770 -06:00] [INF] [77] Emby.Server.Implementations.Session.SessionManager: Playback stopped reported by app "Finamp" "0.6.4" playing "Innocent". Stopped at "0" ms
[2022-07-22 15:32:24.620 -06:00] [INF] [115] Emby.Server.Implementations.Session.SessionWebSocketListener: Sending ForceKeepAlive message to 1 inactive WebSockets.
[2022-07-22 15:32:36.620 -06:00] [INF] [115] Emby.Server.Implementations.Session.SessionWebSocketListener: Lost 1 WebSockets.
[2022-07-22 15:36:12.561 -06:00] [INF] [84] Emby.Server.Implementations.Session.SessionManager: Playback stopped reported by app "Finamp" "0.6.4" playing "22". Stopped at "0" ms
[2022-07-22 15:36:13.858 -06:00] [WRN] [138] Jellyfin.Server.Middleware.ResponseTimeMiddleware: Slow HTTP Response from "https://jelly.*******.***/System/ActivityLog/Entries?startIndex=0&limit=7&minDate=2022-07-21T21%3A36%3A12.727Z&hasUserId=true" to "192.168.1.1" in 0:00:00.6394811 with Status Code 200
[2022-07-22 15:36:14.006 -06:00] [WRN] [71] Jellyfin.Server.Middleware.ResponseTimeMiddleware: Slow HTTP Response from "https://jelly.*******.***/System/ActivityLog/Entries?startIndex=0&limit=4&minDate=2022-07-15T21%3A36%3A12.729Z&hasUserId=false" to "192.168.1.1" in 0:00:00.7890996 with Status Code 200
[2022-07-22 15:36:14.160 -06:00] [WRN] [72] Jellyfin.Server.Middleware.ResponseTimeMiddleware: Slow HTTP Response from "https://jelly.*******.***/System/ActivityLog/Entries?startIndex=0&limit=7&minDate=2022-07-21T21%3A36%3A12.722Z&hasUserId=true" to "192.168.1.1" in 0:00:00.9423416 with Status Code 200
[2022-07-22 15:36:14.308 -06:00] [WRN] [10] Jellyfin.Server.Middleware.ResponseTimeMiddleware: Slow HTTP Response from "https://jelly.*******.***/System/ActivityLog/Entries?startIndex=0&limit=4&minDate=2022-07-15T21%3A36%3A12.718Z&hasUserId=false" to "192.168.1.1" in 0:00:01.0890877 with Status Code 200
[2022-07-22 15:36:16.759 -06:00] [INF] [94] Emby.Server.Implementations.Session.SessionManager: Playback stopped reported by app "Finamp" "0.6.4" playing "False God". Stopped at "0" ms
I'm also affected, and I believe this is due to network timeouts. On my commute I have a station where there is no connection and it helped me pinpoint the issue. Shortly after arriving at the station, playback stops due to the buffer running out as discussed in #239, and here Finamp seems to try to skip to the next track, repeatedly. This results in playback resuming at a completely different track once Finamp reconnects.
Iirc, the issue is less of a problem when direct streaming, as it seems like caching does work better this way compared to when transcoding.
That's a very good theory, I'll see if I can change the behaviour when an item fails to play. A similar behaviour can be seen when downloaded items that have been verified fail to play (although that shouldn't ever happen in actual usage)
As for transcoding being more reliable, that may be caused by transcoding using HLS instead of just getting a HTTP stream of the file. HLS is better at handling stuff like seeking and interruptions in general. AFAIK, I can't really make direct streaming work with HLS due to codec requirements, but if I could it would make my life much easier.
As for transcoding being more reliable
Ah sorry, I was missing a word there. Transcoding is less reliable is what I meant, caching seems to work better when direct streaming. I edited my comment :)
Oh lol, in that case I could guess that HLS's complexity causes either Jellyfin or Finamp to get confused when one side stops responding 🙃
The added complexity of transcoding probably doesn't help either
My wife and daughter have had Finamp stop playing in the middle of a song on Android. This happens to them even when they are connected to the local network which shouldn't have any issues with timeouts. In their case it does not skip to a new song it simply stops. Pushing play seems to start playing again.
I only have MP3 and AAC. I am trying to get my daughter to catch the logs the next time it happens but so far she hasn't sent me the logs yet.
I have some logs to help. I'm on the Surface Duo with 12L and latest July security patch. I tried to force stop and clear cache but that didn't work this time. Normally that would fix it for some time.
null
[MusicPlayerBackgroundTask/SEVERE] 2023-07-09 12:37:36.144522: Connection timed out
null
[MusicPlayerBackgroundTask/SEVERE] 2023-07-09 12:37:36.146870: Connection timed out
null
[MusicPlayerBackgroundTask/SEVERE] 2023-07-09 12:37:36.147506: Connection timed out
Looks like a timeout then, I wonder if we can change the behaviour
Yeah that would be great, whenever my phone loses connection Finamp decides to skip ahead like 20 songs because every song times out 😅
Should we just pause when a playback error occurs then? I doubt there's a clean "retry infinitely" option.
Yeah I think that's the best solution: If no data connection and music is at the end of the buffered music: Pause song
On data connection resume: Buffer music, then resume playing
Should we just pause when a playback error occurs then? I doubt there's a clean "retry infinitely" option.
like @JengaMasterG said, only pause until the playback buffer is filled up again. If my phone reconnects, I would definitely like the music to resume! Maybe switching to the paused state isn't the right approach, maybe there's a setting in just_audio defining how large the buffer needs to be before playback is resumed?
I've been using Finamp a lot recently and can now also confirm the "pausing" behavior mentioned by @rawkhopper. Sometimes a song simply pauses for no apparent reason, and resuming it works just fine. I don't think a network issue is the problem either. Maybe it has something to do with audio_session / audio_service trying to handle a system interruption (e.g. it automatically pauses when a phone call starts), but the interruption is so short that unpausing doesn't work properly? Just a theory at this point.
Regarding the pausing behavior, I might have a lead now:
https://github.com/jmshrv/finamp/blob/b4a18056916925610701fcf406332ab4aef5f46c/lib/services/music_player_background_task.dart#L177-L187
Turns out the sleep timer is actually not fully cleared when it expires and pauses playback. Only pressing stop, restarting the app, or manually canceling the timer (only works when the timer is running) will do that. And every time playback is resumed after the timer paused playback, the timer is restarted!
I use the sleep timer every now and then, and the explanation fits nicely with the behavior I'm seeing, where sometimes I don't have this problem for days, and then sometimes I get it in regular intervals, even when the app is open.
@rawkhopper are you also using the sleep timer sometimes, and can you confirm my theory?
Hello, My wife is the one that experienced the issue. We do not use sleep mode intentionally. Maybe it got turned on by accident. It might explain why we have not seen the issue in quite some time.
Okay, that sounds promising! I'll remove the restarting sleep timer for the redesign (since it's technically a breaking change).
I'll also go ahead and close this issue, but feel free to re-open if the problem appears again!