Reduce amount of writes to SD-card (to protect it from wearing out)

[d1vzero]

First of all, thanks a lot for the excellent work!

I am using raspotify since years on a raspberryPi. Recently on my pi3 my SD-card died because of too many write operations over the last years. On my new setup (same pi3 with rasberrypios 11, bullseye) I wanted to improve things and reduce the number of dics writes.
Using iotop, i figured out, that a large portion of the dics writes is caused by librespot. Hence, I carefully checked that audio caching is really disabled. However, the dics writes were caused by the currently played song. The song is not directly streamed, but temporarily "downloaded" to the path given in librespots environment variable TMPDIR and deleted directly afterwards. This causes a high IO on the SD-card.

To circumvent this behaviour the idea was to write the currently played song directly to a RAM-disc (tmpfs) instead of the SD-card. So here is what I did.

As mentioned, per default librespot writes the downloaded file to its temporary directory given in the Environment variable TMPDIR. So in raspotifys systemd service one simply has to point that variable to a path located in a tmpfs. To make the changes persistent and not being overwritten with the next raspotify update do not edit raspotifys systemd service configuration file directly, but create an override file using:

sudo systemctl edit raspotify.service

This generates an override file and automatically opens that file in nano. Simply add

[Service]
RuntimeDirectory=%N
Environment=TMPDIR=%t/%N

and save the file. The two lines define a runtime directory which is mounted as tmpfs (ramdisc) located at /run/raspotify and sets the Environment variable TMPDIR to exactly that location. Just save and issue the commands

sudo systemctl daemon-reload
sudo systemctl restart raspotify.service

From now on the file will only be written to RAM which protects your SD-card from write cycles when music is played back.

If you additionally want to control whether to write to SD-card or to RAM you can add the following line to your /etc/raspotify/conf
TMPDIR=/tmp

If uncommented raspotify writes to the SD-card directly (to its private temp directory at /tmp/systemd-private-[hash]-raspotify.service).
If commented it writes to a tmpfs located at /run/raspotify

This is what helped for me, maybe its worth thinking about to include it in the official release, which makes the systemd override file unnecessary.

[JasonLG1979]

I/O isn't really an issue if you get a decent SD card. I've had the same SD card in 4 different versions of Pi's going back for over 5 years and have re-imaged and abused them more than I care to admit. If disk I/O is such a big deal you should just set the Pi to boot read only in raspi-config.

My gut tells me that you're entering unnecessary optimization territory.

An alternative if you have a reasonable sized SD-card that will reduce disk and network I/O and theoretically boost performance a tiny bit is to configure librespot to cache audio files to disk. I have it set up with a cache size of 2 GB (16 GB SD card) on my Pi Zero v2 and 16 GB on my home server (the server is not a Pi) You can fit a lot of 320kbps Vorbis' in 2 GB that later do not need to be re-downloaded.

That being said I'm open to a tmpfs as default so long as it doesn't break disk caching or otherwise negatively affect the operation of Raspotify in any way.

Put in a PR and I will review it.

[d1vzero]

Well, so far I also never had issues with any SD-card, but now it appeared very suddenly and slowed down things extremely. However, I have to admit that I used the SC-card for quite some years reformatting it several times. Of course this also depends on how occupied the card is. Since a lot of people even advise to put /var/log on a tmpfs I wanted to check the I/O in advance. During normal usage I found, that librespot by far caused the highest I/O for me.
Maybe you're right and it 's over optimization, who knows exactly. On the other hand I haven't seen any drawbacks yet. One point I haven't carefully checked is, how very large songs or even long podcasts are handled during playback.

I will put in a PR and we will see.

[JasonLG1979]

I tested it out for a couple hours on my Pi Zero v2 it didn't seem to negatively effect it in any way.

One point I haven't carefully checked is, how very large songs or even long podcasts are handled during playback.

I don't listen to podcasts ever so I don't know how long they can get? But according to this audio file size calculator the track would have to be over 2 hours long to even come close to exhausting the RAM on a Pi with 512MB.

I don't think I'll personally be using it but what we can do is make it so it defaults to using TMPDIR=/tmp in the config so users have the option if they'd like because I do see this as something some people (like yourself) would want.

[JasonLG1979]

Done:
68f45ad

[d1vzero]

Oh, that was a way faster than I was able to even react. Thanks anyhow. Best regards

[JasonLG1979]

Well it was a reasonable, in-scope request and something that other people might want that doesn't change the default behavior. The perfect kind of feature request.

You'd be surprised how often people file bug reports for things that are totally not bugs or are caused by user error and/or failure to actually read the README or wiki, or make feature requests that are super niche or completely out of scope or out of my control.

Basically it's a lot of "I can't get it to work the way I want and I didn't read any of the docs can you spoon feed me." or "I want Raspotify to make me a sandwich."

[d1vzero]

Sorry, I was off for some days.
Well, sounds funny how you give it a name, but I can entirely feel what you are saying.
By the way, that was my point, why I shared this idea. So far I took a lot from the FOSS community and that time it was perfect to give something back, even though it's just two or three tiny lines of "code".

So, thanks again and keep ongoing with your good work and maintenance.

[JasonLG1979]

Download buffering is what Gstreamer calls it and also does the same thing for remote files on occasion.

[d1vzero]

Well then let's name it accordingly.

[dowaichi]

First post to any kind of Github project, so please excuse any mistakes in etiquette.

Not really a bug, but for really long tracks the tmpfs can fill up and cause Raspotify to crash. I recently updated my installation to 0.42.6 and found that Raspotify would crash when playing a 9 hour track (I play white noise to help my infant daughter sleep).

Adding TMPDIR=/tmp to the conf file fixes the problem (revert temp file to main SD card). Making a note here in case someone else has the same use case.

[dowaichi]

Thanks, I see the changes to the default config. Thought I would leave a clue to check the config in case someone else has the same problem. Error: Os { code: 28, kind: StorageFull, message: "No space left on device" }.

It's funny how temporary solutions become permanent ones. I started playing the 9 hour white noise track one night when my daughter wouldn't sleep. I should create a local file so I can play the track offline.

[JasonLG1979]

You don't need a local file, you can generate pink noise indefinitely with speaker-test -c1 -l0 > /dev/null 2>&1.

[JasonLG1979]

You could also go so far as to create an alias of that command called pink-noise so you don't have to remember it. That way all you'd have to do is ssh into your device and type pink-noise into the terminal.

[dowaichi]

Thanks for the awesome tip! I didn't realize there was something that did this.

[JasonLG1979]

Well it's really for testing speaker outputs but the test tone by default is pink noise, -c1 makes it mono so it doesn't cycle though the speakers, -l0 makes it loop infinitely and > /dev/null 2>&1 redirects the terminal output to /dev/null otherwise it will fill your terminal with text output. So it's kinda a hack but it works.

[giggywithit]

raspi-config
performance options
overlay file system

when you get your system all set up the way you want it, then enable the overlay file system
cheers!

[JasonLG1979]

Not a good idea. Raspotify is not designed to be used that much like apart of an appliance I update the package very regularly.

[giggywithit]

The unit I put together for my mother has been operating for over a year no issues using overlay fs

[JasonLG1979]

The unit I put together for my mother has been operating for over a year no issues using overlay fs

As long as there are no issues and you and her are happy with how it function I guess?