Flush spotify streams before unmuting

[mahkoh]

When the streams are unmuted they often still contain a bit of ad because they are buffered.

[ghost]

Yes I can confirm this behaviour, it is just below a second. Thanks for the good work!

[mahkoh]

I don't think this can be fixed. The real solution is for spotify to become latency aware. You can see the same effects in the UI when it already shows the next song even though the old one is still playing.

[ghost]

Why not just adding half a sec of an offset value?

[mahkoh]

Unfortunately the latency is not consistent.

[gCurse]

What about adding an unmute delay of about 5 seconds and prior to unmuting encourage spotify to jump to the beginning of the current song?

[mahkoh]

Ideally we would seek to 0 once the ad ends. This would flush the buffer. However, spotify does not support seeking via MPRIS.

[gCurse]

But spotify supports "Previous" which seeks to 0 if the song is playing for about 3 (or more) seconds. I now use this script (see lines 56-57) and it works ~seamlessly~ fine for me.

[mahkoh]

I'd hardly call this working seamlessly:

            if advert:
                advert = False
                time.sleep(6.0)
                player.Previous()

            pulsesink_mute(0)

But since the interval is only 3 seconds I might think about implementing this properly.

[ghost]

If it helps, here's how to do prev for spotify:

dbus-send --print-reply --dest=org.mpris.MediaPlayer2.spotify /org/mpris/MediaPlayer2 org.mpris.MediaPlayer2.Player.Prev

[mxmilkiib]

Presumably, in this case, at the point of the notification, the audio buffer power level is at non 0 (playing the tail end of the ad). The audio buffer level presumably then goes to 0 output amplitude for at least a sample at the end of the advert, no? Could detecting that 0 volume sample be used to trigger unmuting the audio?