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?
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.
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.
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.
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!
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.
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?
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.
vs
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?
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.
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.
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)
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.
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.
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).
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.
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.
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.
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?
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.
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)
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.
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 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.
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...
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.
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?
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.
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 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).
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.
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).
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.
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.
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.
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.
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.
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?
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).
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.
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).
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'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.
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.
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.
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.
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.
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.
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)
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.
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.
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.
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...)
263 comments
[ 4.6 ms ] story [ 242 ms ] threadPeople 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?
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.
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.
Playing a song from a phone 'pushing' to a device on a slow connection always causes troubles for me.
https://techcrunch.com/2014/04/17/spotify-removes-peer-to-pe...
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.
ps aux | grep ' /Applications/Spotify.app/Contents/MacOS/Spotify$' | awk '{print $9}'
"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!
https://vgy.me/TbvxHh.png
I don't list to _that much_ music?!
Spotify launched 10 days ago, 127MB written, 1.29GB read.
maybe relevant, I'm running Mavericks.
Pretty heavy usage, though.
vs
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?
You can block all ads with uBlock Origin too.
I can't find a reason to download the application now.
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:
edit: good abx test for spotify standard quality: http://abx.digitalfeed.net/spotify.htmlI 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.
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.
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
I didn't count the x's in the quoted text that I copied from the thread.
Also, I'm assuming this has to be done after every update, and since Spotify auto-updates, not so convenient...
https://sqlite.org/lang_vacuum.html
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).
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
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.
It is disheartening to those of us who enjoy writing decent software, particularly decent native software.
Thanks logicallee! I definitely need to be more judicious about time management, so I appreciated your comment!
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.
That's how I took it.
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.
http://bvi.sourceforge.net/
perl -pi -e 's/VACUUM/xxxxxx/g' /Applications/Spotify.app/Contents/MacOS/Spotify
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.
or
SET @noop=0
or
NULL; -- works in pg at least
seem like good possibilities.
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.
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/...
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.
Not a spotify user, cannot say this is viable solution.
Given Chrome's battery and RAM usage, it's not surprising that Spotify performs poorly even compared to iTunes.
Isn't there enough evidence that wrapped web apps like Slack or Atom (and now Spotify) perform worse than the native apps?
>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...
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.
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.
It simply doesn't matter that SSDs will be ok. It's being wasteful of system resources. Software should not waste system resources.
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)
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.
Maybe someone can program a Mac's camera light indicator to blink when the SSD is writing?
https://news.ycombinator.com/item?id=12833647
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.
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...)