Spotify excessively writing to drive | Hacker News Reader

Spotify excessively writing to drive

community.spotify.com

439 pointsboernard256 comments

I had to go through a lot of comments in that thread to find a working workaround.

On OS X, Open /Applications/Spotify.app/Contents/MacOS/Spotify in a hex editor.

Search for "VACUUM;" Replace with "xxxxxx;"

On Windows, apparently the key "VACUUM;" string is in libcef.dll but I don't have a Windows system to see if editing it the same way provides a workaround like on OS X.

I used hexcurse from homebrew. After opening the file hit tab once to switch to the ASCII side, Control-F to search for VACUUM;, then type "x" six times to overwrite each character. Quit and save.

EDIT: fixes

6 or 7 x's? In your example, you used 6.

7 x's, one to overwrite all of VACUUM; including the terminating semicolon.

I didn't count the x's in the quoted text that I copied from the thread.

If you overwrite the ; is there not a risk you might cause the next legitimate sqlite operation to fail?

They might get lucky and overwrite the last SQL statement in the method. Seems likely with a statement like VACUUM.

6, it wont start otherwise. I left the ; in.

Hmm, I used 7 and my patched client is running fine. Maybe it's enough to garble VACUUM so it doesn't do anything valid.

If you replaced the ; also, you also didn't change the total length of the strings, I think that's what the problem is.

An explanation of what this does?

Also, I'm assuming this has to be done after every update, and since Spotify auto-updates, not so convenient...

I didn't read all of the original thread but apparently Spotify is overusing sqlite VACUUM, causing a modest amount of data to turn into a huge write volume.

https://sqlite.org/lang_vacuum.html

I'm more familiar with Postgres, but it basically instructs the table storage provider to clean up unused disk.

Think of it roughly as defragmentation. You're trading work (in the form of writes and CPU) for reclaimed space.

Unless SQLite has some semantics around it, replacing it with "xxxxxx;" will likely just cause it to run a bad command...might be more correct to replace it with something like "------;" (comment characters).

I was going to say "SELECT 1;" but it's two characters too many. Will all comment characters evaluate to whatever VACUUM does?

It likely just stops Spotify from VACUUM'ing the SQLite database it has.

Spotify stores a local SQLite database file (by default on a Mac it's at ~/Library/Application Support/Spotify/PersistentCache/mercury.db )

The file is only about ~100MB (on my computer). With databases, you issue a vacuum command to defragment a database (reclaim space from deleted/updated rows, re-sort the data, etc). SQLite's VACUUM behavior basically just recreates the entire database from scratch in a temp file, then replaces the live file with that[1]. It makes the file smaller and more efficient to run queries against. Spotify must be triggering a VACUUM statement too aggressively (possibly after every change), rather than on a periodic schedule or after a certain amount of fragmentation. By breaking the VACUUM statement with this solution, you prevent the database from getting recreated so frequently. The file itself will grow slowly (since you're not reclaiming free space like a VACUUM would) and possibly slow down queries against the database, but that sounds like a far better tradeoff than excessive wear on the drive from recreating the file so often.

[1]https://sqlite.org/lang_vacuum.html

Years ago, manually vacuuming the several SQLite databases that Firefox used (uses) was often cited as a way to speed up Firefox, meaning particularly an instance/profile that had been heavily used for some time. Not sure about these days, though the other week something had me in Bleachbit (IIRC) and I saw that doing so is still one of that application's selectable functions.

Once you apply that fix you can manually vacuum with

  sqlite3 mercury.db vacuum;

from https://sqlite.org/download.html

That sounds like an incredibly easy thing for Spotify to fix - how is this still an issue?

On the other hand it fits the picture: Their clients/apps on multiple platforms are very underwhelming. The abandoned rdio apps back from 2014 (or when did they close?) would offer a better experiment in almost any aspect.

Agreed.

  if (time_since_last_vacuum > 3600 /* seconds */) {
     go_hogwild_on_io();
  } else {
     be_nice();
  }

Yes, this is an incredibly easy fix. Perhaps it is me but sometimes it seems that nobody wants to write decent software anymore. I have seen software from giants like Cisco and BT that is abysmal.

It is disheartening to those of us who enjoy writing decent software, particularly decent native software.

I can't find the article right now, but I read a while ago that the Spotify client applications are modularized, such that different feature teams can push updates to their individual feature without breaking or being interdependent on other parts of the clients releasing in sync. I'm not sure what the mercury database is used for or if it's maintained by one of those "feature teams" or is part of the core lib, but that lack of central oversight (and responsibility) could be one reason why such an easy fix isn't so easy to get fixed.

Use <Control-F> to search and <Control-S> to save, it seems you mixed them up in your otherwise very helpful comment. What's the source of the problem and the fix, though?

Yep, mixed them up. See other comment about sqlite.

This fixes it, but it's likely any future update kills this temp fix. Hopefully Spotify will take care of this. I also noticed the extremely high writes less than a week ago. Wonder how long this has been going on.

Spotify updates itself fairly regularly, so you may need to reapply this fix from time to time.

Brute-force solution: save this as spotify-fixer.py, run it as cron job:

  #!/usr/bin/python

  target = "/Applications/Spotify.app/Contents/MacOS/Spotify"
  with open(target) as infile:
      bytes = infile.read()
  with open("./Spotify", "wb") as backup:
      backup.write(bytes)
  fixed = bytes.replace("VACUUM;", "xxxxxx;")
  with open (target, "wb") as outfile:
      outfile.write(fixed)

[retracted]

