fixes #1020 Pressing "Next track" via headphones will skip to next track but pause

[root-intruder]

Problem

On Bluetooth headsets (reproduced with Pixel Buds Pro 2 on a Pixel 9), single tap correctly pauses playback, but double tap (next track) had wrong behavior:

• the app moved to the next track
• playback then paused/stopped instead of continuing playback automatically

Expected behavior: The headset "next" action should skip and continue playback immediately.

This problem is also described in issue #1020 .

What changed

Adjusted skip handling in lib/services/music_player_background_task.dart:

• Updated skipToNext() and skipToPrevious() to better handle cases where a pause fade-out is in progress.
• If a fade-out is active when skip is triggered, playback is resumed appropriately so skip does not end in a paused state.
• Added a safety check to resume playback after skip when playback should still be active.

This targets media-button event sequences from some Bluetooth headsets where pause/skip can arrive in quick succession.

Verification

Verified manually on my own device setup:

• Phone: Pixel 9
• Headset: Pixel Buds Pro 2

Result: double tap now skips to the next track and playback continues as expected.

Notes

I am not a Dart developer.
This fix was done with vibe coding support, then tested on-device to confirm the behavior works in practice.

[Komodo5197]

It looks like this fix relies on the fade period to determine the double click happened, but fading is actually disabled by default, so I believe this fix will not work for most users. I think you need to add a variable tracking the time of last play/pause and use that to catch the double click. Also, do you have any data on how much time could maximally elapse between the double click? I want to minimize the chances we accidentally revert a legitimate pause and skip input from a non-faulty interface.

[root-intruder]

@Komodo5197 My fading is disabled in the UI (set to 0) and pause as well as skip works well. For the double click time i would assume the time span between the clicks is below 1sec.

[Komodo5197]

Interesting. If you have a 0 fade time and the fix is working, that presumably means that _player.playing is true when the skip is called but false when the actual seek completes. So I guess it would be relying on the gap between the pause and skip inputs being smaller than the latency for us to receive the pause confirmation from the native player. That does not feel like something we should be relying on, so I think explicit time-since-pause tracking worth implementing.

I think it might help me out if you stick a log statement at the very start of the play(), pause(), skipToNext(), and skipToPrevious() methods. You can then do a couple skips around and upload the logs. That way we can get the exact timings the app is receiving and how consistent they are.

Also, the linked issue confirms that the issue also manifests as playback beginning when skipping while paused, but I believe this PR currently only handles the case where you start while playing. The paused case should also be addressed.

[root-intruder]

Good point @Komodo5197 .
I added entry logging at the start of:

• play()
• pause()
• skipToNext()
• skipToPrevious()

The logs include playing state, fade direction, index/position, and relevant flags (disableFade/forceSkip, hasNext/hasPrevious, loopMode).
In the logs there is first skip while playing with my fix and then also skip while paused which skips and automatically starts playing the next track, a behavior also common on other players.
log.txt

[Komodo5197]

So the skip fires before the pause? That does not match what I expected at all, but if it is consistent it does make our jobs easier, because it allows us to detect the false input immediately instead of retroactively when the true input fires. You can just create a member variable which you record the current time to when calling skip in either directions, and then add code to play/pause to avoid taking action if that variable has a time less than 50 milliseconds ago. This avoids any need to consider the fade state and completely prevents sending incorrect commands to the native player.

By the way, generally resuming playback when skipping may be the way some players operate, but it does not match how Finamp behaves on other devices or via non-bud interfaces, so that's not a good argument to leave the behavior in place. If we want that behavior we can implement it properly, but having it only in certain places due to a bug is not good.

[root-intruder]

@Komodo5197 OK changed it like you recommented. working also like a charm with pixel buds. Additionally, now if playback is paused and i skip to next playback will remain paused like you whished for.

[Komodo5197]

The code looks good to me, so if the fix is working for you I think the functional changes are complete. If you add the requested comments, this should be good to merge.

[Komodo5197]

Okay, I've merged the changes. Hopefully the other hardware mentioned in the issue thread presents similarly enough for this fix to apply.

[root-intruder]

awesome, thanks!

[Chaphasilor]

@Komodo5197 thanks for handling this one. From what I've seen the Pixel Buds are notorious for sending different commands than other bluetooth devices, and Finamp isn't the only app affected. If this PR really fixes it that's great!

And thanks for the PR of course, @root-intruder !