Mute Spotify during Ads

[Batwam]

Hello, it's me again!

I came across this Spotify Ad-Block extension and found that it would be easy to implement something similar as we already have all the building blocks to identify mpris info, mute/unmute, ... Essentially, the idea is to spot if trackID contains spotify/ad/ which was actually suggested by a user.

Let me know what you think. I have tested it for a while and it's working well so far. It won't block chromium based ads but despite my investigations, I don't think that this will be possible as chromium appears in the streams list but not in the mpris list so there is no way to know if the browser it being used for an ad or not unfortunately. Note that Spotify has a tendency to spawn multiple streams when ads are started, that's why I'm muting all of them.

I included a default lag of 1400m (essentially 5x300ms refresh cycles based on default refresh rate) to avoid unmuting before the end of the ad. If you use the Spotify app, please check if that default duration works for you. When muting, the icon/album will show the mute icon so people can visually see why it has gone quite. I could have gone of an OSB but I thought that the icon change was more subtle.

Finally, if the user disables the extension in the middle of an ad, extension will unmute as part of disable(). I know that this is quite unlikely but I felt that the extension should leave the system as it would be if it wasn't there. I made the code generic as possible to allow the ad-blocking functionality to be extended to other sources of possible in the future.

[Moon-0xff]

Cool! but it's way better if that functionality is independent from the extension. Actually, it would be way better if it's independent from GNOME.

Adding this to the extension is duplicating the effort of the extension you linked.

Blocking ads can be quite challenging, so it of course benefits if there's a joint effort of achieving that.

[Batwam]

yeah, I was interested to see how easy it would be to implement and didn't want to have a second extension running and icon in the panel when they could be integrated. This said, there is definitely a risk of maintenance burden or breakage if/when spotify changes the way they implement ads so I see why it might be beat not to duplicate.

I guess, the reason it was built as an extension is that it allows easy deployment and gjs has the building blocks for mpris and volume using gjs. The user who suggested the spotify/ad/ method seemed to have it implemented as a script. There are other solutions which aren't gnome based such as Calaboka, however, I believe that it only works if you also have Spotify installed as a snap. Spotube is another alternative which I believe doesn't skip ads (not sure of the method).

Anyway, just putting it out there if you feel it makes sense to have this built-in, otherwise, we can just drop the idea.

[Moon-0xff]

If we can read this.activated from spotify-ad-blocker, then we can change the logo or implement any other behaviour when an ad plays, without having to duplicate the underlying logic.

I definitely see value on adding that.

spotify-ad-blocker has an option to hide the icon (or that's what I read in the code) so I don't think we should worry about the icon, but if we can read this.activated from the extension I'm pretty sure we can also flip that setting ourselves.

[Batwam]

I suspect that accessing this.activated might be difficult. However, it may be possible to access other extensions gsettings values. This crossed my mind when investigating the dash-to-panel issue #47.

The Spotify blocking extension has a little quirk which potentially could be exploited as it saves the song volume into gsettings. If don't really understand why it's done that way (possibly so it can stay persistent on restart) but by monitoring changes in this value, we could find out if Spotify has been muted or not...

<!-- Used internally to persist volume before ads. Not intended to be modified by user. -->
    <key name="volume-before-ads" type="i">
      <default>-1</default>
    </key>

As far as I can tell from reading the code, the value is different than -1, the sound is muted as it sets it back to -1 on unmute.

This said, I'm not sure it's worth the effort implementing something which is dependent on external code which might change, just to change the icon. I'd probably rather keep the codes independent and just forget about this PR altogether?

[Moon-0xff]

Yes, I don't justify the effort of implementing it either, but as I said, there's value on adding it.

Of course it will be prone to breakage but it looks like the codebase is fairly stable, so I don't think it would be a problem to maintain.

But I'm pretty sure it will break eventually, like if the extension stops being maintained.

So overall: Nah. If you want to develop it I would accept it but there's not much value on that work honestly.