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.
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.
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.
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'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 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.
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...
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.
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?
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.
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)
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.
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.
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.
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.
> 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.
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.
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.
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.
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.
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!"
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)
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
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)
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).
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?
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.
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.
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.
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!
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?
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?
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.
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.
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.
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.
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'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)
"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."
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.
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.
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.
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.
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...
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.
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:
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.
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.
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).
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.
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...)
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.
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.
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.
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 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.
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?
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