Thanks logicallee! I definitely need to be more judicious about time management, so I appreciated your comment!

dude. stop. the reason your username is "toomuchtodo" is shit like this. Just do it RIGHT NOW, or don't do it. It's not that important. Delete that stupid bookmark.

Just because something could be fun to do if you didn't have anythign else to do and were bored out of your mind, doesn't mean it's worth doing, ever.

Is the vitrol really necessary? How does what a complete stranger decides to do in their spare time affect you in any way shape or form?

I think it's more tough love than it is vitriol.

> I think it's more tough love

That's how I took it.

yeah

If you're on a Mac you have python already. Just save it somewhere and curl pipe it to python.

No No No, please do not encourage people to do this. Curl pipe is a horrible anti security pattern and you are encouraging people to be irresponsible with patching binaries from the internet.

The weird thing is talking about "curl pipe"ing into Python when you have a local copy? Wha?

The now-retracted comment talked about rewriting the Python into a shell script that you could toss on a web server and curl-pipe to run. I was pointing out that you can curl-pipe the original Python without rewriting it as shell.

If you do that, go the extra mile and schedule a (weekly or so) job to vacuum that database.

Also, since you are on a Mac, I would use launchd jobs and make it less brute-force by scheduling the job changing the file on writes to the Applications/Spotify.app/Contents/MacOS/ directory.

It's beyond me, why doesn't Spotify do exactly the same thing instead of overusing the VACUUM command.

On Ubuntu/Debian, it might make sense to run it after each apt-get:

    $ cat /usr/local/bin/spotify-turn-off-vacuum 
    #!/usr/bin/env python2
    target = "/usr/bin/spotify"
    with open(target) as infile:
        bytes = infile.read()
    with open(target+".bak", "wb") as backup:
        backup.write(bytes)
    fixed = bytes.replace("VACUUM;", "xxxxxx;")
    with open (target, "wb") as outfile:
        outfile.write(fixed)
    
    $ cat /etc/apt/apt.conf.d/99spotify-turn-off-vacuum
    DPkg::Post-Invoke {"/usr/local/bin/spotify-turn-off-vacuum";};

Hex Fiend is another hex editor for the Mac. Native and fast. http://ridiculousfish.com/hexfiend/

If you're looking for vi, but for binary, bvi does the job.

http://bvi.sourceforge.net/

Or use hexl-mode in Emacs

I'm pretty sure vi itself, or at least vim, is fine with binary files. You can run it as `vim -b` or `:set binary`.

I've always liked 0xED (http://www.suavetech.com/0xed/0xed.html)

Or do it with a one liner

perl -pi -e 's/VACUUM/xxxxxx/g' /Applications/Spotify.app/Contents/MacOS/Spotify

Hmmm, could it be an issue with Chromium Embedded Framework, give that it uses SQLite and it's in libcef.dll? I uninstalled Spotify from my MBA but I'm not sure whether the damage was already done...

Great fix. Only 1.7MB written in about 45 minutes.

iHex is an alternative (native) hex editor and it's in the Mac App Store https://itunes.apple.com/us/app/ihex-hex-editor/id909566003?...

That's a pretty cool fix. I wonder how they found that. This also highlights another issue with closed source software (and a few open source apps too): complete opaqueness. Yeah, hide the logging and status by default but at least give me a way to see what's actually going on. The Spotify Android app is worse. I wonder if it also suffers from this issue (I swapped to Apple Music after losing all of my offline tracks in Spotify again)

They probably just monitored what files the spotify client had open, or on Windows uses something like Process Monitor and monitored the program's activities. It would have seen a file open command pretty soon.

And once they saw it open the sqlite.db, all they needed to do was run sqlite3 on the command line against the DB file and see if there was history in the file.

It is possible that the Android client does the same as sqlite3 is the underlying database format for apps and is very easy to use.

How does this not break the signature on the binary and stop execution?

is Spotify signed at all? Anyway, worked for me (used '------;' with the python script above).

It's signed on my laptop.

Mine is signed. Maybe the HN crowd tends to have less restrictive GateKeeper settings since running unsigned stuff is kind of a pain in the ass.

Does anyone know why "xxxxxx;"? Seems like that would make an invalid call, so wouldn't it make more sense to replace it with some sort of no-op? Or is xxxxxx sql's way of doing a no-op?

Presumably it results in an error, but if the return value isn't checked then that's fine.

DO 0

SET @noop=0

NULL; -- works in pg at least

seem like good possibilities.

Because that breaks the statement, Spotify doesn't care if this particular statement succeeds or fails, and because it has the same length as "VACUUM;". Since this is being modified in a binary, you can't change the length of the string, or else you'll overwrite some other part of the data.

This patch also works fine on Spotify for Linux if you patch with ghex.

for Linux, it is at /usr/share/spotify/spotify.

I think it's pretty astounding that a customer complaint thread has run to 17 pages, direct contact on twitter, a HN story and customers going to such extreme lengths as editing their binary...

... and not one engagement from Spotify themselves on the thread. Seems like pretty poor customer support to me.

I've had a similar poor customer support.

They constantly kept redirecting me to their forums or to their FAQ's when my payment wasn't going through.

Finally I raised a support request and awaited their reply. That was a few months ago. Since I didn't hear back from them I gave my money to Google play music (even though I'm not a fan of the google play UI or the app).

How did you transfer all you saved songs, and playlists?

Also, how is music discovery there? Spotify is crazy good with their discover weekly feature.

The discover weekly is sponsored content.

