Open ferox opened 4 years ago
Hi there, i think because MacOS hosts location is /private/etc/hosts and not /etc/hosts
Also flush your DNS when added entries.
Let me know if that worked.
No, when I change the /etc/hosts the /private/etc/hosts is updated. I have flushed DNS, but the issue persist.
That's weird. Have you cleared Spotify cache file?!
Yeah, I did it!!
But it's not working.
It's working on latest Spotify 1.1.34.694.gac68a2b3 and macOS Catalina 10.15.5
@ferox could u please confirm on same version status?!
Well, give a couple of days to test. OK?
Sure man, no problem. Hopefully will work fine at your end. Let us know.
-Anis
My main box runs High Sierra, so I still use an old 32-bit version of Spotify that does everything I need.
I used your generous HOSTS lists on my test Box, running MacOS Catalina & Spotify v.1.1.34.694. After flushing my dnscache, I was still getting 5- or 6-second WalMart commercials, but they seem to have gone away after I deleted my Spotify cache folder in ~/L/Caches/ and restarted the app.
Anyway, I used LittleSnitch to intercept and deny some additional domains and addresses that snuck through. Thought I'd share them with you. In some cases, I denied the entire domain, in others, just the particular address. Here you go:
a.tribalfusion.com ad.sxp.smartclip.net adeventtracker.spotify.com adsd-sync.amanad.adtdp.com c1.adform.net cm.adgrx.com cr-p35.ladsp.jp d.agkn.com dntcl.qualaroo.com dsp.adfarm1.adition.com gu.dyntrk.com iad02-event.spotxchange.com iad02-search.spotxchange.com s.side3.zucks.net secure-gl.imrworldwide.com sync.tidaltv.com usersync.videoamp.com vop.sundaysky.com bloodhound.spotify.com a.adsrvr.org www.googletagservices.com s-static.innovid.com
Not sure what "bloodhound.spotify.com" is. Maybe they're using the bloodhound API for metrics or some other reason. Anyway, thanks again for your lists.
re: above
[CAUTION]
After many plays on Spotify over a few-hour period w/no ads, an ad did eventually come through, but because of one or more of the add'l blocks of mine (see above), the ad didn't play but Spotify wouldn't play either. Like it was waiting for an ad to play before resuming, but since the ad didn't play, neither did Spotify play resume.
The same here!!
re: above
[CAUTION]
After many plays on Spotify over a few-hour period w/no ads, an ad did eventually come through, but because of one or more of the add'l blocks of mine (see above), the ad didn't play but Spotify wouldn't play either. Like it was waiting for an ad to play before resuming, but since the ad didn't play, neither did Spotify play resume.
It's not working!! Definitely it is an issue.
Sure man, no problem. Hopefully will work fine at your end. Let us know.
-Anis
After firing up Spotify 1.1.34.694 yesterday on my test box, you're right. Spotify seems to have defeated these host blocks. Now, I'm getting a lot of connection requests from "gew1-accesspoint-x-xxxx.ap.spotify.com" (as well as "s3.amazonaws.com"). If I deny them, all the tracks are greyed out and the app doesn't work. If I accept these connections, the advertisements return. And they're no longer 5 second WalMart spots but full 30-second ads.
So, yeah. Unfortunately this approach is already obsolete it seems. I have my app locked to prevent upgrading, but it's back to square one as far as ad blocking.
When I paste all the entries to /etc/hosts and then starting to play with the app, about two and a half minutes after that Ads are popping up.
OS.: MacOS X High Sierra (Version 10.13.6) Spotify version: 1.1.25.259.g85cf5e4c
What is going on?????