• Welcome to ASR. There are many reviews of audio hardware and expert members to help answer your questions. Click here to have your audio equipment measured for free!

moOde audio player for Raspberry Pi

I'm surprised SMB 1.0 is still enabled by default. It's been deprecated for ages because of security issues in the protocol itself.
 
Yes, on the other hand the user says he has an only Zyxel device so the support for SMB 1.0 gets very handy for him. Many people use HTTP or very weak passwords on their local networks.
 
Yes, on the other hand the user says he has an only Zyxel device so the support for SMB 1.0 gets very handy for him. Many people use HTTP or very weak passwords on their local networks.
I know, but with more things aiming for 'secure by default' these days the capability to use the less secure options often has to be manually enabled. It's the sort of change that can then catch people out with "it used to work but now it doesn't" type problems when they're using something that used to be enabled by default but now needs to be manually enabled.
 
It's still your music, not your bank account credentials. Then it is in your LAN, and usually your router does not port forwarding to your NAS, or your moOde box.
I find these vulnerabilities in the SMB protocol (for one) taken to an excess, sometimes...
 
I appreciate your remarks about the vulnerabilities of smb 1.0, but please have in mind the following:
  1. The box is quite (more than 10 years) old and its original OS doesn't support greater smb versions.
  2. Apart from file sharing, no other media or online server has been enabled on this NAS.
  3. My home router's firewall doesn't permit inbound connections either to rpi or NAS.
  4. This device is not always on. It is booted only when I want to add or modify albums and when I want to listen to music.
Thanks.
 
Last edited:
  • Like
Reactions: EJ3
I appreciate your remarks about the vulnerabilities of smb 1.0, but please have in mind the following:
  1. The box is quite (more than 10 years) old and its original OS doesn't support greater smb versions.
  2. Apart from file sharing, no other media or online server has been enabled on this NAS.
  3. My home router's firewall doesn't permit inbound connections either to rpi or NAS.
Thanks.
I am with you.
And for what concerns the firewall... well, you can always bypass it for a certain path. No worries.
 
V1 SMB is an interesting issue.

What I see in the Samba relnotes is that the v1 protocol is default disabled starting with Samba 4.11 (2019) and can be removed entirely from a Samba build starting with 4.17 (2022). https://wiki.samba.org/index.php/Samba_Features_added/changed#Release_Announcements_13

Current moode ships with the 4.17 package from PiOS Bookworm but I think its built with v1 included, at least I don't see anything in the deb package release notes that indicates v1 protocol was removed in 4.17 or any higher builds. https://metadata.ftp-master.debian..../samba/samba_4.17.12+dfsg-0+deb12u2_changelog

So unless it's explicitly removed from the build itself it apparantly can still be used by either specifying "vers=1.0" in the client mount options or for servers enabling it with some options in the server smb.conf file.

I'd have to look at the moode code that does SMB mounts but I think it detects/allows SMBv1 when querying a Samba server for protocol support and then auto-adds "vers=1.0" to the client mount flags. Something like that.

At some point the upstream Debian/Raspbian Samba build will remove v1 protocol and then we can update our mount code.
 
Hi, I have a rasberry pi 2 with Allo Digione and a rasberry pi 3 with HiFiBerry Digi+. The music library for both are two NAS boxes, a quite old Zyxel (with SMB 1.0) and a more recent AsusStor.

On rpi2 I have recently installed moode 8.3.9 successfuly.

On rpi 3 I initially installed moode 9.4.0. The two NAS connections were setup successfuly and moode reported the total and free disk space. When I tried to update the library however, the process stuck in a path in Zyxel (as I saw in the mpd log file), after adding a couple of albums. I rebooted the device and tried to update the library from the command line (mpc update or mpc rescan). I even deleted the database file and let the mpd create a new one by restarting the service. Nothing succeded to overcome the stuck point. To save my time (and my nerves) I installed moode 8.3.9 (64 bit) which installed and update the library successfuly.

I'm reporting my experience here to notify Tim (to whom I remain grateful) about this case.