EDIT I am interested are you downvoting because you (1) think I am wrong, or (2) don't like that it contains adverts, or (3) don't mind it containing adverts and think that this is irrelevant?

I found some content[1] on that, but I don't think it affects paying subscribers.

[1] http://www.adweek.com/news/technology/spotify-will-now-let-b...

Some of the playlist may be, but I'm pretty sure Elvis Costello, Paul Mccartney's Wings and Dâm-Funk don't need Spotify marketing.

I've used an iOS app called Stamp (paid for) to transfer my stuff to Apple Music. There is a desktop version as well.

Apple Music's discovery is awful (although I guess it doesn't know me as well as Spotify does)

I just spent 3 weeks talking in circles about their Android app and buggy Bluetooth support. Even after telling them that I'm a software engineer and explaining the technicalities of the bug that was happening, I still got referred to the "Bluetooth setup" section of their guides with a copy / paste email. After several more emails it ended in "we'll email you when we have more info".

I started my Google play music subscription two days ago. Their customer support beyond pre-recorded rhetoric is abysmal.

Apple musics is very friendly, though I haven't talked to them about technical issues.

The app, at least on Android, is very immature, though.

Has a better Asian selection than Spotify, at least.

Was it that Spotify (even if closed) hijacks bluetooth "play" from another audio application that is currently open and active?

That annoyed me to no end as well. I had to get another app to forcifully intercept any play call and trigger a pre-defined application instead. Which is... not optimal. I'm glad this thread is on HN, bugs with Spotify clients not getting fixed for months/years have annoyed me since I signed up in 2008.

I've had the opposite: Google Play Music (which I don't use) hijacks bluetooth "play" from Spotify - or at least it does every time I accidentally update Play Music.

And what is up with the issue? It's marked as "Closed" without any interaction from Spotify?

Was it closed as Fixed? Duplicate? Wontfix?

Apparently they have released new version with a fix to this issue. you should check whether it updates to 10.0.42

The Spotify desktop client had a bug where, every time you pressed "back", it would lose the scroll position on the previous page. It would show you the correct point, but when you tried to interact with it, it would jump back to the top of the page. It was incredibly frustrating if you were trying to browse through an artist's albums.

This is the kind of bug that should have been easily caught by automated regression testing. It wasn't. That should have been easily caught by a pre-release QA process. It wasn't. The kind that, if it it sneaked into a release, should have been triggered a rollback or a quick patch. It didn't.

Instead, they left this ugly bug in place for months. Despite dozens of complaints of their support forums, containing hundreds of posts. And throughout, I never saw a single official response from a Spotify employee. The only communication was hearsay through volunteer moderators, who said it was being "worked on", but with no suggestion of why it wasn't being fixed sooner, or when it actually would be.

Spotify push out updates to their client almost every few days, but it's clear their software development process is garbage, and that their developers are either unwilling, or unable to prioritise basic bug fixes. If I had to guess, I'd suggest that it's a combination of technical debt and bad processes inherited from their startup days, combined with a management focus on features that support monetisation goals rather than basic maintenance.

> If I had to guess, I'd suggest that it's a combination of technical debt and bad processes inherited from their startup days, combined with a management focus on features that support monetisation goals rather than basic maintenance.

I wish it was that. I'm not claiming to know, but AFAIR they've done at least two overhauls which I believe changed both dependencies, interface and logic, which suggests they had at least the opportunity to clean out any technical debt.

But for sure, something in the client development is broken. I remember reporting that bug too, as well as others.

If they did a big bang rewrite in a hurry they likely just swapped one kind of technical debt for another.

Each of their overhauls has been a massive failure. Spotify "1.0" didn't even have ctrl-f support for monthS!

> it's clear their software development process is garbage, and that their developers are either unwilling, or unable to prioritise basic bug fixes.

In my experience, when things are this bad, the prioritisation is being made outside of the development team. Working with a super buggy codebase is unpleasant, demoralising work. Developers don't do it by choice.

This issue has been driving me insane! I never went looking on the forums, assumed that my installation was buggy or something.

Just noticed, thanks to this comment, that it's FINALLY been fixed. Excellent

Agreed.

For a service I love dearly and have been using for 8 years, both their client applications and their support thereof has always been astoundingly lacking.

I've reported numerous bugs, and they almost always go unanswered for years, while some community elevated user will respond in a well-meaning but non-relevant answer, suggesting some run-of-the-mill IT tech solution, without any insight into the actual problem nor the Spotify tech.

I have rarely ever seen a Spotify rep taking client bugs seriously. Which is a shame.

But on that note: Has anyone tried Tomahawk? Or any other alternative client? I've been meaning to try something else but haven't gotten around to it.

The first reply on the top of that page is a classic

"Isn't installing Spotify in a regular HDD an option?"

Just completely ignore the problem and find a way to let you pretend it doesn't exist.

Haha!

I didn't even check, but that is indeed a very accurate synecdoche of their support forum at large. Good catch.

After reading this thread, I'm actually going to do just that. Not that I agree with the solution but it solves my issue at least

EDIT: Just tried to do so, and the spotify installer doesn't let you choose where to install.

A typical response here would be, "Have you tried just switching out your main hard drive to a non-SSD and making that the default install location? Good luck!"

You can set the location of the cache in advanced settings IIRC.

Thanks for pointing that out. Even ignoring the excessive writes, it'll be nice to have the cache take up space on my vast spinny drive rather than on my somewhat tight SSD.

The folder isn't as large as the IO usage makes it out to be. The entire PersistentCache directory is only ~104MB on my drive, even with >300GB written in the last few days

