Official moOde 8 support thread

[Tim Curtis]

Ok got it.

[Tim Curtis]

Pi with the HifiBerry HD DAC.  Everything worked perfectly under M7 using Tim’s overlay fix.  But using same overlay and config in v8 gives me an ALSA error:

Failed to open "ALSA Default" (alsa); Failed to open ALSA device "_audioout": No such file or directory

Which log should I be looking into for clues?

I don’t know if this is relevant or not, but I swear v7 did not call the HD DAC an I2S dac, but v8 seems to automatically select that when I select the proper overlay. 

Thanks,
Mike

Version 8.0.0 or 8.0.1 ?

Works here with the version 8.0.1, but need one change in config.txt

Disable the onboard EEPROM by adding

force_eeprom_read=0

to your boot/config.txt file.

See the last comments:
https://github.com/raspberrypi/linux/issues/4898

The commit to kernel 5.15.25 makes no mention of needing this command in confix.txt. 
https://github.com/raspberrypi/linux/pull/4904

Is there a post in the Hifiberry Forum that can be referenced?

Also @Marrahm, you posted about the "DAC HD" (not the 2) giving an ALSA error. Is this a separate issue or were you actually referring to the "DAC 2 HD"?

-Tim

To my knowledge there is no post in the Hifiberry forum for that.
If you check the issue comments, config.txt modification is there.
https://github.com/raspberrypi/linux/issues/4898

It looks like there are two links mentioning the EEPROM setting.
https://www.hifiberry.com/docs/software/...ux-3-18-x/
https://www.hifiberry.com/blog/configura...linux-5-4/

Prolly best just to just automatically add the setting for all hifiberry cards.

[TheOldPresbyope]

Anyone tried Bluetooth functionality. Running 8.01 on RPI3B+ and getting following screen after scan. Same behaviour from terminal. Not the same behaviour that I had with 7.6.1 which worked as expected.

I can confirm.

@Tim Curtis

The information returned by bluetoothctl scan on seem to have changed between buster and bullseye. Sigh.

Regards,
Kent

I get this which seems pretty normal. IIRC sometimes the scan has to be run multiple times before names start appearing in the list.

Code:

...

Argh. I forgot 1) I'd turned off my usual BT devices and 2) moOde now detects BLE as well as Classic devices. So, when I scanned I detected a ton of BLE sensors I have salted around the house but no audio-related devices. A number of the BLE devices don't transmit an identifier so they show up only as MAC addresses, which is what led to my confusion.

Turning on my usual BT speaker and several moOde players' pairing agents, I now see them in the output but they're kind of "lost in the noise" of all the BLE devices.

This leads me to suggest one might want to make detection of BLE devices optional. I remember (now!) the circumstance which lead to BLE scanning being added, but I'd argue that most audio-related devices use Classic Bluetooth.

