Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Musicbox - SD Card Corrupt! Fix by using Read Only file filesystem? #373
Every couple of weeks the SD card gets corrupted. When that happens I plug the SD in my PC and re-write the musicbox0.6.img on it using Win32DiskImager. I then copy over the settings.ini file to get access to my spotify profile. After putting back the SD in the Raspberry Pi 2, everything works again.
I've been checking some ways to make sure the system doesn't get corrupted from power outages for an other Raspberry Pi project. One way to do it is by using a read-only filesystem, with an unionfs for the parts that need write access. Or an seperate partition that gets recreated on boot (and the system reboots when it isn't writable anymore).
I was wondering if that would be possible with the musicbox image?
I don't need to be able to change any settings with the web-interface, so not being able to persist the settings wouldn't be a problem.
I agree this would be a good improvement, it's something that has come up before and I've been looking into it a bit recently. My thoughts so far were leaning towards unionfs and steering clear of changing partitions.
Most people would want to use the web settings normally so supporting this would be good. It'd probably be enough to sync back the changes on shutdown.
I also agree it would be a great improvement. On most music systems, the ideal setup would involve having the RPi hidden below a HiFi setup, and only turning it on when it's going to be used for playing music. In such cases, the SD card doesn't survive three power cycles without becoming corrupted.
Things I've tried, from the HowTos linked above:
removing packages doesn't seem necessary, since the Pi Music Box image seems to be already stripped of all unnecessary stuff. DHCP also works without linking to a different file.
For logging, I had to change the log path from
With only these changes, everything seems to work fine, but extremely slow. I'm not sure if this is a specific problem of 0.7 RC4, anyway. Other users have reported slowness in the forum as well.
Since the music is hosted in a remote SMB or NFS share, I think it would be clever to move the database there. I've tried digging on the folders and on the project documentation, but haven't found the path of it. Do any of you guys have an idea of where this path can be?
Apart from the DB, are there any other files or folders where the MPD service needs to write?
I personally don't see why you'd be switching the pi off and I maintain that's the ideal setup. However, I appreciate it's entirely up to you or it might just be logistically difficult with your power arrangement.
In 0.7.0rc4 there should already be no swap and a tmpfs at /tmp.
Mopidy doesn't try to create it's folder in /var/log and I think you'll find that's the case with other services that have their own subdirectory there (apache springs to mind). I'm not sure if that's some sort of debian best practice or something. Some other tmpfs logging setups I looked into would go and specifically create all the folders that were missing (which is derived from the target directory used to sync things to on shutdown).
I've heard of streams being slow to start but not slowness in general. Do you have examples of other slowness? Maybe we could work out where it's now unable to cache to. /var/cache maybe? Spotify expects somewhere like that, I don't recall where off the top of my head. Gstreamer might be using somewhere unexpected on the file system for it's buffering.
Are you using the MPD frontend? That is generally slower than the Http frontend, especially with streaming backends like Spotify.
I don't think you'd want to move the database to somewhere slower to access. You want the database local. Having a remote music directory should only result in slow scanning but then be unnoticeable. You're welcome to try it though: https://docs.mopidy.com/en/release-1.1/ext/local/#confval-local/data_dir
Other places to write:
Thanks for the feedback.
Well, I've just added
I'll take your advice about not moving the DB to a network share. I'm considering the idea of putting it into a separate USB drive. That would give faster and read-write access. Do you know what's the exact path of it?
In normal operation there are only reads, so I don't think there is much to be gained by moving it.
You can change the setting, it's actually https://docs.mopidy.com/en/release-1.1/config/#confval-core/data_dir that you want (different to what I said before). By default it's set
but the command : apt-get install busybox-syslogd gives me this error :
Do you think the method linked should work with pimusicbox ? can someone give me the steps to make pimusicbox read only ?
I'm not an expert but it looks like you're out of space. Have you expanded the filesystem?
I think there is a way to configure it in the settings.ini file so it happens automatically on the first boot.
Sometimes there is a buffer somewhere on the filesystem like /var/cache/gstreamer that needs to write.…
On 23 Sep 2017 3:03 p.m., "acca84" ***@***.***> wrote: My system is box read only but i have no sound from my usb sound card (wich worked in rw mode). Any advice To make it work please ? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#373 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA5DqKdDtX7cpdgYM8ZnE-lEjEullV3tks5slQ_BgaJpZM4IyAyk> .