Good to know. I assumed it would not be dozens of GBs, but I assumed it might be one or two.

It is not the cache that causes the heavy IO. It is the SQLite DB at AppData\Local\Spotify\mercury.db AppData\Local\Spotify\mercury.db-wal

See http://blog.scaleprocess.net/spotify-heavy-io-problem/

Besides that, a lot of times setting a diff location for your cache does NOT move the cache. I had to use a symlink.

Also, they fixed this a couple months ago it seems. Page 22 of the comments in OP link.

I checked with some of my colleagues in work. My machine had 220GB written in 2 days. Another colleague had 300GB.

Go to Preferences -> Advanced Settings -> Change Cache Location

It's the VACUUM'ing of the SQLite database in that folder that's the problem. Moving that destination to your other drive should hopefully move the IO with it (I don't have a second drive to test with)

I think that often happens on support forums, because the power user volunteers trying to help others are too enthusiastic about the product. They have a deep bond to the product, that is strengthened by getting the (mental) reward of being recognized as an expert by answering a lot of questions on support forums. Therefore they will continue to use the product, even if it requires them to change their habits or to apply (costly) workarounds. Of course their answers will be written with this sentiment, so their suggestions might completely ignore the problem.

For Mac users: I wrote a bash script to create a Spotify app for you that is just electron wrapping the official Spotify web player. Just one command: https://jamesmcintyre.github.io/spotify-electron-client/

When the value your offering provides, which in Spotify's case is a ridiculous amount of music for a few bucks a month, most customers will forgive less than perfect software.

Obviously HN has a techie lean, and we dislike "bad" software but in the real world this matters little to 90+% of Spotify's customer base I'm sure.

+1, I've cancelled my subscription and moved to Play Music.

Probably at this point it's time to vote with the wallet and let them know why.

I am a participant in one 45+ page thread that has spanned two years (client failures when using the iOS app with CarPlay). Several participants have posted exact steps to reproduce, including model and firmware numbers and yet there was one response, two years ago, from Spotify, stating that they were aware of the issue and we should try version 3.X (we're on version 6.X now).

It's so frustrating and totally avoidable on their part (just a check-in saying "we're still not sure what the cause is but we are looking at it" would make such a difference)

This is a recurring, continuous pattern with Spotify. They don't care about artists, customers, or even record labels. Their dev process is awful. They never communicate. They push through awful UI redesigns (we just got one the other day, and it's just lots and lots of white space at the bottom of the page). Their customer support is terrible. AND they're screwing over artists who make less than a penny per play.

And despite all this, I am still using their service. None of the competitors have what I want/need.

Just checked on a Mac with 10 days uptime in Activity Monitor and Spotify has written 28.99GB and read 325MB. For comparison Chrome wrote 1.93GB, iCloud (cloudd) wrote 10.47GB, Mail 927.4 MB, and Slack 607.8MB.

10h uptime here and Activity Monitor is reporting 28.7GB written.

I forget how long it's been running, but mine reports 947.99GB written! Holy cow!

You can run `uptime` on both OS X and Linux to see how long a machine has been running.

The relevant figure here would be how long Spotify had been running, wouldn't it?

There's probably some way to get that info too, but of course I killed the app as soon as I saw what was going on, so it's too late!

Edit: uptime does give it a firm upper bound, at least. My current uptime is a bit over 12 days. So that's an average of 80GB/day at least, more if I started Spotify sometime after boot.

Can do it with

ps aux | grep ' /Applications/Spotify.app/Contents/MacOS/Spotify$' | awk '{print $9}'

Right you are. I'll keep that in mind for next time, thanks.

Vote this issue up if you have an account! https://community.spotify.com/t5/Ongoing-Issues/Major-I-O-wr...

I tried, but instead it told me I couldn't, and there's this message:

"We've seen some questions in our Community around the amount of written data using the Spotify client on desktop. These have been reviewed and any potential concerns have now been addressed in version 1.0.42, currently rolling out to all users."

So... sounds like it's fixed? If so, good job on making a fuss, everybody!

Yeah! Mine is 910GB and I only have a 256GB SSD. I guess that speaks to my uptime.

Uptime 36 days 112GB written, I listen music like 6h to 8h per weekday.

On a Mac I rebooted earlier today (a little under 4 hours uptime) and Spotify's showing 11.06 GB written in Activity Monitor. This is without having listened to anything at all today.

Similar story. 3-4 hour uptime, 9.6Gb written. Haven't listened to anything on it at all. That's nuts.

2 days and 179+GB written while only 1.21GB was read!! This is on my Mac - I wonder whats the number for my Windows PC at home.

For me it was 212.5GB over the past 4 days according to Process Monitor.

https://vgy.me/TbvxHh.png

5 days uptime, 310GB

I don't list to _that much_ music?!

39 days uptime (I know), 206GB written, 5GB read. Mac.

Up 9 days and it has written 440GB

12 days uptime, 367 GB written.

Mac here. 2d uptime. 54GB written. 255MB read.

Does spotify use daemon process on mac ? I had application installed but I didn't run it for a long time (ca 5 months). Is it possible that Spotify was silently writing massive data amounts to my drive without running Spotify application itself?

Interesting - seems like I'm the only one without this issue so far, so I thought I'd comment.

Spotify launched 10 days ago, 127MB written, 1.29GB read.

maybe relevant, I'm running Mavericks.

8 days uptime, 237GB written, 10GB read

Pretty heavy usage, though.

12GB written just opened couple of hours and haven't even listened to a single song :|

