A Spotify bug thrashed subscribers' drives for the past five months

Originally published at: http://boingboing.net/2016/11/11/a-spotify-bug-thrashed-subscri.html


If they can manage to burn 10+GB/hr of database operations just keeping track of a few playlists, I shudder to think of what these heroes of software excellence would do to a problem that involves actual, nontrivial, database use.


So many dead SSD. Was this also network activity?

I wonder how much heat they created, increasing global climate change?

Spotify killed us all!


Firefox and Chrome have a similar problem. Firefox can write 24 GB every day, but there’s a fix:

If you use an SSD and Firefox or Chrome, you definitely want to cut down on the excessive writing.


Hmm. On my OSX box, according to Activity Monitor, Firefox has written 8 GB in the last few days since I last launched it, while something called kerneltask has written 333 GB. Granted, I’ve only opened a handful of tabs in FF (I do my main web-spelunking in Safari (only 2 GB in whatever the time interval is)), but whatever kerneltask is doing looks more threatening to my SSD.

1 Like


Check out this ars technica comment

Holy shit. I just checked, and Task Manager says Spotify has written over 1TB in the past 15 days. I’ve played maybe 5 songs on this computer during that time.

I’m shutting it off now, and it’s not coming back till this is fixed.


sudo kill -9 0


I have no idea what that means, but the ‘kill’ doesn’t look good.

1 Like

I didn’t see it (sorry if I missed it) but is this just the Spotify App or is it streaming Spotify using the web player?

1 Like

My new band name. :slight_smile:


I’m sure it was more than 5 months ago when I noticed it was really sloppy. I was checking to see why I had so little disk space left on my old PC and Spotify’s temp/cache directory was the 3rd largest thing on my drive after a directory of large VM virtual disks and a big directory of videos. I deleted it all but it came back so I made a script that ran daily, cleaning up Spotify’s mess. Eventually I realized I didn’t use it that much anyway, so I uninstalled and deleted it. I didn’t realize how much/often it was writing though, just that you could store an entire collection of MP3s in the space it needed to stream one.

1 Like

Kill always kills! Keep eyes out to accept updates kill -72, which takes tasks out hiking. kill -40 is more severe and justs tests app behavior at the edges of comfort.
I tried renicing (+3 of what I thought would be 20) Firefox and it ended up taking more CPU and getting in fights. Gotta audit backports…
I was thinking “Spotify, that’s not how Rowhammer works!”


Thanks! I’m a casual, though; it says in your link that the session restore interval is 15 seconds by default. when I opened about:config and found the parameter, it has the value shown as 15000. so that would make a minute 60000? if I want to change the interval to, say, 5 minutes, I need to re-write the value to 5(60000)=300000? Am I getting it?

1 Like

An eye for /profiles/{whatevs}/sessionstore-backup/sessionrestore.js (and relevant about:config lines) there. Also to whatever ad network is trying to build brownstones up and down your cookies folder in the process of determining whether you’re looking at the ad in the background window (spoiler: No. Not.) Thanks. servethehome.com, eh?


That’s it exactly.

1 Like

oh good. I didn’t want to goof it.

thanks, buddy!

I wonder if they have a QA department?
Actually, being ex-QA and knowing startups, I pretty much assume they don’t.


I wonder if anyone bothered to report this at https://bugzilla.mozilla.org as a bug?

But, yeah, if you set your sessionretore interval to less, it may cause you to lose more information in a crash. That said, I rarely crash.


Yes, it’s been reported:

And here’s more discussion:

1 Like

Ah, Gian-Carlo reported it. Ok.