Different approach to ad spotting

[carlosgarciafm]

I noticed you're querying playerctl for the track's title and artist to determine if the song is indeed an ad. Is there a reason you are not asking for the trackid instead?

Some of the ads served lack one or both title and artist. They, however, always include its trackid information. Moreover, the trackid follows a rather helpful format:

• spotify:ad:trackid for ads,
• spotify:track:trackid for songs and
• spotify:episode:trackid for podcast episodes.

I think using trackid could lead to a more robust and straightforward solution to ad spotting. Granted, the lack of information might be exclusive to the ads served in my region or to a limited number of ads. So more research is needed.

[KivalM]

After a bit of investigation, I believe you are correct. I was unaware of the existence of the 'ad' part of the track-id. This should surely improve the reliability and streamline the process of detecting advertisements. I will push these changes soon.

Thank you for your contribution!!

[KivalM]

Changes have been pushed, thank you very much!

I may soon change the code so that it is directly requesting the trackid from the d-bus interface, cutting out the Playerctl middle man

[carlosgarciafm]

They, however, always include its trackid information.

Turns out this is not quite true. I've encountered ads with nothing but title information.

Then maybe:

• all songs and podcasts have a trackid , which makes sense since you have to be able to reference the song in spotify's db; and
• only most ads include it since ads are irrelevant to the user.

What I'm getting at is that the current implementation (9cee57b8) might fail to mute ads without trackid. Something like this might be better:

let ad = response.starts_with("spotify:ad:") || response.is_empty();

PS: excuse my rust if that is not the correct syntax.

[KivalM]

I do see how these inconsistencies can be problematic, thank you for pointing it out. I believe your implementation is correct and will add these changes shortly

[KivalM]

Should be good now