Funny enough for me it's right opposite. 6 days uptime, Chrome R 5.4GB/W 30GB (?!?!), launchd (R 643MB/W 24GB), kernel_task R 112MB/W 10GB, Cisco Jabber R 200MB/W 5GB.

Spotify R 100MB/W 400MB

What in blazes are the offending programs doing? If it were swap, then one should expect an 1:1 ratio between R and W, but that? Seriously?

Is that really a big problem? I mean most modern SSDs works fine until at least 600 TB which is like 16 years with that 100GB/day rate

>Errors didn't strike the Samsung 840 Series until after 300TB of writes, and it took over 700TB to induce the first failures. The fact that the 840 Pro exceeded 2.4PB is nothing short of amazing, even if that achievement is also kind of academic.

http://techreport.com/review/27909/the-ssd-endurance-experim...

I think the point here is that this is pointless process activity. Either a bug or something else. It's eating SSD write cycles, which is a finite resource, and providing very little if any benefit to the user.

And consuming IO, and consuming memory bandwidth, and consuming CPU cycles, and consuming battery. It is bad all around.

It is a bug, it should be fixed, it's unacceptable that it's taking so long. But tone of the discussion would be very different if this was simply "app is slow and drains battery". This is big news only because most people think Spotify will kill their SSD like by Christmas or earlier. When in fact it probably doesn't matter at all, because most computers get replaced due to natural causes in less than 8 years.

>This is big news only because most people think Spotify will kill their SSD like by Christmas or earlier. When in fact it probably doesn't matter at all, because most computers get replaced due to natural causes in less than 8 years.

From a test I've seen, SSDs can start showing issues at the 250TB mark. Wouldn't be a huge issue if Spotify were the only problem child, but remember when Firefox (and probably Chrome) were/are doing excessive SSD writes as well? And this past week, the League of Legends client was revealed to be too. If they all do 100GB per day like how Spotify does in this example, then your SSD could have issues after just under 2.5 years, which is nuts.

The above is a super rough estimate as Spotify usage will vary and how bad the League client and browsers are and how often people use those vary as well, but this could just be the beginning. What if Word decided to be SSD write heavy too? Or Adobe Reader? Or iTunes? Or whatever else it is people use.

16 years if that's the only thing writing to your SSD. Imagine if every piece of software did this, that is why it needs to be kept in check.

A few days (or a couple of weeks perhaps) ago there were similar posts about Chrome and Firefox, but in the browsers it was related to writing the metadata to reopen every tab and sesion back when you restarted the browser.

Firefox comes pre-configured with a time of 15 seconds intervals, that is, every 15 seconds it writes a few KBs of data just to reopen your session, no matter what' activity you're doing with the browser (or if doing nothing at all). At the end of the day it ammounts to a few GB's in writes, depending on your browsers usage.

So it's not crazy/paranoid/weird to asume that this is becoming more or less "standard" behaviour.

Wait, do you mean a few kb 4 times/minute (5760 times/day) which would be a few MB if you write kbs, or do you mean GBs per day? I don't understand...

IIRC "a few" == from 100KB to 1MB, which sums up to a few gigs.

Disk writes are not free from the point of view of the battery, either. Something with a much lower cycle lifetime.

Yes, it's a problem. This is shoddy craftsmanship and shouldn't be acceptable to anyone.

It simply doesn't matter that SSDs will be ok. It's being wasteful of system resources. Software should not waste system resources.

This kind of "shoddy craftsmanship" has been the accepted way to produce software for a very long time, and the effects have until recently been hidden by Moore's Law. Wasted resources didn't matter because everyone with money to spend would throw away their old machines and buy new, faster ones. People working at the extremes -- data centers and mobile phones -- have to actually think about resource use; maybe this will make its way toward the center.

I'm not sure. On older machines it was more obvious where shoddy craftsmanship was as you had less resources to use. Now it is hidden a bit more but I never ever accepted it as the "accepted way" to produce software.

Others might have, but I don't think it was ever encouraged to write daft loops or short timers to write data.

It is interesting that the styles of writing code (eg doing dynamic casts at runtime a lot) has real impacts on performance and speed. Stroustrup wrote an interesting paper (must find it) where he encouraged static code generation rather than runtime dynamic checks all the time. It means we have to think a bit harder when designing software and writing it, but it is worth it for all our sakes (less CPU time to do the same thing, less power used etc)

I hope you don't work for an online publisher/advertiser. The amount of waste their software generates is absolutely staggering.

Yesterday I was working from home and trying to compile our codebase was taking an excessive amount of time. Still have a spinner in my home computer so I heard it working really hard even after I stopped the compile and noticed spotify slamming disk I/O. Killed it and everything went smoothly. So yes it can actually matter quite a bit.

Spotify clogs the write queue on my workstation (w/ssd), giving me 2 second freezes every 5mins or so. I don't know if it's this bug, but the disk write numbers and database file match, and the only remedy is exiting Spotify.

I only used web based Spotify https://play.spotify.com/

You can block all ads with uBlock Origin too.

I can't find a reason to download the application now.

Well the application doesn't require flash.

I'd better Flash than new SSD.

With Adobe Flash installed it's only a matter of time before a new plugin exploit allows your SSD to be reformatted/flashed.

Click to activate solves this problem fairly well.

Chrome and Edge have Flash built in. Problem solved.

A good reason would be if you have a Premium account and want to listen to something better than 128kbps MP3s.

I am also an audiophile but I would wager that most regular people could not tell the difference anyway.

