Thanks! Will use halt, controlled by GPIO.
Is it possible to run normal Rasbian GUI on RPi and open browser/email while moode is playing? Then I can just mail script to myself and open on RPi.
I'm not sure whether all of the necessary packages are installed for that, but you should be able to use scp.
Rick
Teac UD-501 DAC - No USB audio device available
Hi everybody,
I have this system:
moodeaudio 2.5 - RPI 2B - Teac UD501 DAC
When connecting the Teac, the "USB Audio Device" is not available in the "MPD"-"Audio output" menu. Doesn´t matter which device I switch on first, or boot with or without the usb-connection. I2S audio device in the system configuration settings is set to "none".
Anybode can help me? Thanks!
Rainer
Hi everybody,
I have this system:
moodeaudio 2.5 - RPI 2B - Teac UD501 DAC
When connecting the Teac, the "USB Audio Device" is not available in the "MPD"-"Audio output" menu. Doesn´t matter which device I switch on first, or boot with or without the usb-connection. I2S audio device in the system configuration settings is set to "none".
Anybode can help me? Thanks!
Rainer
RPi Corrupting SD Card!?
Has anyone found that leaving the RPi running eventually corrupts the SD card?
I started my RPi home audio project a couple of years ago with a different, more difficult to configure, distro. I had it mostly working, but found if I left it running 24/7 for a week or two, it would stop working. It would then fail to boot. And not only were the SD cards corrupt, but I couldn't reflash them again. They were ruined.
I assumed the problem was some type of repeated access from the Linux image itself, which was based on Raspian. But now I've had the same thing happen with the moOde image. I had hoped the ArchLinux baseline world be different. But no joy.
All these failures have thus far been with the same RPi 1 B rev 2. I bought a RPi 3 yesterday and got some new SD cards today, so I'm going to try with Henry's image.
Is anyone else seeing this type of problem?
Rick
Has anyone found that leaving the RPi running eventually corrupts the SD card?
I started my RPi home audio project a couple of years ago with a different, more difficult to configure, distro. I had it mostly working, but found if I left it running 24/7 for a week or two, it would stop working. It would then fail to boot. And not only were the SD cards corrupt, but I couldn't reflash them again. They were ruined.
I assumed the problem was some type of repeated access from the Linux image itself, which was based on Raspian. But now I've had the same thing happen with the moOde image. I had hoped the ArchLinux baseline world be different. But no joy.
All these failures have thus far been with the same RPi 1 B rev 2. I bought a RPi 3 yesterday and got some new SD cards today, so I'm going to try with Henry's image.
Is anyone else seeing this type of problem?
Rick
It looks like a lot of people must have overlooked this functionality:
Nope, some use from the command line, some from ssh, and some (me 😉..) from an ncurses client. All use sudo halt.
If I am connected from the web app then I shutdown as in your screenshots.
rtillery
Unless you're undead and never sleep then you have no way to know if a lines failure or brownout has caused the corruption.
Maybe worth investing in one of the Pi supplies that have battery backup and initiate a controlled shut-down when mains power is lost...?
Oh, one other thing that may or may not be related:
I hit a problem I'd seen with the earlier distro with both the RPi 1 B rev 2 and now I'm seeing it with the brand new RPi 3. I believe it happens when I mount the SD card with my Linux machine after I've flashed it using the img file (with dd). It seems that the system writes the date that the card was mounted onto the card! (WTF is the system doing writing to a card that has just been mounted!?) Then when I try to boot on the RPi, which has no RTC (or at least doesn't have it set on the new card), it refuses to boot because the card was last mounted in the future.
I found a workaround for this (for anyone interested, I'll post it below), but I can't believe 2 years later this same thing isn't happening to most people using a RPi.
(Aside from the obvious question as to why the system shouldn't boot at all with what is obviously not a catastrophic failure, but just a mismatched time...) Is this also something others have seen? Is there a reason we aren't just fixing this in the img file to start with?
Anyway, the workaround is to add the following file:
/etc/e2fsck.conf
Code:
[problems]
# Superblock last mount time is in the future (PR_0_FUTURE_SB_LAST_MOUNT).
0x000031 = {
preen_ok = true
preen_nomessage = true
}
# Superblock last write time is in the future (PR_0_FUTURE_SB_LAST_WRITE).
0x000032 = {
preen_ok = true
preen_nomessage = true
}Well, I do have the power supply connected to a battery backup. And of course any power loss while I'm at work long enough to outlast the battery backup would kill the clocks, so I believe I'd know.
So I take it you've run the RPi 24/7 (perhaps with moOde) for weeks and/or months without issue?
Rick
Last edited:
LOL, I dropped a smilie out of there.
I'm an init 0/init 6 man myself 😉 Sudo halt is too much work.
I run 4 Raspberry Pi´s of various versions around the house performing various tasks. I have had SD card failures, but only when running apps that do frequent card read/writes. My weather server (RPi2) has now been running 24/7 for just over a year without a problem, and my Mo0de server has been running 24/7 January. Prior to running Mo0de I had Volumio on the music server for just under a year without an issue.
I generally don´t mount the SD card on my computer after writing the image, but I am sure I have in the past and can´t remember having any issues.
Good to learn that it might be good to power off decently. I have experienced corruption problems with other programs, but not with MoOde. I must admit that I have been powering off quite a lot in testing by just unplugging and I haven't experienced any problems that I have related to doing that. I have however now and experienced that an SD card apparently could not be re-used and could not be formatted by my mac - until I used SD formatter - a wonderful nut-cracker.
Thanks for the info. I just wish I knew what was giving me problems.
I've now got the RPi 3 set up, but I get no audio from the onboard DAC. I didn't get any with a RPi 1 B+ either. On the RPi 3, I'm actually getting errors. I got one doing the raspi-config thing to change to audio mode 1. And after I forced it in the config.txt file, files won't play with moOde. The streams do though. (But I have no audio.) sound-test doesn't work on RPi B+ or RPi 3 like it did with RPi B rev 2.
Gonna see if there is any way my TSR cable just didn't like the 3.5mm jack next. But that might not explain the errors.
Rick
What DAC are you using?
Can you do a reboot, SSH in and run 'dmesg >msg.txt'? If you post the subsequent msg.txt file, I'm sure we can work out what's going wrong.
A good place to stuff logs, etc. is Pastebin.com - you paste your log, save and it gives you an http link to that log, which you can post.
Putting stuff online from SSH is not the most intuitive, so to make it easier, install pastebinit on your Pi:
apt-get install -y pastebinit
then to send your log file (or whatever):
pastebinit -i msg.txt
It will return a web link
You can do it all in one go: dmesg msg.txt|pastebinit -i msg.txt
http://paste.debian.net/425672/
Last edited:
The onboard DAC, as I mentioned. But I think the DAC choices in moOde differ on Henry's image for the RPi 3 and the image I was using on the RPi 1 B rev 2. The selection I used for the RPi 1 said something like "onboard sound" (I can't look, because as I mentioned, that installation corrupted) while there is no such choice on Henry's image. There I found RPi-DAC and tried that. The log you mentioned checking showed errors, so before I posted, I switched it to None, and voila, sound works!
Thanks, Zootalaws.
Oh, and I neglected to thank Henry for the image!
Rick
Well, this is a new one. Now that Henry and Zootalaws helped lead the way to get the RPi 3 working, I connected moOde to my SMB music server and things were fine...until I rebooted. After reboot, moOde can't connect to the music server. The Configure|Sources screen shows a red X for the share and the error is
"Last mount error
mount error(101): Network is unreachable Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)."
If I re-save the mount without changing anything, all is well (green checkmark).
It appears there is some race condition on startup with the RPi 3 (I didn't see this on the RPi 1 B rev 2) between network availability and mounting the share. Is there a workaround for this?
Rick
"Last mount error
mount error(101): Network is unreachable Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)."
If I re-save the mount without changing anything, all is well (green checkmark).
It appears there is some race condition on startup with the RPi 3 (I didn't see this on the RPi 1 B rev 2) between network availability and mounting the share. Is there a workaround for this?
Rick
umm, as a DLNA server, it doesn't update files 'additionaly' copied to SDCARD.
invisible from the remote(via wifi) control point, but Browse tab sees them and can play locally.
I checked with diyAudio server HTTPS page and confirmed no new files added.
Eventually turning DLNA OFF and ON did it.
Is it the right behavior? I was expecting copying files to SDCARD and "Update this folder" should do it.
invisible from the remote(via wifi) control point, but Browse tab sees them and can play locally.
I checked with diyAudio server HTTPS page and confirmed no new files added.
Eventually turning DLNA OFF and ON did it.
Is it the right behavior? I was expecting copying files to SDCARD and "Update this folder" should do it.
Hi,
In Moode 2.5, the DLNA server needs to be turned off/on to pick up changes. This actually causes a complete rebuild of its database from scratch. The "Update folder" and "Update MPD db" actions only affect the MPD database, and the update process is smart i.e., its a rescan that handles add/change/delete as opposed to a rebuild from scratch.
I can check to see if there is an option in miniDLNA to rescan.
Regards,
Tim
Probably a far out suggestion, but you are not using the Pi with a screen attached to the HDMI port? If so, the sound is redirected to HDMI
Last edited:
Minidlna supports inotify but that's not without its own problems - would work on local filesystems but not sure if it would work against a NAS mount.
Thanks. Henry. I hit that one in my first attempt to get the whole house audio system working several years ago 😎. This time it turned out that I'd misunderstood the DAC selection in moOde. I chose RPi-DAC thinking that meant the onboard RPi DAC, but I found I needed to select None instead to make it work. (I think Tim renamed None in the newer version to clarify.)
BTW, do you see the issue I mentioned with the share not being successfully mounted on reboot with RPi 3 & your image? (Again, thanks for the image.)
Rick