[NOTE to self: don't try to do a quick test just you are rushing out the door. Bound to go badly when you overlook details.]

Regards,
Kent

[Tim Curtis]

There is the setting below in /etc/bluetooth/main.conf

Code:

# Restricts all controllers to the specified transport. Default value
# is "dual", i.e. both BR/EDR and LE enabled (when supported by the HW).
# Possible values: "dual", "bredr", "le"
ControllerMode = dual

In moOde 7 it was set to "bredr".  It was just left as the default "dual" in 8 but could be changed. I'll run some tests tomorrow.

-Tim

[TheOldPresbyope]

There is the setting below in /etc/bluetooth/main.conf

Code:

# Restricts all controllers to the specified transport. Default value
# is "dual", i.e. both BR/EDR and LE enabled (when supported by the HW).
# Possible values: "dual", "bredr", "le"
ControllerMode = dual

In moOde 7 it was set to "bredr".  It was just left as the default "dual" in 8 but could be changed. I'll run some tests tomorrow.

-Tim

On the scale of things which need to be done, this is closer to a 1 than a 9

I had noticed the ControllerMode setting but not played with it. I'm not getting the result I expected changing it to bredr on a moOde 8 player. Here's the SCAN-for-devices output after rebooting

Code:

**
** 56-75-A3-61-0A-30
** GVH5075_E94A
** cc:04:b4:0d:4e:42
** 61-A4-09-B1-26-29
** 4E-BF-EB-39-DF-03
** GVH5075_04F6
** GVH5075_6E31
** 4D-12-36-F3-50-2D
** GVH5075_B970
** 41-2D-A1-12-74-21
** GVH5075_EA5B
**

While for a moOde 7 player on the same LAN

Code:

**
** m8zero2w Bluetooth
** m8pi3bplcd Bluetooth
** m8pi3a Bluetooth
** JBL Flip 2
**

If I change the moOde 8 player back to "dual" and reboot

Code:

*
** GVH5075_E94A
** GVH5075_B970
** m8pi3bplcd Bluetooth
** JBL Flip 2
** CM4 Bluetooth
** GVH5075_EA5B
** 56-75-A3-61-0A-30
** GVH5075_04F6
** cc:04:b4:0d:4e:42
** 41-2D-A1-12-74-21
** 4A-3D-8D-34-87-EA
** 5F-C5-4D-BB-C6-E0
** 70-04-25-2E-9C-A0
**

It missed several moOde players and there are actually 7 GVH5075 type sensors in the house so I know the detection is a bit rando. 

Repeating the moOde 8 scan a while later gets all the GVH5075 type sensors and no moOde players. Several players were missed when I repeated the scan on the moOde 7 player.

One thought: I have a number of RPis on the desk. I wonder if I'm getting some transceiver overloading from the proximity of so many sources. Sigh - one more thing to check.

Compare this to HomeAssistant, say, which I have running on an RPi4B on the same desk. It finds everything every time. I haven't figured out yet how they do it.

Regards,
Kent

[Tim Curtis]

I think HomeAssistant uses a Python based bluetooth implementation named pybluez https://github.com/pybluez/pybluez which according to the readme is "not under active development" :-0

It's a more sophisticated bluetooth wrapper than moOde uses.
https://github.com/home-assistant/core/b...tracker.py

The BASH script used in moOde is pretty old and just does bluetoothctl command/response type wrapper stuff. It prolly needs to be rewritten afresh by someone that really knows bluetooth. Maybe the HomeAssistant script can be modified to work in moOde ??

[Frank79]

I own an Hifiberry DAC2HD hat. I saw that closed thread about this hat.

But today, I read a mention of the Hifiberry DAC2HD on the release notes on github: https://github.com/moode-player/moode/bl...s.txt#L119


[color=var(--color-fg-default)]- UPD: Add mixer name exception for hifiberry dac2hd[/color]

What does that mean exactly? Is the DAC2HD finally supported? Downloaded the latest Moode release, but I can't seem to make it work... 

Any help would be appreciated. Thanks! 

[Tim Curtis]

There are multiple issues with supporting Hifiberry DAC2HD

1. If OS release uses 5.15.y kernel branch as does moOde 8 then DAC2HD requires 5.15.24 or later.
2. DAC2HD and other Hifiberry devices apparently store a device tree overlay in the board's EEPROM which is automatically read by Pi firmware during boot. If there is also a dtoverlay= in /boot/config.txt as is done by moOde for all I2S audio devices it will or may conflict with the overlay loaded from the audio board's EEPROM. This is because the EEPROM based overlay may not be compatible with newer kernels. The fix according to Hifiberry is to add "force_eeprom_read=0" to /boot/config.txt.
https://www.hifiberry.com/blog/configura...linux-5-4/
https://www.hifiberry.com/docs/software/...ux-3-18-x/

Note that no other manufacturer's audio cards require these configs. They all just support the explicit dtoverlay= setting in /boot/config.txt.

Upcoming moOde 8.0.2 release adds the "force_eeprom_read=0" for all Hifiberry cards / overlays listed in /boot/overlays.

-Tim

[Frank79]

The fix according to Hifiberry is to add "force_eeprom_read=0" to /boot/config.txt.

Thank you Tim. Haven't added any local server yet, but I can confirm this is working when using Spotify!

[s_mury]

Hi all,

I am having problems generating my library. It takes quite some minutes for the busy indicator to stop but there is still no music in the library. The thumbnail generation process seems to be working because I can see what it is doing using the View Status button. That also means it is not the NAS, which I also confirmed by going to the mount point on the pi.

If I use the update library command, I can see empty album folders appearing in the folder view but with no files in them.

Looking in the MPD log, I see file not found messages but the file is there in the mount folder. I can post logs this evening.

This may have been occurring before I updated to moode 8.0.1. It was my reason for updating but I didn't check it so extensively before the update.


The test sound file works.

Could you please advise how to troubleshoot this and which logs I should post?

Best wishes
Sean

Errors in the MPD log such as "File not found" can result from insufficient permissions on the file and all the containing directories.

MPD needs read permission to the files and read+execute permissions to all the parent directories.
https://mpd.readthedocs.io/en/latest/use...d-database

I found the problem. I needed to add vers=1.0 to the Sambda options. I don't know why this is since my router is supposed to support v3.

Perhaps connected to this, with version 8.0.1 I had to manually enter the path to the share.
If I remember correctly, in previous versions it was always found using the scan button.