I'd wager those self-proclaimed audiophiles can't either, or maybe just. My dad is one of those and it's all imagination. Give him a song he doesn't know yet and he can't tell whether you're playing the flac or 192k mp3 version. 128k seems audible if you're looking for it on good hardware.

Flac is used for storing music and then encoding to a format that is more suitable for playback.

Well a well mixed record does way more good than lossless vs. 192k, but I definitely hear it.

It depends a lot on the record, but on a gorillaz track ("feel good inc") I could hear it very well.

Ironically the tracks quality on spotify is quite bad, because the label provided crap to them.

edit: reply from the support was:

    ~320 kbps (only available to Premium subscribers) [...]

    Also, we only make the music available in whatever form it’s given to us by the artists or labels.

edit: good abx test for spotify standard quality: http://abx.digitalfeed.net/spotify.html

I now did the test and failed :) (the one vs 192kbs

I wonder though, if I would hear it for the kind of music I listen too (more technoid or classic). James Blake was the closest sample, but rather easy on the codec I guess.

Here (James Blake and alike) much producing goes in to making things sound "punchy", so you limit the frequency range of most things to keep a clear sound (e.g. a high cymbal will be stripped of possible lower frequencies) and you do tricks like cross-chaining: when the base drum hits you turn the volume of the rest of the track down. And than loads of compression, making silent parts louder.

> ~320 kbps (only available to Premium subscribers)

Yeah if it were up to me they should get rid of the free tier altogether. It's basically people living off the back of paid users, which I am one of, and not wanting to compensate artists. They might as well be using the pirate bay.

Well there is still advertisements. I once read facebook make 12$/Year/ActiveUser or something? Surprisingly much! (though if there was the option and I didn't have fb so much I'd happily pay that)

Seems they rolled out a fix now:

https://community.spotify.com/t5/Ongoing-Issues/Major-I-O-wr...

I have this version: so far looks better around 200MB written while listening for cca 30 minutes.

I really hope they've fixed this.

This is pretty interesting. Should software that destroy someone's physical items be handled the same way as hardware destroying something physical (Samsung Note 7 for an exaggerated example).

The software in not "destroying" the SSD. It is using it properly, but excessively.

well yes, my comment was more hypothetical relating to this story (though it will wear out your SSD quicker).

In the terms of lets say something cause your SSD to burn out within a year, with a known bug. I feel the company the software bug should be held responsible.

This reminds me when Dell refused warranty repairs if VLC was installed[1]

Turns out that you could increase the volume causing hard clipping, which caused physical problems on the speakers.

[1] http://en.community.dell.com/support-forums/laptop/f/3517/t/...

That was a dell issue, though, and had nothing to do with VLC. See the following comment by jbk (VLC lead): https://news.ycombinator.com/item?id=7205875

Back in the HDD age, you had to optimize applications for sequential I/O and minimize disk seeks. When you tested your software, you could audibly hear the HDD grinding away with seeks. With an SSD there's no feedback like slow loading or seek sounds to indicate you have bad I/O patterns or are constantly writing to the drive. This certainly isn't the first case of an app going crazy with writes.

A great testing tool would be to induce latency on seeks or keeps track of writes / fake disk seek sounds to avoid these kinds of problems going undetected during development.

And failing that, LED indicators, which you could have on your case.

Maybe someone can program a Mac's camera light indicator to blink when the SSD is writing?

I recall reading that the light is directly coupled to the camera recording so bad actors can't use it while the user is unaware. But if you have to turn the camera on and off and you have the lens covered that's probably not too bad.

Spotify's Mac app also gobbles up memory. I regularly see it consuming more than a gigabyte. As someone who's still running an 8GB machine, that bytes.

I've not noticed Spotify to be particular bad for this, but I've noticed slack is awful for this.

Yeah especially the latest version of Slack - it helps if you remove any unnecessary teams.

I can't multitask with firefox on android

Yeah I'll occasionally switch to music on my phone if I'm doing a lot of memory intensive tasks. Having Spotify and Chrome open is like a RAM kiss of death.

I'm sorry, but this has been reported since 5 months ago. How on Earth has this not been officially fixed by Spotify? Same problem here. What a joke.

I would suggest tweeting at @spotifycares with #stopkillingourssds :D:D https://twitter.com/MariusKubilius/status/796621559129657344

Your suggestion is good, but their reply is a little underwhelming. I didn't expect their customer service to be of this caliber.

Still beter than Google or Apple.

They reacted to the mess on the community forums and just rolled out fix with version 10.0.42

Oh? Where do you see this? I'm already on version 10.0.42 and I still see ridiculous writes to disk.

For me it fixed, Though I needed to wait for few days for update to become available.

Looks like he got a response. I sent them a DM as well.

I had heard Spotify uses P2P quite a bit.

People on this forum are reporting that its eating up 50GB's on idle. Could it be possible they are using idle clients to help stream content to other users?

Okay but streaming content is a read operation, not write.

Not if they have your computer get content to serve, perhaps based on popularity.

They could be "pushing" the most popular content to those clients for the others benefit even if you never listen to it.

It looks like most of it is being written to a SQLite DB, so probably not.

Based on quick glance to the thread, somebody has pin pointed the problem to embedded SQLite database vacuum operation. That is optimizing the storage of database and maybe it is being called too often.

isn't the vacuum operation's job to reduce database size by removing free space and defragment the data?

edit: ok, I got the answer by myself: apparently, Vacuum copies the database to a temporary file and then it overwrite the original, it's not the usage, it's the writes that are the problem here.

Spotify has a few nifty features that must be using a fair bit of bandwidth. Features such as the ability to remote control another instance means maintaining a control channel. The ability to switch music to your local device means all devices must stream the song, as though it were playing on that device, to allow immediate switching.

These work quite well for the user, as it's enjoyable to listen to music on your stereo at home, then just tell the phone app to switch from your stereo to your phone (maybe over headphones) while you're mobile. And heavy use of P2P between devices on the same LAN or Wifi network would reduce internet bandwidth use, but may unintentionally cause a lot of churn and disk use.

Spotify doesn't forward the stream. When you tell it to play with another device that's running Spotify, it simply instructs that device to play the stream; unlike AirPlay it doesn't send the music to that device.

I can attest to this.

Playing a song from a phone 'pushing' to a device on a slow connection always causes troubles for me.

They have stopped using P2P for some time now.

https://techcrunch.com/2014/04/17/spotify-removes-peer-to-pe...

Spotify used to be P2P, several years ago. These days it streams directly from Spotify's cloud servers (or technically Google's).

