Official moOde 8 support thread

[philrandal]

Hello , I think I have a bug to report . I have two Raspberry zero w with Moode . Version 7.6.1 was previously running on both of them. Have now written the one with the latest version. The Zero w also starts in AP mode , but can not longer find my router during the scan. However, routers in my neighborhood are found. The SSID of my Router is "TP-LINK_2B91 " .
My location is germany .

I have a Zero W. 
I'll test later this morning to see what the scan reports in AP mode and whether it finds my Router.

No problem on Zero W listing my 2GHz SSID after a scan. 

On a 3B+ the scan lists both my 2GHz SSID and 5GHz SSID.

Problem solved ! It was actually my router. Since here in Germany the wifi networks are jostling in the lower channels, I switched to channel 12 and had it to myself. This setting worked fine in previous versions of Moode as well. I am currently using channel 8 and my router is found by Moode 8.0.0. I assume that it is due to the new operating system substructure (→ Raspberry Pi OS Lite 11.2).

I don't know what's changed in between releases, but here's what I think is happening. 

There is a regulatory-domain code stored in the kernel. Out of the box, a moOde 8 player here says the value is

Code:

pi@m8zero2w:~ $ iw reg get
global
country US: DFS-FCC
    (2400 - 2483 @ 40), (N/A, 30), (N/A)
    (5150 - 5250 @ 80), (N/A, 23), (N/A), AUTO-BW
    (5250 - 5350 @ 80), (N/A, 23), (0 ms), DFS, AUTO-BW
    (5470 - 5730 @ 160), (N/A, 23), (0 ms), DFS
    (5730 - 5850 @ 80), (N/A, 30), (N/A)
    (57240 - 71000 @ 2160), (N/A, 40), (N/A)

phy#0
country 99: DFS-UNSET
    (2402 - 2482 @ 40), (6, 20), (N/A)
    (2474 - 2494 @ 20), (6, 20), (N/A)
    (5140 - 5360 @ 160), (6, 20), (N/A)
    (5460 - 5860 @ 160), (6, 20), (N/A)

In s quick test, this value  doesn't seem to be affected by changing the country (code) in moOde's WiFi settings to, say, Germany (DE). This latter is the value which will be used by the wpa_supplicant code which connects to an existing access point.

Continuing with the Germany setting as an example, my finding suggests to me we could have the situation where moOde is able to connect to access points in the channel range permitted in Germany (1-14*) but will scan for APs only in the channel range permitted in the US. 

*As hinted by Lukesan, the RPi doesn't appear to support channel 14.

@Tim Curtis

Assuming I haven't missed something here, it would seem moOde should use the country set in WiFi Configuration to update the internal regulatory domain code. Quoting from the iw man page

Code:

    reg get
        Print out the kernel's current regulatory domain information.

    reg set <ISO/IEC 3166-1 alpha2>
        Notify the kernel about the current regulatory domain.

By the by, supposedly the file /etc/default/crda contains  a setting REGDOMAIN for iw to use as the initial regulatory domain but in both Raspberry Pi OS and my Linux Mint laptop the value of REGDOMAIN is blank. The kernel must be getting it from somewhere.?.?.

Regards,
Kent

It may be getting it from the router.

Does the solution suggested here work?

https://storck.io/posts/raspberry-pi-cant-find-my-wifi/

Phil

[Tim Curtis]

Right, setting the wifi country code only makes an update to wpa_supplicant.conf "country=" line.

Maybe check to see what raspi_config does?

[UpsiUps]

I hate the Major version upgrades as I have to walk and find all my RPis in the house, plug th eSD card , burn a new one , plug the new one in and restart configuration ... Oh, last point has a significant improvement : backup and restore !

Excellent! and even a possibility to run my own restore script - more excellent !

