somebodyelse
Master Contributor
- Joined
- Dec 5, 2018
- Messages
- 6,031
- Likes
- 5,783
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.
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.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 am with you.I appreciate your remarks about the vulnerabilities of smb 1.0, but please have in mind the following:
Thanks.
- The box is quite (more than 10 years) old and its original OS doesn't support greater smb versions.
- Apart from file sharing, no other media or online server has been enabled on this NAS.
- My home router's firewall doesn't permit inbound connections either to rpi or NAS.
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.
@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?)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.

ls -R -lUYou 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.@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.![]()

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.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.
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?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.
Raspberry Pi 4 with Audio Injector Octo – Installation Guide
NOTE: This guide shows how to...
moode uses the alsa_cdsp LADSPA plugin from @scripple https://github.com/scripple/alsa_cdspHi 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?
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.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.
Can you elaborate? I have almost 2K albums. ALL ripped to single CD image + CUE file. No problem at all.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. (...)
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?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.