Serious question - how are you able to modify an application binary and not have the OS refuse to run it?

Is spotify shipping an unsigned binary?

Does OSX actually check signatures anytime after installation ? If yes, how do auto-updates work, do they update the signature every time?

If signatures are checked, they are checked by the kernel (and its userland buddy AMFI) every time the process is launched. I'm not sure what the defaults are for macOS lately but a developer can opt-in to even more restrictions like requiring linked shared libraries to be signed with the same key pair as the executable. This library validation behavior changed in 10.12 and can now also prohibit mprotect(RWX). I'm fuzzy on the exact details of the {OS version, compiler version [yes, 10.12 changes codesign validation behavior based off of the version of the compiler, not the OS, used to build the binary], codesign requirements} mix but it is increasingly becoming more like iOS. Apple has spent the last decade developing a pretty impressive* chain of trust for code execution, starting with iOS and merging into macOS.

Basically, code signing on iOS is dynamically secure, modulo vulnerabilities, and macOS is steadily on its way to become more like iOS in this regard.

* But not fun for security research and having ultimate control of your device. Always the tradeoffs...

http://www.newosxbook.com/articles/CodeSigning.pdf

https://developer.apple.com/library/content/technotes/tn2206...

App signature checks aren't required to succeed on macOS -- the user has the ability to override it globally in System Preferences, or add an exception using the right-click menu.

Good !

Finally this is taken to a level where Spotify might actually notice something !

There were/are threads on their forum and basically nothing happens as they seems to not care for the users.

To those who start with the comments: this is about Spotify the application, not Spotify the company. Big difference:)

Good tip, I also thought this was about some kind of SSD reliability testing done by their engineers.

Well, it sort of is. Though not intentional.

How else could it be interpreted?

I have no idea so I'm guessing the title was edited after this comment.

It was. It used to be something like "Spotify killing SSDs by writing hundreds of GBs to them". It almost made it sound like performance testing.

Wow. I'm a Spotify on Linux user and I've been trying to track down this issue for months. System Load Indicator showed huge write spikes, but they were brief enough that I hadn't yet caught the culprit red-handed in iotop. They bring I/O to a crawl for a second or two though.

Look what I found with a `cat /proc/$pid/io` on the main spotify process:

    rchar: 315169616727
    wchar: 236191291851
    syscr: 320352243
    syscw: 330963886
    read_bytes: 945213440
    write_bytes: 230711586816
    cancelled_write_bytes: 51481772032

That's 230GB written over 6 days of uptime. Granted, some of that is to the network, to an audio device, or just normal download caching. Still...good grief.

Same here.

I had the gut feeling something had been wrong with the Linux client for a while. Spotify also tends to show up pretty high in h/top, aside from iotop.

8 days uptime and Spotify has written 272GB

Ha! I have had this problem for months (OSX) and never looked at Spotify. In the past few days it has written 22GB already, every few weeks I run out of disk space and never had a clue why, restarting would reclaim it.

This should not be the reason why you run out of space. Might be memory swapping that gets released on reboot, or it's because Photoshop is closed when shutting down (scratch disk).

Never use Photoshop. Most of the time when I look at activity, it's just "kernel_service" doing the writing.

Yeah should be memory swapping then. A RAM upgrade (if possible) would eliminate most, but not all, of that. I'm quite fed up with Apple about the 16GB RAM limit for that reason.

This bug generates disk activity but does not actually leave files around, so it's not your issue I'm afraid.

Actually, with regard to the other comments, this could very well be the reason the parent runs out of disk space due to OSX's swap files/sleep image (I think it's fixed in the more recent versions).

I wonder if they are also aggressively vacuuming the sqlite db on mobile devices too.

The spotify desktop app is really shoddy, i've had problems with the 'spotify helper' process on osx draining cpu/battery and causing the fan to start, had to write a script to kill it if it's using over 90% cpu. There are posts on their support forum about that issue going back four + years so I wouldn't expect this to get fixed any time soon.

Is there a way to measure Spotify write activity on my Android phone?

Yes, I'm interested to know if this behavior happens on the phone. Given the space constrains on phones, I think they wouldn't dare.

While this bug is writing a lot of data, it doesn't mean it will actually use a lot of data at one time.

From other comments, it sounds like it is defragmenting a database file which is normally only a few hundred MB max. However, defragmenting this file means it essentially writes a duplicate of that file, switches over to the new file, and deletes the old one. So, it uses a lot of writes, but its writing the same couple hundred MB over and over again, with the total usage only being 2X the max size of the file, assuming no fragmentation. If there is a lot of fragmentation, that multiplier would be less than 2.

