Moode Audio Player for Raspberry Pi

apologies but how you install moode now with no image?

@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
 
@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 :D
 
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.


I can confirm a similar observation on a 1st generation Pi B (not B+). Here are the last few lines from mosbuild.log

.......

Another thing, I don't have any ttys available when I attach a console (TV over HDMI & a wireless keyboard). Is this intentional?

Thanks,
- DD

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.
 
I was able to get 4.0 up and running on my first attempt utilizing the script. What I have not been able to do is to get it to successfully connect to my FreeNas Server where all my music library resides. I am trying to connect via NFS utilizing the exact same settings and path that worked in 3.8 but still no joy. I also tried to connect via CIFS and the same thing. When I looked at the log it looks like it is inserting the word NAS to the mount path. Any suggestions?

@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
x Mount error: Click to view moode.log for message text
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
mount error(6): No such device or address

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
Source name invalid
NAS, RADIO and SDCARD cannot be used in Source name

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
 
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.

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
 
For Qobuz you can get the md5 checksum of your password from any Linux box by entering the below command , putting your password in. Note the -n so you don't get a CR hashed in. Its not great but makes me feel slightly better.

echo -n reallysecurepassword | md5sum
14128ce9d7573671f28e95987d19bd40


For Google App passwords try this link.
Sign in using App Passwords - Google Account Help


@Kent
Just realised that my still have not changed my password on this brand new build. :eek:

@FellowInstallers
Script worked fine for me, my advice for PI2 and PI3 is use wired connection to do the install and go and watch a movie or boxset. Stops you being premature in checking.

@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
 
Follow up post
The porblem turned out to be the bluetooth option.
Do not turn the option on if you have the hifiberry Dac+ pro or it will cvarsh the system.
I had to disassemble the DAC form the rpi and uncheck the bluetooth speaker option and after a reboot, things were back to normal

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
 
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.

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???
 
Last edited:
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.
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:
@guyhayton: check moslog command and see what's going on.

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
 
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. Raspbian by default will only swap if it is close to memory exhaustion.

Phil

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'd clean forgotten about that bit in mosbuild_worker.sh, Phil.

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
 
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

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
 
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 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
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