@thisisvv
You have to build the image yourself. The instructions on moodeaudio.org have proved sufficient for folks familiar with the Raspberry Pi ecosystem but if you need more you can also have a look at @Drone7's nice post
Moode Audio Player for Raspberry Pi
The result is well worth the extra effort.
Regards,
Kent
Maybe Tim could put this kind of howto on the webpage ?
This will be very usefull for any potential new moode audio users 😀
Yes I did manage to get it to work with Safari.
Oh, man. I was a Norton man back in the day, but any vintage bike turns my head!
Amplifier Switch
Hi Tim,
new UI looks great - I am still a bit afraid about the update, since I added the GPIO switches for my amps (http://www.diyaudio.com/forums/pc-based/271811-moode-audio-player-raspberry-pi-770.html#post5073283)
Are there any plans of you, to add this feature by default?
Thank you
Vogi
Hi Tim,
new UI looks great - I am still a bit afraid about the update, since I added the GPIO switches for my amps (http://www.diyaudio.com/forums/pc-based/271811-moode-audio-player-raspberry-pi-770.html#post5073283)
Are there any plans of you, to add this feature by default?
Thank you
Vogi
UPDATE: I was complaining earlier that I wasn't able to build moode on my Raspberry Pi 2. It turns out I don't have one. It's a Pi B 1 with 256M RAM. I also have the variant with 512M of RAM on which I was able to finish the automated build without issues - it took almost 4 hours.
If you have the 256M RAM variant, this might be the problem. I managed to build it on the 512M one, as I said. I could try to build it on a different SD card on a USB adapter, but I can't find the adapter in the house. If I do it, I could create the image and share it.
=====
A different discussion: is there a way to build the image without some of the components? I think there are a lot of people who don't need the Local UI, which is pretty big in requirements. Also, at least in my case, Airplay (or what the apple thing is called) is not a needed component.
If you have the 256M RAM variant, this might be the problem. I managed to build it on the 512M one, as I said. I could try to build it on a different SD card on a USB adapter, but I can't find the adapter in the house. If I do it, I could create the image and share it.
=====
A different discussion: is there a way to build the image without some of the components? I think there are a lot of people who don't need the Local UI, which is pretty big in requirements. Also, at least in my case, Airplay (or what the apple thing is called) is not a needed component.
@eparson
Just a friendly reminder that we are not mind readers.
The upper part of the NAS Source page requires five entries, not counting the choice of NFS vs SMB/CIFS. What information did you enter, exactly?
By "no joy", I assume that when you tried to save the settings you got the error message
This can be caused, for example, by an incorrect entry in the "Remote directory" field (notably, by including a leading slash "/" in the share name) or by an unresolvable "Host or IP Address" field entry. Sadly, the error message in the moode.log is the same in both cases
As @Serverbaboon says, you can't have "NAS" in the source name, but if you tried you would get a popup on save which says
I haven't run FreeNAS in years but I have no problem configuring moOde against both OpenMediaVault and MinimServer. I would expect the same with FreeNAS.
Because neither NFS nor SMB/CIFS are working for you, I wonder if you are pointing to the correct server host. Entering the symbolic hostname works fine for me on my network, but @Serverbaboon's comment about using the numeric IP address of his server is cogent.
Rather than trying to read through all of relnotes.txt before I've had my requisite fill of coffee, I'll let Tim comment on the possibility the transition from moOde r3.8 to r4.0 has caused your problem.
Regards,
Kent
What was that old Sesame Street song? Oh, yeah, "One of these things is not like the other."
You could also try enabling swap (to a swap file; Google is your friend) but of course that would slow things down even more.
Glad you got it sorted!
Regards,
Kent
@Serverbaboon
Thanks for going the extra mile here. I've now read the Google explanation of App Passwords. It isn't clear how this would work against upmpdcli accessing the Google Play Music API but at least I have a point of reference.
And I heartedly endorse your recommendation to always build moOde using a wired ethernet connection.
Regards,
Kent
Hi,
The oscillators on the DAC+Pro interfere with 2.4GHz WiFi/BT band.
WLAN driver not working correctly when using HiFiBerry DAC+ Pro * Issue #1588 * raspberrypi/linux * GitHub
I think Hifiberry has a new revision of the Pro that may fix this ugly issue. Contact them for support.
I'd be suspicious of any HAT board with oscillators (clocks).
-Tim
Hi Vogi,
Prolly not because the amp switcher is not a very common reqt but if I get bunch more requests for it then I'll have a look.
-Tim
Hi,
You would have to use the manual Build Recipe if you wanted to omit components but the risk in doing this is that future in-place updates might bomb and parts of the UI won't work.
Good luck.
-Tim
I am on my third attempt at running the 4.0 build <sad face>
Previously successful at building beta12 I thought that this would be easier.
On this third attempt, I am once again getting errors:
Last login: Fri Feb 2 11:31:37 2018 from 192.168.0.13
pi@moode:~ $ mosbrief
// STEP 2 - Direct build so no need to expand Root partition
// STEP 3A - Install core packages
// STEP 3B - Install core packages
// STEP 4 - Install enhanced networking
** Compile bluez-alsa
// STEP 5 - Install Rotary encoder driver
** Compile WiringPi
** Compile rotary encoder driver
// STEP 6 - Compile and install MPD
** Error: install failed
** Error: image build exited
** Error: reboot to resume the build
Any suggestions what I might be doing wrong. It's a reliable SD card on an RPI2, clean version of November Stretch Lite "etched" onto the card and the commands run verbatim from the instructions. Not using Wifi either. I've done a restart of the RPI - but it doesn't seem to be resuming the build???
Previously successful at building beta12 I thought that this would be easier.
On this third attempt, I am once again getting errors:
Last login: Fri Feb 2 11:31:37 2018 from 192.168.0.13
pi@moode:~ $ mosbrief
// STEP 2 - Direct build so no need to expand Root partition
// STEP 3A - Install core packages
// STEP 3B - Install core packages
// STEP 4 - Install enhanced networking
** Compile bluez-alsa
// STEP 5 - Install Rotary encoder driver
** Compile WiringPi
** Compile rotary encoder driver
// STEP 6 - Compile and install MPD
** Error: install failed
** Error: image build exited
** Error: reboot to resume the build
Any suggestions what I might be doing wrong. It's a reliable SD card on an RPI2, clean version of November Stretch Lite "etched" onto the card and the commands run verbatim from the instructions. Not using Wifi either. I've done a restart of the RPI - but it doesn't seem to be resuming the build???
Last edited:
Part of the problem is that mosbuild_worker.sh turns off swap and deletes the swap file. The latter makes sense if you're building a burnable image, I guess, but otherwise it's a right pain if you later decide you need to swap.
I've argued on this thread before that it should leave swap alone, perhaps with the option at the end of the build to turn it off.
IMHO, there really is no advantage in turning swap off in modern Linux kernels, especially if you set swappiness to 1.
sudo nano /etc/sysctl.conf
vm.swappiness = 1
Phil
Last edited:
Did another restart of the RPI2 and tried mosbrief again and it now seems to have moved on!!
// COMPONENT 1 - MiniDLNA
// COMPONENT 2 - Auto-shuffle
// COMPONENT 3 - MPD Audio Scrobbler
// COMPONENT 4 - Shairport-sync
// COMPONENT 5 - Squeezelite
// COMPONENT 6 - Upmpdcli
** Compile Libupnp jfd5
** Compile Libupnpp
So don't know whats going on...? Other than accepting that it now seems to have restarted the build as previously promised by the script.
It this works, then hats off to the scripters who have worked their magic for it to autorepair
I'd clean forgotten about that bit in mosbuild_worker.sh, Phil.
[edit: looks like you slipped an edit of your own. This bit is now redundant] Perhaps reintroduce swap along with a very low swappiness setting (something like 10 instead of many distros' 60 or so) to save us from OOM errors but keep the kernel from constantly swapping buffers and caches.
Regards,
Kent
I updated my post with that in mind. For the purists, set swappiness to 1, otherwise, try 10.
Phil
Hi Phil,
I'd have to revisit swap but as I recall the advantage to disabling it is to save up to 1GB of disk space that it reserves, and AFAIK on a running moOde system swap is never used anyway.
Is the issue that no swap causes Builder fail on 1st gen Pi w/256G ram?
-Tim
Might be worth creating a 100 or 200 MB swap file. I had problems building one of the betas on my pi zero w until I gave it some swap, but Kent came up with a workaround to install a package first.
But the same principle probably applies to 256MB pis.
Cheers,
Phil
Hi,
I'm totally agree with Phil on this case... no need to touch the swap, and i think, in certain case (with DSD, localUI and other options in same time), you can need more memory...
Why touch the swap file and not configure it (size and usability)
for the percent of use, like Phil wrote, just change this parameter (or create it) inside /etc/sysctl.conf
for the size of the swap file you can refer to this :
Increase size of existing swap file - Raspberry Pi Forums
Regards