Major I/O write bytes on the Spotify Desktop app. It will kill SSD drives in record time (fixed)

[MinionMan74]

**********************************************************
EDIT: According to Spotify this issue has been fixed in the 1.0.42 version so the case has been closed. Personally I have no more issues with this anymore on any computer. Thanks everyone for making this happen !!!

**********************************************************

original post:
Major disk write activity detected on the Windows/Mac app. Does not behave like that when using the browser player.

Please look into this thread, more details there:
https://community.spotify.com/t5/Desktop-Linux-Windows-Web-Player/Spotify-killing-my-SSD/m-p/1365378

Attached readouts from a Win7/64 PC during one hour and ten minutes. No offline playlist syncs and zero songs were played during that hour, only the spotify app tray active in background!

No disk drive, SSD or standard HDD can take that rate for a long period of time.

PLEASE ADDRESS THIS ISSUE ASAP OR BE THE NEXT SAMSUNG NOTE !!!

[nename0]

@ Arkanius

This will not fix writes to mercury.db, mercury.db-wal

And even if you also redirect them, the writes still occur. Also as described here You would also have to redirect the temp folder

Still it is most likely a bug.

[shirantrixi]

Hallo Maxk..,so wie du es sagst,wenn die Übersetzung richtig ist.

Den Cache "umgebogen" heißt das man Windows und auch Spotify anweist diese Cachedaten auf einem anderen Laufwerk zu schreiben. Appdata User\.....\Spotify\Cache..... nicht mehr auf C: sondern auf 😧 ..... schreiben!Entsprechender Ordner bei User...... umbenannt. Die Registry wurde deswegen auch geändert und im Spotify-Programm der neue Cachespeicher ausgewählt! Bei jedem Neustart,am nächsten Tag war der Umbenannte Ordner bei ...\User\.. wieder im Original vorhanden,obwohl er eigentlich auf dem LW C: NICHT mehr gebraucht wird, trotz Anweisung auf einem anderen LW zu schreiben. Moin,have a nice Day

[orson_welles]

@Arkanius Thank for the suggestion on a temporary loop-hole. This does not work for those who do not have the option of using a second hard drive, but may work for some people.

[TheSeven]

Sorry Arkanius, but this doesn't solve it. The files that are the problem here are mercury.db, mercury.db-wal and %temp%\etilqs_*

Each of them gets around 30% of the write traffic, so fixing the first two (which are easier to redirect) would already remove 60% of the SSD traffic, but wouldn't completely fix it either.

I'd appreciate if you could adjust your instructions to take that into account.

Also, people, please stop marking this thread as solved.

There are some half-working messy workarounds, but this isn't really solved at all.

[Arkanius]

i have edited my "solution" with your comment. thx for clarification

[TheSeven]

Thanks a lot.

Your instructions are still applicable, but you'd need to link the whole Spotify directory, not just the Data subdirectory, to catch those two database-related files as well. That would at least catch around 60% of the writes.

[Avanti]

if the solution from @Arkanius dont fix this problem, how can remove his solution?

[Avanti]

will a reinstall fix that?

[Arkanius]

I´v edited my tutorial to inlcuding the whole spotify folder.

[nename0]

How to debug/reproduce on windows using Proccess Monitor from Sysinternals:

The used filter is attached (Filter->Organize Filter... -> Import)

Start capturing

Then after some time (track switching...) you will see many read and writes on mercury.db, mercury.db-wal and %temp%\etilqs_*

(etilqs -> sqlite reversed). This is caused be the Sqlite command VACCUM (Docs).

So in conclusion spotify is calling VACCUM way to many times

SpotifyFileFilter.zip