Playlist resumes wrong track.

Support
1

Issue description:

I have two playlists, they are resumed and stopped by API calls from Tasker. Sometimes when resuming a playlist the wrong track is played. It’s happened on a few occasions, and it seems to resume from a track position that the playback ended on a few days ago, rather than the most recently played position.

I do have a log where this happened, but I had to leave debugging enabled for a few days because it doesn’t happen all the time. It’s a 300mb log file, so I wasn’t sure you wanted me to upload that. I compressed it to a much smaller RAR archive and uploaded that. I thought it would be useful to have logs including the playlist being resumed, and the last time those tracks were played.

Logs:

Upload description: debug (4).rar

Additional information:

 

 

Reproduction steps:

 

 

Media provider:

Any provider

Screenshots:

     

2

I’m trying to review the logs myself to see if I can describe for you exactly which tracks played when, but it’s so verbose and I don’t know what I’m looking for!

I can say however, the first track that played this morning (2025-04-09 approx 11:15) is not where that playlist had ended the previous night.

3

I have no way to read 300Mb logs without even knowing what I’m looking for.

What api calls do you use? Do you pause before switch? …

4

A Tasker event fires for each of my Bluetooth devices when they are connected. On connection it runs MEDIA_START, MEDIA_TYPE:playlist, ID:8L or 9L depending on device, RESUME:true. On bluetooth disconnection it runs MEDIA_COMMAND, COMMAND:stop. “Ignore remote sop command” is disabled. I haven’t seen any difference when it’s enabled. I also have tried COMMAND:pause, but I don’t like how it leaves a notification and keeps the “now playing” status in-app.

After further reviewing the logs, here’s what I found:
I can’t identify any log line that states simply “this song is beginning playback now”. I presume there is one, it just doesn’t include the track title on that same line. The closest analog I found is lines containing “PlaybackController: closePreparedForRendering”. This shows me the following playback sequence for the specific playlist in question (which is in my car during my short commute to/from work):

2025-04-07 14:45:15.562 file='Gore/A Bud That Never Blooms/03 - Babylon.flac'
2025-04-07 15:46:15.619 file='Gore/A Bud That Never Blooms/04 - Angels Like You.flac'
2025-04-07 15:47:29.058 file='Gore/A Bud That Never Blooms/05 - Heaven Is Above Me.flac'

Playback stops here, and resumes the next morning:

2025-04-08 11:45:19.296 file='Gore/A Bud That Never Blooms/05 - Heaven Is Above Me.flac'
2025-04-08 11:49:37.306 file='Falling in Reverse/Just Like You/01 - Chemical Prisoner.flac'
2025-04-08 11:49:50.741 file='Falling in Reverse/Just Like You/02 - God, If You Are Above....flac'

Stops here, and resumes later that day:

2025-04-08 16:01:05.027 file='Falling in Reverse/Just Like You/02 - God, If You Are Above....flac', title='God, If You Are Above...'

Stops here, and the following morning it resumes at:

2025-04-09 11:16:10.425 file='Falling in Reverse/Fashionably Late/15 - Rolling Stone [Remix (Shy Kidx)].flac'

This song is about 20 tracks earlier in the playlist. Now that I’m seeing it layed out like this, two things I remember that might be relevant. First, “15 - Rolling Stone [Remix (Shy Kidx)].flac” was skipped before the track ended (which happened before I enabled debug logging, probably some time last week). And second, the previous playback session starting at 2025-04-08 16:01:05.027 was paused for most of the drive while I was on a phone call. So that might explain why its position wasn’t saved, but shouldn’t explain why it would resume the next time 20 tracks behind.

Please let me know if there is anything else I can do to assist in debugging.

5

I need smaller logs just reproducing the issue or a precise reproduction, I can’t parse that much logs for a feature that only you use as not tied to the UI.

6

It happens intermittently, and I don’t know if it’s related to the last time that playlist was stopped, or if it’s related to when the playlist is resumed. If I enable debugging every time I resume a playlist, would that give you enough information? I suspect not, as if that were the case then I could simply send you only the log items from 2025-04-09. If instead the problem occurs the last time playback was stopped, I would need to leave debugging enabled for long enough to capture both events, which is how I ended up with a 300gb log.

What do you suggest I do?

7

Find a way to repro with the api calls and force killing the app or things you usually do.

8

This happened again today. On resume, it started playing all the way back to that same track again, 15 - Rolling Stone [Remix (Shy Kidx)].flac. Could this have something to do with the Min play percentage to mark played (95), Min play time to save resume (0), and/or Max play percent to record skip (50) settings?

I can’t reliably reproduce the problem, because it happens intermittently and there don’t seem to be any obvious causes.

9

Play queues are unrelated to those. They are saved on each change.

If you manually load both queues the positions are correct ?

10

I’ve been experimenting and found a few things. I disabled my Tasker profiles, and found that in my car, playback begins automatically when BT connects, resuming from whatever it played last. The car has no option to disable that “feature”. It’s not Symfoinium auto-resuming because “Bluetooth auto play” is disabled in the app. If I understand correctly, that means the car is essentially sending a signal to the phone as if I pressed the play/resume button, and Symfonium picks it up since it has a MediaButtonIntentReceiver? At first I thought that command should be ignored since auto play is disabled in-app, but if it did ignore that would it also mean it would be ignoring actual user initiated play/pause, skip, etc commands from the BT device? Or is there a way that Symfonium can tell the difference between the auto-play command and an actual user-iniated command? If that’s possible, could it be honored or ignored based on the “BT auto play” setting?

My “dumb” BT speaker at work does not auto-play, I have to either resume the playlist manually or let Tasker resume. If I only had one playlist that would be fine, but since I’m switching between multiple playlists depending on location, auto-play in the car isn’t going to work properly.

How does this relate to my current problem… Could it be possible that Symfonium gets that command from the car, and then at the same time gets a resume api call from Tasker, and that somehow “confuses” it and ends up resuming the wrong position?

11

I don’t do guesses games it’s just time lost.

And no there’s no way to differentiate a remote command from another.