Maybe these are test accounts/artists created/used by Spotify developers? I don't know much about their culture but if there was an actual attack with actual consequences and these accounts were removed as a result, they would've said something.
Mystery tracks being 'forced' on your Spotify
61–65 of 65 posts
Re: Mystery tracks being 'forced' on your Spotify
#62Earlier quoted context omitted.
I wouldn't be afraid of the Discover Weekly playlist. I think it's Spotify's best feature. For me, it surfaces great songs & artists I hadn't heard before, and sometimes it's almost spookily accurate. For Discover Weekly to work though, it helps to feed it good data. It's based on a PageRank-like system, but instead of webpages it's based on user playlists [1]. If you create some of your own playlists, it will go and…
You should share that goth/industrial list too, I love that stuff.
Seems I'd accidentally made the goth nightclub playlist public anyway - here's the link, though it isn't as well maintained as the other playlist:
https://open.spotify.com/user/syneryder/playlist/3AOszFh3njR...
Re: Mystery tracks being 'forced' on your Spotify
#63Earlier quoted context omitted.
Goodness me, no. They could be fetching all values for a given key (for performance reasons, since the seek for a read is surprisingly expensive). Depending on how they then use that data, these short and plentiful tracks can end up being included instead of dropped.
Sorry if I'm being obtuse but why would they be using a hash as a key instead of a uuid? I've never heard of any distributed system (or any system) that use hash as a key. Or are you saying there is somekind of auxiliary hash table in use for performance somewhere?
Is it not fair to say that git is a distributed system using a hash as a key?
Re: Mystery tracks being 'forced' on your Spotify
#64Earlier quoted context omitted.
Sorry if I'm being obtuse but why would they be using a hash as a key instead of a uuid? I've never heard of any distributed system (or any system) that use hash as a key. Or are you saying there is somekind of auxiliary hash table in use for performance somewhere?
Is it not fair to say that git is a distributed system using a hash as a key?
I suppose it is. Though it's not the sort of systems I meant in my reply. Never even crossed my mind. P2P networks (like torrents) could probably also count as ones.
Re: Mystery tracks being 'forced' on your Spotify
#65Earlier quoted context omitted.
Goodness me, no. They could be fetching all values for a given key (for performance reasons, since the seek for a read is surprisingly expensive). Depending on how they then use that data, these short and plentiful tracks can end up being included instead of dropped.
Sorry if I'm being obtuse but why would they be using a hash as a key instead of a uuid? I've never heard of any distributed system (or any system) that use hash as a key. Or are you saying there is somekind of auxiliary hash table in use for performance somewhere?
Git was already mentioned as an example, but there is a more generic answer to your question. Look up https://en.wikipedia.org/wiki/Content-addressable_storage ; the design is basically a DHT. Key collisions are standard feature in any hash table.
In any hash table, collisions are unavoidable. In a distributed KV store, the collision resolution might be done at a higher level, so any lookup reads all the values for a given key. The reason is simple: opportunistic caching. Sometimes you get lucky and are asked for two or more items that hash to the same key within cache expiration window. If you can avoid a read just 0.1% of the time, that's an improvement on tail latency AND it just left capacity available for other clients to do their reads.
We are all aware Spotify stores a lot of media. I know nothing about their internal architecture, but they might use hash of the track metadata as its content key. If assumptions (or "happy optimisations") about their size distribution don't hold, some extra tracks could end up getting through.