BalenaSound on Pi4 requires purge data to function: scheduling?

Product support
1

Hi all,

I am still struggling to get BalenaSound to keep running on my Raspberry Pis (3 & 4). Currently release 5618043.

Earlier today my Pi4 stopped showing up on Spotify Connect, went to online (VPN only) mode, an eventually went offline. Hard rebooting didn’t help, and pretty quickly went to online (VPN only) mode again.

After some searching I found folks having trouble with storage space
https://github.com/balenalabs/balena-sound/issues/367

After purging the data on the Pi4 (in the literal five seconds that it showed up online after a hard reboot), it showed up online again, and on Spotify Connect. Note that neither memory or storage was full on the Pi4 before the purge.

Now, since this seemed to work to get my BalenaSound running again, I would like to automate this purge. Similarly to the cronjob described here. https://github.com/dtcooper/raspotify/issues/144#issuecomment-596159273

I have setup cronjobs before in Raspbian, but I don’t know where to start in BalenaSound, and if it’s possible to use the purge data action described here https://www.balena.io/docs/learn/manage/actions/

On a similar, is it possible to schedule a reboot, since this is the only thing that seems to shrink the Spotify Connect delay. i.e. When using Spotify Connect with BalenaSound the delay between play/pause grows over time after a reboot. Immediately after a reboot it’s a few seconds, once it’s been online a week it grows to 5 seconds, and this delay continues growing the longer it stays online.

Thank you for your time and thoughts!

2

Hello
If you want to modify this, you will have to fork the balenaSound repo and add your desired changes

  • You could use the supervisor API to trigger a purge from another container using this endpoint. To enable these Supervisor environment variables, the io.balena.features.supervisor-api label must be applied for each service that requires them. See here for further details.
  • Likewise you can use the reboot endpoint. but i wouldn’t recommend this since an error could lead to the container crash looping and causing the device to keep rebooting

From the description you provided, it seems the performance of balenaSound is hindered if the device is on for long. This might be to cache data filling up the disk. I will ask the maintainer of the project for some insights and hopefully this is something we can improve

Cheers

4

Hi there, I think the suggestions made by Rahul are great and would certainly appreciate a PR if you succeed on automating it. As far as I know, spotify’s cache is the only thing that’s using disk space so the only thing that could create a problem like this. It would be nice to observe the disk usage on spotify’s cache directory over time but I realize it’s a very (and long) thing to do.

It’s also possible that the delays are related to this however that I would most certainly attribute it to the software that coordinates the multiroom feature. This is tracked here: Input latency slowly increases over days in multi-room mode · Issue #477 · balenalabs/balena-sound · GitHub, we haven’t had the time to look into it yet. A simple workaround is to reboot every few days that should reset the delay.