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.

12

This is still happening. And because it’s intermittent, by definition, there IS no way to simply reproduce the problem and save a log. My only option is to leave debug logs enabled for a long period of time and wait for it to occur. I have uploaded a new log from today that I have trimmed down to approximately a 2 hour period. The logs are far too verbose for me to interperet myself, but I can say that the song “Dredg/Catch Without Arms/09 - Spitshine.flac” was playing, the BT device disconnected, which triggered the “MEDIA_COMMAND - COMMAND : stop” api call. A few seconds later, it was resumed by “MEDIA_START - RESUME : true”, and instead of resuming that track, it started from the very first track of the playlist, “Cartel/Chroma/01 - Say Anything (Else).flac”

13

Ok this is because you stop at a moment where there’s no resume point set due to your settings.

Change the min play percentage to played to 99 and the min play before resume to 0 to reduce the risk.

But again you are trying to do things that are meant to be handled by the queues.

14

OK, I have changed those settings.

What I want to do can not be achieved using queues, so I am working within the limitations of the app. Queues are too easily lost, playlists are permanent. Queues can not be synced with my media provider, playlists can. Queues do not mirror changes made to a playlist: additions, deletions, sorting, etc. Queues do not have auto-caching rules, playlists do. Queues are identified by ID numbers that aren’t permanent so API calls to control it are problematic, playlists can be identified by their name or a permanent ID number. Queues can not be randomized by album, playlists can.

To be honest, I don’t understand why Queues even exist. I’m sure they are useful to the app internally, but I can’t see a scenario where they are useful to the end user. In my opinion, a singular Now Playing queue would be useful, but only when playing non-playlist tracks. When working with a playlist, the playlist itself is much more useful as the “queue”, which could be handled by the app internally and transparent to the user.

Can you elaborate on the theory and use case for Queues, as they are currently implemented? Maybe I just don’t get it…

15

Queues contains everything including the playback settings …

You can switch from listening to a playlist at normal speed to an audio book at 2x and skip silence.

And switch between both without loosing the positions and the settings.

That’s just one use case and there’s plenty of others.

And no, the now playing queue is not a playlist, when you reorder or add new items or use smart queue / smart flow you don’t touch the playlist, and editions to the playlist can’t be directly reflected in the queue 99% of the time …

Already explained that to you a couple of times already :wink:

16

These all things that could have been implemented directly into playlist functionality, with the only exception being the automatic mixes and smart flow-type features. In those few cases it makes sense to have a “transient” often-changing Now Playing queue. Otherwise, any other desired usage would be better served using playlists (if the required features were added).

In any case, neither way works the way I’d like it to, so I have to find which way works better with lesser tradeoffs, and that’s by using Playlists.

17

Yes if we ignore half the functions and the fact that Symfonium is multi provider and that no provider would allow to store those stuff on their side :wink:

So no actually it could not … I wonder how many apps support what you want and have APIs and everything ? :wink:

18

Symfonium doesn’t restrict itself to supporting only things that are also supported by every other provider, that would be nonsense. Besides, Symfonium advertises itself as “Offline first”, so what the poviders do and do not support shouldn’t be relevant to what the app itself is allowed to do.

None! Which is why I bought this one… Even if it only gets me 90% there, I can still wish for the last 10%

19

What can I look for in the logs to confirm this for myself in the future? It’s happened a few more times. I do have another log, but instead of posting them every time it happens I can check myself instead of wasting your time.

And/Or… Could that setting be stretched to 100%, so that it always saves a resume point?

20

I’m still experiencing this issue pretty frequently. I have uploaded a new log trimed to the previous day when the playlist was stopped, up to the incorrect resume.

Plaback was stopped at 2025-08-19 14:43. At that time, “Armor for Sleep/Smile for Them/01 - Smile for the Camera.flac” should have been playing. I can’t tell for sure, again due to the excessive verbosity of the logs! Maybe it was just loading that track and the one playing was a track or two before. That is track #850 in the playlist.

That playlist is resumed again at 2025-08-20 11:58, and the track the resumes is “Delain/April Rain/11 - Nothing Left.flac”. This is is track #664 in the playlist, almost 200 tracks behind.

EDIT: I have a lot more logs where this keeps happening, even with resume point settings set to the best case scenario, but I forget to upload them when I get home and later I dont remember the specifics so I’m unable to describe exactly what happened and when.