
Spotify excessively writing to drive - boernard
https://community.spotify.com/t5/Desktop-Linux-Windows-Web-Player/Spotify-excessively-writing-to-drive-in-my-case-an-SSD/td-p/1365378/highlight/true
======
philipkglass
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

~~~
joemi
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?

~~~
CGamesPlay
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.

------
phab
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.

~~~
stupidcar
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.

~~~
croon
> 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.

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

------
0xCMP
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.

~~~
JonathonW
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.

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

------
bdz
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...](http://techreport.com/review/27909/the-ssd-endurance-experiment-
theyre-all-dead/4)

~~~
JustSomeNobody
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.

~~~
username223
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.

~~~
72deluxe
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)

------
technojunkie
I only used web based Spotify
[https://play.spotify.com/](https://play.spotify.com/)

You can block all ads with uBlock Origin too.

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

~~~
toomanybeersies
Well the application doesn't require flash.

~~~
ar15saveslives
I'd better Flash than new SSD.

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

~~~
angry-hacker
Click to activate solves this problem fairly well.

------
cjg_
Seems they rolled out a fix now:

"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."

[https://community.spotify.com/t5/Ongoing-Issues/Major-I-O-
wr...](https://community.spotify.com/t5/Ongoing-Issues/Major-I-O-write-bytes-
on-the-Spotify-Desktop-app-It-will-kill/idc-p/1493699/highlight/true#M25856)

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

I really hope they've fixed this.

------
Spooks
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).

~~~
martin-adams
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/...](http://en.community.dell.com/support-
forums/laptop/f/3517/t/19492918)

~~~
lorenzhs
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](https://news.ycombinator.com/item?id=7205875)

------
r1ch
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.

~~~
Scoundreller
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?

~~~
brazzledazzle
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.

------
luhn
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.

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

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

------
developer2
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.

------
mk3
I would suggest tweeting at @spotifycares with #stopkillingourssds :D:D
[https://twitter.com/MariusKubilius/status/796621559129657344](https://twitter.com/MariusKubilius/status/796621559129657344)

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

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

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

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

------
subie
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?

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

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

------
45h34jh53k4j
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?

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

~~~
jevinskie
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](http://www.newosxbook.com/articles/CodeSigning.pdf)

[https://developer.apple.com/library/content/technotes/tn2206...](https://developer.apple.com/library/content/technotes/tn2206/_index.html)

------
potrebitel
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.

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

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

~~~
Xylakant
Well, it sort of is. Though not intentional.

------
sigil
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.

~~~
bassman9000
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.

------
Dramatize
8 days uptime and Spotify has written 272GB

------
ricardobeat
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.

~~~
manmal
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).

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

~~~
manmal
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.

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

------
eunice
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.

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

~~~
sumitgt
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.

~~~
vel0city
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.

------
pasbesoin
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...)

------
ddrmaxgt37
15 days uptime on mac. 1TB written

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

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

------
piotrjurkiewicz
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.

------
neurostimulant
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.

~~~
wlesieutre
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.

~~~
justanton
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?

~~~
exadeci
Multi-platform at the lowest cost.

------
teh_klev
Already posted a few days ago:

[https://news.ycombinator.com/item?id=12833647](https://news.ycombinator.com/item?id=12833647)

------
crypt1d
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.

------
stereo
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.

------
inopinatus
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.

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

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

------
glastra
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.

~~~
bigfunlx
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.

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

Fuck me.

------
babak_ap
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.

------
ilaksh
Are there any viable alternatives to Spotify?

~~~
LeoPanthera
Lots. Google Play Music. Apple Music. Amazon Music Unlimted. Or this massive
list: [https://en.wikipedia.org/wiki/Comparison_of_on-
demand_stream...](https://en.wikipedia.org/wiki/Comparison_of_on-
demand_streaming_music_services)

~~~
voltagex_
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.

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

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

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

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

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

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

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

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

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

------
ryanlol
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.

~~~
coldcode
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.

~~~
ryanlol
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.