We've had a few similar reports in our Forum regarding the current 0.24 series MPD (used in moode 9) having issues indexing a file while the older 0.23 series MPD (used in moode 8) had no issue.

Feel free to zip up the album containing the file(s) that are involved and PM me a download link. I'll have a look.
@dadim, I tested your files (on a USB stick with a lot of other music files) and no issues with MPD indexing or playback but there were some hidden dot files in the folder (maybe from MacOS?)

Screenshot 2025-09-30 at 7.04.00 PM.png Screenshot 2025-09-30 at 7.05.48 PM.png

Are you sure this is the album that caused MPD update to not finish?

When looking at the MPD log it's not obvious but MPD processes the music directory tree in whats called "directory order" not alphabetically. If you want to determine the file after the last one that was successfully indexed and logged then try listing out the music directory using the command below.

ls -R -lU

if there are a lot of files then the output could be ginormous.
 
@dadim, I tested your files (on a USB stick with a lot of other music files) and no issues with MPD indexing or playback but there were some hidden dot files in the folder (maybe from MacOS?)

View attachment 479689 View attachment 479690

Are you sure this is the album that caused MPD update to not finish?

When looking at the MPD log it's not obvious but MPD processes the music directory tree in whats called "directory order" not alphabetically. If you want to determine the file after the last one that was successfully indexed and logged then try listing out the music directory using the command below.

ls -R -lU

if there are a lot of files then the output could be ginormous.
You are right Tim. I thought that mpd didn't update the whole album (left out Sibelius), but this is not the case. This album has been updated successfully. I sent you the next album in order.

Concerning smb 1.0. Please don't drop the support. Show mercy to people like me with old devices. :(
 
You are right Tim. I thought that mpd didn't update the whole album (left out Sibelius), but this is not the case. This album has been updated successfully. I sent you the next album in order.

Concerning smb 1.0. Please don't drop the support. Show mercy to people like me with old devices. :(

lol, I don't see a need to remove smb1 mounts from moode, unless some big security issue comes up in our Forum but be forewarned that it will eventually be removed in the upstream Samba package and then by default in moode. Prolly best to migrate your files from old to new NAS.

As far as the second test album goes I didn't encounter any issues with MPD indexing the album and playing the ape file itself but the album is broken because:

1. The FILE parameter in the cue sheet doesn't match the actual filename
2. There are non-UTF-8 or corrupted characters in the filename, cue sheet and file metadata.

Have a look at the items highlighted in red.

Metadata in the ape file:
Album tag: Sir Alexander Gibson Brahms??Schubert
Title tag: D:\cd\?½??ļ???\Claudio Arrau, Scottish National Orchestra - Sir Alexander Gibson Brahms??Schubert

Files:
pi@moode9:~ $ ls -al /media/VFAT64/Test/dadim/BBCL4125/
total 181504
drwxr-xr-x 2 root root 32768 Oct 1 06:27 .
drwxr-xr-x 4 root root 32768 Oct 1 06:27 ..
-rw-r--r-- 1 root root 184884959 Mar 11 2009 'Claudio Arrau, Scottish National Orchestra - Sir Alexander Gibson Brahms;Schubert.ape'
-rw-r--r-- 1 root root 1473 Mar 11 2009 'Claudio Arrau, Scottish National Orchestra - Sir Alexander Gibson Brahms;Schubert.cue'
-rw-r--r-- 1 root root 1482 Mar 11 2009 'Claudio Arrau, Scottish National Orchestra - Sir Alexander Gibson Brahms;Schubert.log'
-rw-r--r-- 1 root root 785363 Mar 11 2009 IMG_0013.jpg
-rw-r--r-- 1 root root 106 May 13 2011 www. boxset. ru. url

