Last seconds of ad coming through

[GijsTimmers]

Similar to https://github.com/serialoverflow/blockify/issues/125.

I think it's just the last second of the ad that doesn't get muted properly.

[phil294]

I can confirm this issue. "Fixed" it locally by prepending sleep 1 into the unmute function.

[Xenphor]

I have this issue too but it only happens one some ads.

[str]

+1

[phil294]

@omega3

Can you give instruction how to do it? What file to edit and what line exactly?

Here: https://github.com/SecUpwN/Spotify-AdKiller/blob/0be950365a2aec7ea25d73e1369e8ea2b750a8d6/spotify-adkiller.sh#L265

add the sleep. It's been a while and I am not using this anymore, but the script edited by me back then has a sleep of 2.2 seconds. Dont know why 2 instead of 1 but adjust like you want

    unmute(){
        sleep 2.2
        debuginfo "pactl: unmute"

[hcgrove]

I also experienced this (it was only 0.5-1 second of each ad in my case) when I used this, and experience the same now in somewhat similar but also somewhat different conditions (somewhat longer though). I came here to see if a (proper) fix had been found/developed.

My thought on this is that this is mostly (or exclusively?) caused by buffering/latency, in the sense that at the point this discovers that spotify is about to resume playing a wanted track, the last parts (0-2.2 seconds from the reports) of the ad has been processed by spotify and sent on, but not reached your speakers/headphones. The unmute is then processed faster, so that when this executes that it is effectuated before the buffer is emptied. This explanation pretty much requires that it can also happen when going from track to ad, but most tracks end in a way (fading out) that makes it harder to observe, but I believe I have observed exactly that, with the different solution mentioned above, I don't remember if I experienced when I used this.