So, as asked in another comment here but not answered, does anyone know whether or not this affects the phone apps?

I haven' noticed crazy battery burn on my Nexus 5x, but then I don't actively use Spotify much (meaning I should probably cancel it now that the trial period is over, anyway...)

15 days uptime on mac. 1TB written

12 days 1.13 TB. OMG! I had no idea. I wonder if this explains the random slowdowns I've had.

wouldn't overwriting VACUUM; with --CUUM; be less invasive?

The last good Spotify client version was 0.8.5. I still use it. This was a proper desktop app, with the interface built with Qt and Linux integration (MPRIS D-Bus Interface).

Todays Spotify desktop client is nothing more than another web browser, which uses WebKit to render all its interface as a web page inside the app window.

Hmmm, I found running Spotify on macOS makes the battery drain faster as well. If you compare it with iTunes running Apple Music, the difference in battery life is quite huge.

Spotify is built around Chromium Embedded Framework, with IIRC a separate browser instance for each UI frame.

Given Chrome's battery and RAM usage, it's not surprising that Spotify performs poorly even compared to iTunes.

What was the decision behind this? Why not to develop a native app (swift or objective-c), that would be better optimized and would perform better?

Isn't there enough evidence that wrapped web apps like Slack or Atom (and now Spotify) perform worse than the native apps?

It's easier.

Multi-platform at the lowest cost.

Already posted a few days ago:

https://news.ycombinator.com/item?id=12833647

Luckily I never experienced any of the issues here, but after reading all the comments I just decided to give Google Play Music a go. They even offer a 30 days free trial period.

Even better, Google Play music seems to support my current country. With Spotify I had to use an old credit card which was from the time I was living in Czech Republic.

The iOS app has a mercury.db in the container’s Library/Application Support/PersistentCache/mercury.db but the app in Spotify.app/Spotify doesn’t seem to contain VACUUM - or any string really. But I’m not familiar with arm64 Mach-O binaries.

I've seen this with an enterprise application. It was just a data pipeline and never needed much storage but it sure was a writeaholic. Workaround was to mount a ramdisk for the working set.

Not a spotify user, cannot say this is viable solution.

Has anyone tried comparing this against the Spotify web app (https://play.spotify.com/)? That might be another temporary solution.

15 days of uptime and Spotify wrote alone 620 GB (Total 1,07 TB). RiP my SSD...

It seems this is not fixed in 1.0.42, released today.

I'm running 1.0.42.151.g19de0aa6 on Ubuntu and I'm seeing 351 MB written to disk in under 15 minutes without listening to any music at all.

I'm using 1.0.42.151.g19de0aa6 on macOS, and I see the difference. after 1hr of playing I only see ~100MB of data written by Spotify.

I had my spotify cache on a btrfs SSD with CoW enabled until a few minutes ago.

Fuck me.

On a Windows 10 machine, deleting the data folder seems to have fixed the issue: rm -rf C:\Users\{username}\AppData\Local\Spotify

Note: Spotify will recreate the folder with a normal amount of writes.

Are there any viable alternatives to Spotify?

Google play music and Apple music are IMO viable alternatives, in some cases depending on what devices you use. Available music is comparable, price is equivalent (and google music includes youtube red as well).

https://www.deezer.com/

Lots. Google Play Music. Apple Music. Amazon Music Unlimted. Or this massive list: https://en.wikipedia.org/wiki/Comparison_of_on-demand_stream...

I just moved from Spotify to Apple - the Android app is good, but doesn't respond to all music intents, doesn't broadcast music info (so no Scrobbling) and downloading playlists for offline use doesn't seem to stick like Spotify did, where new tracks added to playlists would be automagically downloaded.

Torrent.

Pandora supposed to be launching one sometime next year. They bought the remains of Rdio, who used to have a good client.

Rdio had a great client. I'd switch back in a heartbeat if Pandora re-released it. It was light years better than Spotify.

I used Google Play for years, switched to Tidal for a short while and now listening only my own music. I have enough music for years, I can listen anything I want and the artists are getting a better deal when I purchase their albums. And I can have my music in any format and in any quality. My music follows me automatically from home NAS to work to mobile.

I occasionally find the client from the arch linux aur repos pegging a CPU core as well. bad syseng :(

I run Spotify with cpulimit, when they used to have lyrics your machine would barely function if you didn't.

Just use web version with uBlock and you have add-free spotify account without this ugly bug.

This is what happens when you put 600 hipster developers in the same office

They just rolled out v. 10.0.42 which according to them addresses the issue.

I assume this is related to DRM keys changing? Either way it's ridiculous.

I sadly feel a bit lost without it , please give me back my music :D

How to check whether this is happening to me on linux?

Now I'm glad that I don't use Spotify anymore!

This is a fucking joke, unless you're a time traveller 100GB/day isn't going to wear out your SSDs. Most modern SSDs can easily hit petabytes, and this would be fine even if they could only hit a quarter of that. 1PB at 100GB a day would take 27 years.

This is an interesting assertion. Can you cite it?

It's sucking up your battery doing useless things. It's a bug they apparently missed or don't care about. It should be fixed.

The title was "Spotify wears out SSDs by writing 100GB/day", which is a ridiculous exaggeration. That's the only thing I was commenting on.

It may not wear out your drive, but it will waste power and take up CPU time and I/O bandwidth unnecessarily!

It's obviously an unintentional bug and one that is easy to fix. Why do you say that it's fine that the bug wasn't fixed yet? Would you think the same if every desktop application wrote 100GB per day to your SSD?

Reply on news.ycombinator.com