I all mention that as there seems a small bug, that I have been faced during my upgrade procedure: I unwraped all backup-zips to grab the unique moodecfg.ini and throw them on the /boot partition. That worked very well and the players came up even with the NAS connected per NFS. I then restored using the zip file the rest.
... and then I had a duplication of my NAS Library as Library source. So it seems that restore adds the library regardless if this is already connected.

Workaround ist fast: just deleted the latest entry of the list. But maybe you want to proof, why the duplication is happening.

[TheOldPresbyope]

Right, setting the wifi country code only makes an update to wpa_supplicant.conf "country=" line.

Maybe check to see what raspi_config does?

Just checked raspi-config (https://github.com/RPi-Distro/raspi-conf...spi-config)

After some prelim to get the two-char country code into $COUNTRY, we find starting at line 609 that iw reg set is used

Code:

 if [ $? -eq 0 ];then
   wpa_cli -i "$IFACE" set country "$COUNTRY"
   wpa_cli -i "$IFACE" save_config > /dev/null 2>&1
   if iw reg set "$COUNTRY" 2> /dev/null; then
     ASK_TO_REBOOT=1
   fi

@philrandal

Interesting find. Yet another place to hide configuration info --- the hallmark of Linux! Out of the box, that file doesn't exist either in moOdeOS (e.g., Raspberry Pi OS) or my Linux Mint laptop but obviously one can define it.

On your first point, I don't see how the country code can be retrieved from the router before the access point has been discovered.

Regards,
Kent

[Tim Curtis]

I hate the Major version upgrades as I have to walk and find all my RPis in the house, plug th eSD card , burn a new one , plug the new one in and restart configuration ... Oh, last point has a significant improvement : backup and restore !

Excellent! and even a possibility to run my own restore script - more excellent !

I all mention that as there seems a small bug, that I have been faced during my upgrade procedure: I unwraped all backup-zips to grab the unique moodecfg.ini and throw them on the /boot partition. That worked very well and the players came up even with the NAS connected per NFS. I then restored using the zip file the rest.
... and then I had a duplication of my NAS Library as Library source. So it seems that restore adds the library regardless if this is already connected.

Workaround ist fast: just deleted the latest entry of the list. But maybe you want to proof, why the duplication is happening.

The Restore handles copying moodecfg.ini to /boot. You don't have to do it manually.

[Tim Curtis]

Right, setting the wifi country code only makes an update to wpa_supplicant.conf "country=" line.

Maybe check to see what raspi_config does?

Just checked raspi-config (https://github.com/RPi-Distro/raspi-conf...spi-config)

After some prelim to get the two-char country code into $COUNTRY, we find starting at line 609 that iw reg set is used

Code:

 if [ $? -eq 0 ];then
   wpa_cli -i "$IFACE" set country "$COUNTRY"
   wpa_cli -i "$IFACE" save_config > /dev/null 2>&1
   if iw reg set "$COUNTRY" 2> /dev/null; then
     ASK_TO_REBOOT=1
   fi

@philrandal

Interesting find. Yet another place to hide configuration info --- the hallmark of Linux! Out of the box, that file doesn't exist either in moOdeOS (e.g., Raspberry Pi OS) or my Linux Mint laptop but obviously one can define it.

On your first point, I don't see how the country code can be retrieved from the router before the access point has been discovered.

Regards,
Kent

I'll add that command to the wifi config code block for upcoming 8.0.1

[UpsiUps]

I hate the Major version upgrades as I have to walk and find all my RPis in the house, plug th eSD card , burn a new one , plug the new one in and restart configuration ... Oh, last point has a significant improvement : backup and restore !

Excellent! and even a possibility to run my own restore script - more excellent !

I all mention that as there seems a small bug, that I have been faced during my upgrade procedure: I unwraped all backup-zips to grab the unique moodecfg.ini and throw them on the /boot partition. That worked very well and the players came up even with the NAS connected per NFS. I then restored using the zip file the rest.
... and then I had a duplication of my NAS Library as Library source. So it seems that restore adds the library regardless if this is already connected.

Workaround ist fast: just deleted the latest entry of the list. But maybe you want to proof, why the duplication is happening.

The Restore handles copying moodecfg.ini to /boot. You don't have to do it manually.

Not really: If you don't change the moodecfg.ini the system might get no IP and the hostname will be wrong. if you boot up multiple RPis you have the fun to find them on your local network.Only after that you could start the restore to fix things. So -IMHO- I think the sequence is better it is better to copy the moodecfg.ini before you boot up the first time. After that you start the restore to re-create your local radiostation etc.

The restore will also find the configuration moodecfg.ini and will restore it a second time. That should not be a problem. The only observation is, that the source entry was now duplicated. 

Maybe I missunderstood the restore process: is there a way to start the restore on a fresh image ? E.g. by store the backup...zip on the /boot partition ? I am currently only aware to start the restore after mood has started and you could use the browser UI to upload the backup.zip file.

In generic it is not a big issue. I would like to thank you that the major upgrade process is nowadays much easier than in the 5.x and less releases.

- Update - 
I reviewed the source and found the challenge :

Code:

.... line 188 of backupmanager.py ...      
if configPresent:
  print('config')
  content.append('config')

That's the reason, why the Source/Library entry is duplicated. Now, if I want to "restore" , why would i like to append it to the current moodecfg.ini ?  I would rather think I would like to overwrite the moodecfg.ini even if it is in place, nor ?

[Tim Curtis]

Right, the fresh image scenario needs moodecfg.ini in /boot.

Good points. I'll add to the TODO list to investigate.

-Tim

[Mr.R0b0t]

Any solution to my problem?

[Tim Curtis]

Any solution to my problem?

I wasn't able to repro it 
https://moodeaudio.org/forum/showthread....9#pid40189

But the log records below from your post #88 suggests that there is some sort of odd sample rate changes and buffer underruns happening.
https://moodeaudio.org/forum/showthread....8#pid40228

Code:

Mar 15 17:04:39.235 WARN sample rate change detected, last rate was 1087.3985895103685 Hz, module: camillalib::filedevice
Mar 15 17:04:39.244 WARN Prepare playback after buffer underrun, module: camillalib::alsadevice
Mar 15 17:04:40.301 WARN sample rate change detected, last rate was 61479.46345625691 Hz, module: camillalib::filedevice
Mar 15 17:04 : alsa_output: Decoder is too slow; playing silence to avoid xrun
CDSP Plugin ERROR: XRUN OCCURRED!

Mar 15 17:13 : alsa_output: Underrun on ALSA device "_audioout"
CDSP Plugin ERROR: XRUN OCCURRED!
Mar 15 17:13 : alsa_output: Underrun on ALSA device "_audioout"
CDSP Plugin ERROR: XRUN OCCURRED!
Mar 15 17:13 : alsa_output: Underrun on ALSA device "_audioout"
CDSP Plugin ERROR: XRUN OCCURRED!
Mar 15 17:13 : client: [6] process command "status"
Mar 15 17:13 : client: [6] command returned 0
Mar 15 17:13 : client: [6] process command "currentsong"
Mar 15 17:13 : client: [6] command returned 0
Mar 15 17:13 : client: [6] process command "playlistinfo "25""
Mar 15 17:13 : client: [6] command returned 0
Mar 15 17:13 : alsa_output: Underrun on ALSA device "_audioout"
CDSP Plugin ERROR: XRUN OCCURRED!

camilla error no sound after 3 sec

To troubleshoot try a fresh image on a bare Pi (No HAT board) with just Camilla turned on and set to whatever config  file you were using on the Pi thats producing the errors. Put some audio files on a USB drive or the SDCard and use these to test with. We don't want any NAS, UPnP or any other renderers turned on. No local display etc, etc. 

The test system needs to be as basic as possible so that in the event the issue occurs a repro might be possible.