pi@moode9:~ $ cat /media/VFAT64/Test/dadim/BBCL4125/Claudio\ Arrau\,\ Scottish\ National\ Orchestra\ -\ Sir\ Alexander\ Gibson\ \ \ BrahmsSchubert.cue
REM GENRE Classical
REM DATE 2002
REM DISCID 6011F407
REM COMMENT "ExactAudioCopy v0.99pb4"
PERFORMER "Claudio Arrau, Scottish National Orchestra"
TITLE "Sir Alexander Gibson Brahms£»Schubert"
FILE "Claudio Arrau, Scottish National Orchestra - Sir Alexander Gibson Brahms£»Schubert.ape" WAVE
TRACK 01 AUDIO
TITLE "BRAHMS - Piano Concerto No. 2 - I.Allegro non troppo"
PERFORMER "Claudio Arrau, Scottish National Orchestra"
INDEX 01 00:00:00
.
.

Screen shots

Screenshot 2025-10-01 at 7.06.53 AM.png Screenshot 2025-10-01 at 7.07.07 AM.png Screenshot 2025-10-01 at 7.07.38 AM.png Screenshot 2025-10-01 at 7.22.52 AM.png
 
As far as the second test album goes I didn't encounter any issues with MPD indexing the album and playing the ape file itself but the album is broken because:

1. The FILE parameter in the cue sheet doesn't match the actual filename
2. There are non-UTF-8 or corrupted characters in the filename, cue sheet and file metadata.
I see. In any case, this is the album that caused mpd update library process to stick, as it is the next album in order to be processed (according to the results of the ls command you write above). And since the update never end it didn't add an entry to the log file. This is where the mpd of 8.3.9 was able to proceed.
 
I see. In any case, this is the album that caused mpd update library process to stick, as it is the next album in order to be processed (according to the results of the ls command you write above). And since the update never end it didn't add an entry to the log file. This is where the mpd of 8.3.9 was able to proceed.

Why it's not working on your end is a mystery to me since that album even with all the breakage in the cue and files was indexed successfully in my test.

That an old version of moode/MPD worked is of no use in troubleshooting because our project has only enough bandwidth to support and troubleshoot the latest version so if you can provide a way for me to reproduce the issue on my end with r940 I can continue to investigate.
 
Hi all,

I hope it's okay to post in this thread.
I’m working on integrating the Audio Injector Octo sound card with moOde on a Raspberry Pi 4.
The issue is that the Octo only works under Kernel 5. With Kernel 6, it’s not supported and only produces noise.

I created a working script that installs the Octo audio interface together with CamillaDSP and the JACK Audio API on a downgraded Raspberry Pi OS Lite.
You can see it here: https://github.com/Audio-Injector/Octo/issues/71.

Now I need to figure out how to make moOde and the Octo work together via Camilla.
I downgraded the kernel of a freshly installed moOde system. With that, the correct device tree overlay (audioinjector-addons.dtbo) can be selected, and the Octo is recognized as an output device.

However, Camilla stays in an offline state and no playback or capture devices are available to choose from.
When I run my script (which compiles Camilla and sets up the service), I can get Camilla into an online state. But in that case, moOde is bypassed, since the Octo’s analog inputs are being used directly.

The question is: How can I get moOde to send audio directly to the Octo via I2S? Is a loobback device needed?
 
The issue is that the Octo only works under Kernel 5. With Kernel 6, it’s not supported and only produces noise.
IMO it should be investigated and fixed. The driver is still there and there were not many changes in that part of the kernel. My 2 cents it would take only some trivial change. Does dmesg say something on kernel 6?
 
IMO it should be investigated and fixed.

Not having to downgrade the kernel would be extremely helpful.
I’ve investigated this issue (with some AI assistance), but so far without success.
Since it’s not directly related to moOde, it’s probably best not to discuss it here.

Please feel free to join the following thread—I’ll be posting dmesg output and other diagnostic data there.
 
Hi all,

I hope it's okay to post in this thread.
I’m working on integrating the Audio Injector Octo sound card with moOde on a Raspberry Pi 4.
The issue is that the Octo only works under Kernel 5. With Kernel 6, it’s not supported and only produces noise.

I created a working script that installs the Octo audio interface together with CamillaDSP and the JACK Audio API on a downgraded Raspberry Pi OS Lite.
You can see it here: https://github.com/Audio-Injector/Octo/issues/71.

