I’m running Volumio 1.55 on a Raspberry Pi model B, and from time to time my system just crashes, i.e. it’s completely disconnected from the network. Mostly this happens when I’m gone for the day, and come back home to find out I need to reboot the Pi (unplug/plugin the power source) before I can play music again. Lately, this has also occured more frequently when I’m playing. In the midst of a song, it will start crackling, playing really slowly, and then just stop.
Usually a quick reboot (unplug power supply, wait 10 sec., plug back in) works, but more often it completely forgets its entire musical library, and it has to rescan the 300+ Gb HDD that is connected to it again. Very annoying, because then it’s not usable for about an hour.
My setup:
Raspberry Pi Model B with Kingston 8 Gb Class 10 SD Card
This problem of random crashes has been there already since the beginning of RaspyFi, but depending on the build it occured more or less often. Also, sometimes I have periods of weeks without crashes.
I’ve read that the R-Pi systems are particularly sensitive to power supplies. The PSU is 2A and designed for the Pi. I calculated that even in peak usage, it is well below 2A (see below).
Could this be a power supply problem? Or something else…? I would like to fix this at some point, it’s getting annoying. If it could be power related, I might consider getting a second PSU only for the Pi.
HDD: 200-500 mA (idle/peak)
Pi + Wifi adapter: 360-500 mA
DAC: < 500 mA
No ideas/thoughts on this? It’s really annoying.
Since my previous post, it has worked stable, until after this weekend. Since Monday evening, it has dropped out 5 or 6 times already, all within an hour of rebooting the system. I can’t think of anything that has/could have changed in the meantime.
I thought about that too, but it’s not a matter of running for a few days. As said, sometimes it runs without trouble for 3 weeks.
Also, I don’t have a second (stable) power supply that I can miss for that long.
Isn’t there an option to see for example in the logs what is going on just before the crash?
not sure I can help you, but this is my view on your problems:
I assume you’re living in the UK and your powerplug is wired with an earth connection so I think the power may not be an issue (it still can though). It sounds as if your setup is “isolated” because everything is powered to your USB-hub and that one is connected to the powersource. If your have connected the USB-hub some sort of powerrail I would change that first and power it directly to the wall outlet. This may prevent interference of other equipment. If you have the possibility you could try to use a AC-filtered powerrail and connect the USB hub to it, but no other equipment. But I don’t think that the power is your problem.
Have you already tried to flash your SD-card again or use another one? The fact that you loose the entire MPD-database (which is a flat file in your linux-filesystem) sounds as if your Operating System is coming to some sort of a halt due to memory leakage or CPU hang situation. In a crash situation your system would either 1) restart again and you would be able to play music again, or 2) your filesystem would be corrupted and it won’t start at-all.
It is also possible that your HDD drive is causing the problems: especially a HDD that is powered via USB. I have noticed myself with such a drive that when the drive spins down to save power it sometimes may have some trouble to startup again. The time it needs to spinup again may cause too much delay for the linux-system to resync the device. This may cause the system to become unstable when it tries to write data onto it. I use my HDD in read-only mode which prevents the system to write data onto it. It may still not be able to read the data, but it won’t crash.
I don’t know if you have some knowledge of linux, but if you know a little you can check the files in /var/log and see if these contain information from before the moment you restarted your device. The syslog file would be the first to check, but the other logfiles may also contain information. Look for the timestamps before you restarted the system and try to find some evidence of issues which may have caused the system to stop after the message.
But I think it won’t be easy to find issues regarding a power problem because when the system looses power nothing will be logged about that.
Firstly, about the setup. I live in the Netherlands, not the UK. Unfortunately my house is an old house, so we do not have any grounded sockets (except for the washing machine).
The Pi is plugged in on a power strip together with the rest of the audio setup (amplifier, cd player, tuner, and record player). With the limited number of power groups in our house, there is no (easy) way to seperate the Pi from the rest. I don’t think putting it in the same wall socket, but not on the power rail, will make a lot of difference for interference. But it’s worth a try.
I also read somewhere that the first models of the R-Pi aren’t too good with power management on the board, so it might be worth it to have everything powered through the USB hub - including the Schiit - so the Pi does not have to power anything through it’s own USB.
I have already alternated more often between two SD-cards (both 8 Gb SDHC Class 10, Transcend and Kingston), and this problem has always occured (as said, it already happened when it was still Raspyfi).
To rule out the HDD, I might have some luck in the logs I guess? There I should be able to see a write error or something alike just before a crash, right?
My knowledge of Linux is limited, but I pick up fast on it. I tried to view the logs, but no success. I tried the ‘tail’-command (with varying parameters) through SSH on both user.log and syslog, both did not return anything?
I managed to retrieve the log files. The system crashed again after a reboot this morning, so I took the SD-card out before rebooting again, and used an Ubuntu Live cd to boot in Linux and copy the log files to my laptop.
Strangely enough, the files are empty. All of them. I checked the settings (in /etc/), it’s supposed write to, and rotate, the log files. I did find three dmesg.gz logs that contained some info, and it seems like something funny is going on in the USB ports.
Unfortunately I cannot recall the exact date of these logs. The files are last changed June 1st 2015, that’s already some time ago so I don’t know if that is accurate.
See log info below. I think USB 1-1 is the Schiit Modi DAC, that is the only thing connected directly to the Pi. Could that have been causing me problems all along?
The 0x0000002 error looks awfully familiar, reminded me of this topic right away: completely-distorted-sound-volumio-model-t2782-10.html
The error-71 is not clear to me yet…
Update: the system wouldn’t boot properly anymore after I had the SD card in my laptop, so I had to freshly install it again this evening. I also applied a fix that was mentioned online for the error -71. A possible fix for this could be to disable autosuspend of usb devices.
I added “usbcore autosuspend=-1” to the file “/etc/discover-modprobe.conf”. Let’s see if this works… Update 2: Nope, woke up this morning and it still worked. When I was browsing for artists, it crashed again.
On the USB-ports, I see this in two of the logs:
[ 2.839330] usb 1-1: New USB device found, idVendor=0424, idProduct=9512
[ 2.847968] usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[ 2.860334] hub 1-1:1.0: USB hub found
[ 2.866657] hub 1-1:1.0: 3 ports detected
[ 3.148911] usb 1-1.1: new high-speed USB device number 3 using dwc_otg
[ 3.157946] ERROR::dwc_otg_hcd_urb_enqueue:505: Not connected
[ 3.157946]
[ 3.170419] ERROR::dwc_otg_hcd_urb_enqueue:505: Not connected
[ 3.170419]
[ 3.182996] NYET/NAK/ACK/other in non-error case, 0x00000002 << this line is repeated several times >>
..
..
[ 3.348963] usb 1-1-port1: cannot reset (err = -71)
[ 3.355318] usb 1-1-port1: Cannot enable. Maybe the USB cable is bad?
On the HDD, I see these logs:
[ 2.553088] EXT4-fs (mmcblk0p3): INFO: recovery required on readonly filesystem
[ 2.562557] EXT4-fs (mmcblk0p3): write access will be enabled during recovery
..
...
[ 11.494248] EXT4-fs (sda1): recovery complete
[ 11.500985] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null)
[ 14.513051] EXT4-fs (mmcblk0p3): re-mounted. Opts: (null)
[ 14.903406] EXT4-fs (mmcblk0p3): Mount option "nouser_xattr" will be removed by 3.5
I assumed you were living in the UK (because of the link to your USB-HUB); we both live in NL then We could continue in dutch but I don’t think the rest of the Forum will understand us then , so we’ll continue writing in english, ok?
the fact that your system crashed during browsing through your music catalogue may imply that accessing reading/updating the catalogue is causing the problem. This sounds as if the access to the SD-card is not working correctly. I myself had a problem with breaking off one the notches of the SD-card holder on the back to the RPI (B-version). So I was not able to insert my SD-card in the right way (causing startup problems in my case), because the card did not slide in properly anymore. I created a small “landingstrip” in my casing which causes the SD-card to be squeezed against the cardholder pins. Since then it works ok. I must say that I never leave my RPI on continuously, so I have no experience with crashes overtime, but I don’t have crashes during usage.
I was thinking about issues you may have with the USB-bus: did you already try to change the USB-connections? Perhaps you can rearrange the USB-ports and see what happens. I think connecting the USB-DAC via your HUB won’t be ideal, but may be worth a try.
Let’s not go into incomprehensible Dutch jibberish then indeed
The SD card fits into the slot nicely, I don’t recall ever having problems with that. If it is the case that it does not properly connect, it has been like this from the start (as said, this problem has occured since I have it). I guess there is no real way to test this?
I always run the Pi continously, so I have music instantly when I come home. Saves me the trouble of having to plug it in and waiting for the system to boot (especially when someone else is using the system). It shouldn’t be a problem, right?
I have changed the USB connections some time ago. Before I always had the Schiit via the hub and the wifi-adapter directly on the Pi. It is the other way around now, considering the Schiit is the most important part of the system. I know the usb-powered devices can cause problems when connected directly to the Pi, but the Schiit should not take more than 120 mA - well below the 500 mA of a bus.
I can try to change this around a bit, maybe connect everything to the hub to relieve the Pi of any duty to power through the bus.
I did notice something regarding the USB connections yesterday. It’s stupid, but it might play a role in this part. The Pi is close to the window, so when I open the curtains, the curtain sometimes moves the USB cable attached to the Pi. That could cause the “USB cable connected?” error maybe.
Other than that, the random drop-outs are still a mystery…
Update on this: it looks like that the PSU was the problem after all…
The R-Pi would not start at all anymore over the last weeks, but I didn’t bother looking at it as I was too busy with other stuff. This week I reinstalled the SD card again for a fresh try. I wanted to disconnect everything and reconnect one by one, to single out the culprit.
All worked well with the R-Pi directly connected to LAN, nothing else connected, and powered through my Sony Xperia mobile phone charger. Then I changed to the PSU of the USB hub, and it would not even boot. So that PSU has had better days…
After, I tried my original setup again with everything connected, but this time the R-Pi was powered seperately by the Xperia charger instead of through the USB hub. That worked stable for several days without drop-outs. The wifi and HDD reading were slow though because of the faulty PSU of the USB hub.
I just ordered a new power supply for just over 20 Euro: a Meanwell GS40A05 5V 5A desktop adapter. It might be a bit overkill, but it looks like a decent switching PSU with plenty of juice to be a stable power supply for the Pi.
It’s really annoying.
, so we’ll continue writing in english, ok?