Now I need to figure out how to make moOde and the Octo work together via Camilla.
I downgraded the kernel of a freshly installed moOde system. With that, the correct device tree overlay (audioinjector-addons.dtbo) can be selected, and the Octo is recognized as an output device.

However, Camilla stays in an offline state and no playback or capture devices are available to choose from.
When I run my script (which compiles Camilla and sets up the service), I can get Camilla into an online state. But in that case, moOde is bypassed, since the Octo’s analog inputs are being used directly.

The question is: How can I get moOde to send audio directly to the Octo via I2S? Is a loobback device needed?
moode uses the alsa_cdsp LADSPA plugin from @scripple https://github.com/scripple/alsa_cdsp

It receives audio from the source, handles rate/format switching, updates the camilla config, starts camilla and pipes the audio to it. IIRC we made a patch to the plugin based on some code from the bluez-alsa project to fix some minor issue.

MPD -> alsa_cdsp -> camilladsp -> device

View /etc/alsa/conf.d/camilladsp.conf
 
Why it's not working on your end is a mystery to me since that album even with all the breakage in the cue and files was indexed successfully in my test.

That an old version of moode/MPD worked is of no use in troubleshooting because our project has only enough bandwidth to support and troubleshoot the latest version so if you can provide a way for me to reproduce the issue on my end with r940 I can continue to investigate.
I understand the bandwidth limitation. From a follow up check I did on my system, the problem with mpd 0.24 appears when the library update encounters a folder with a CUE file and a single audio file and even more, when the CUE file contains illegal characters or has integrity problems. In these cases the mpd 0.23 is more forgiving, where the library folder contents may not be playable, but the update continues. When I split the CUE file into separate Flac files for each track, the mpd 0.24 updates the folder successfully, as it is expected. From some AI questions I performed, I got responses that the CUE issues of mpd 0.24 are more or less known, but I'm not sure that this is correct.
 
Last edited:
the problem with mpd 0.24 appears when the library update encounters a folder with a CUE file and a single audio file and even more, when the CUE file contains illegal characters or has integrity problems. (...)
Can you elaborate? I have almost 2K albums. ALL ripped to single CD image + CUE file. No problem at all.
CUEs cannot contain illegal characters... they may contain characters that you cannot read properly... thing is: CUEs MUST BE UTF8 at least; then, there is no illegal character.

What is this that you call "integrity problems"? A CUE cannot have such a thing, as it just indexes "addresses" / frames within a file. If it is messed up (that is: one track starts before the one preceding it) then you better re-rip, so the CUE may get properly regenerated...

ETA
Please note, that CUE files go together with ONE AUDIO FILE ONLY. Using CUEs as if they were M3U playlists is an abomination. Use M3Us.
 
I understand the bandwidth limitation. From a follow up check I did on my system, the problem with mpd 0.24 appears when the library update encounters a folder with a CUE file and a single audio file and even more, when the CUE file contains illegal characters or has integrity problems. In these cases the mpd 0.23 is more forgiving, where the library folder contents may not be playable, but the update continues. When I split the CUE file into separate Flac files for each track, the mpd 0.24 updates the folder successfully, as it is expected. From some AI questions I performed, I got responses that the CUE issues of mpd 0.24 are more or less known, but I'm not sure that this is correct.

The challenge is that on my end 0.24 MPD had no issues indexing the broken cue/ape you provided which would suggest something else in moode is causing the issue on your end or something external to moode.

I searched the 0.24 MPD issue list and can't find any "cue" or "cue+database update" issues so maybe the AI is hallucinating again.
 
I understand the bandwidth limitation. From a follow up check I did on my system, the problem with mpd 0.24 appears when the library update encounters a folder with a CUE file and a single audio file and even more, when the CUE file contains illegal characters or has integrity problems. In these cases the mpd 0.23 is more forgiving, where the library folder contents may not be playable, but the update continues. When I split the CUE file into separate Flac files for each track, the mpd 0.24 updates the folder successfully, as it is expected. From some AI questions I performed, I got responses that the CUE issues of mpd 0.24 are more or less known, but I'm not sure that this is correct.
And does mpd output any log on an error like that?
 
Back
Top Bottom