Official moOde 8 support thread

[Tim Curtis]

Do you have one of these boards?

I have a raspberry pi 4 rev 1.5 that I received at the beginning of this month. I used the updated Raspbian boot files to launch moOde 7.6.1, but it would not boot with my Digi+ pro attached. According to hifiberry there are issues with power delivery to the HAT that keep it from booting with digi2 and Digi+ pro attached.

I thought maybe this was a software fix for that.

I returned the Digi+ pro to my Pi3 with moOde 7.6.1 and it's working flawlessly in my main system.

I have the Pi4 rev1.5, still running 7.6.1, working as a temporary player for my basement until either a new hifiberry digi board comes out that works with rev1.5 or until it gets fixed in software (which hifiberry does not believe is possible)

The EEPROM setting prevents the Pi from reading an EEPROM based driver overlay in the audio card which may conflict with the overlay specified in config.txt. It has no effect on power.

Maybe just try another brand like Allo DigiONE.

[philrandal]

Do you have one of these boards?

I have a raspberry pi 4 rev 1.5 that I received at the beginning of this month. I used the updated Raspbian boot files to launch moOde 7.6.1, but it would not boot with my Digi+ pro attached. According to hifiberry there are issues with power delivery to the HAT that keep it from booting with digi2 and Digi+ pro attached.

I thought maybe this was a software fix for that.

I returned the Digi+ pro to my Pi3 with moOde 7.6.1 and it's working flawlessly in my main system.

I have the Pi4 rev1.5, still running 7.6.1, working as a temporary player for my basement until either a new hifiberry digi board comes out that works with rev1.5 or until it gets fixed in software (which hifiberry does not believe is possible)

The EEPROM setting prevents the Pi from reading an EEPROM based driver overlay in the audio card which may conflict with the overlay specified in config.txt. It has no effect on power.

Maybe just try another brand like Allo DigiONE.

Or try it on 8.0.2 to see if that works.

[fdealexa]

Hello everybody,
since the functionality of the "loopback" option was released I have noticed some anomalies. After many tests, with various releases, software components, etc, I can now be sure that there is a problem related to enabling this option.
The last test I did today with a scratch configuration (8.0.2).
Configuration:
Raspberry pi: 4 - 4GB,
DAC hat: I tried with some cards,
no additional software components.
Symptom:
significant increase in CPU load and slight increase in memory occupation.
Repeatability:
with the "loopback" option set to "ON", starting to listen to a radio, the system freezes after some hours.
During this period of time, keeping under control with "TOP" you notice that the "MPD" process grows (in CPU and Memory occupation).
With the same configuration and the same radio station (Jazz24), but with the "loopback" in "OFF" the CPU and Memory load (even after 3 hours) remain stable at the same value.
It is essential that there are no pauses during playback: if you "pause" or "stop" or change the source, the problem clears up..
I tried to search if there was already a "thread" on this problem, but I did not find anything: please excuse me if I am wrong.
Please let me know if it is appropriate to open a different thread.
Thank you all for your attention and greetings,
Francesco

[cheapvega]

@cheapvega 

Re point #1, you can always enter directly the endpoint URL for the screen you want to reach in your browser. Example http://moode/snd-config.php (for a suitable value of “moOde” )

Regards,
Kent

This is an OK workaround when I connect through my laptop, but not really feasible for my touchscreen interface unless I am missing something.

1. Renderer overlays are an integral part of the renderer sub-system and cannot be removed. It wouldn't make sense anyway because a renderer is a separate playback application where it's control UI is an app on some other computer or mobile. MPD, the Library and the Configs are irrelevant when a renderer is active.

2. Those types of niche customizations would need to be done by either yourself or another developer thats interested in the same thing. Another avenue for getting some dev attention is if a lot of users expressed interest in your proposal.

1. OK, I am good with controlling stuff like play/last/next track via my phone or w/e. But do the volume/EQ settings in moOde apply to the renderer? It would be nice to have access to those settings without having to disconnect/reconnect the renderer (especially volume). And an overlay with album art and artist/track info would be nice as well. 

2. I'll do more research on that. I imagine there have to be other users pushing analog inputs through moOde.

The client app for a renderer controls volume. moOde automatically sets its own volume to 0dB when a renderer connects. This ensures overall volume is 0dB when client volume is at 100%.

EQ will sound same for MPD as for the renderers that support EQ. Read the heading text in the Equalizer section of Audio Config for which renderers support moOde EQ's.

Airplay cover art and metadata was unreliable in the implementation that was used some years back in moOde and so it was dropped. If a dev has a solution that works I'll be happy to take a look.

Is there anyway to keep the volume consistent when switching between, say, a renderer and Bluetooth? I would like to use moOde to control all media volume. I would rather have something like Spotify default to 100%/0dB and have moOde stay at a set volume if possible. 

The URL trick works for playing with EQ while a renderer is engaged so I can live with that workaround. I will only have to play with EQ once if at all.

[Tim Curtis]

Hello everybody,
since the functionality of the "loopback" option was released I have noticed some anomalies. After many tests, with various releases, software components, etc, I can now be sure that there is a problem related to enabling this option.
The last test I did today with a scratch configuration (8.0.2).
Configuration:
Raspberry pi: 4 - 4GB,
DAC hat: I tried with some cards,
no additional software components.
Symptom:
significant increase in CPU load and slight increase in memory occupation.
Repeatability:
with the "loopback" option set to "ON", starting to listen to a radio, the system freezes after some hours.
During this period of time, keeping under control with "TOP" you notice that the "MPD" process grows (in CPU and Memory occupation).
With the same configuration and the same radio station (Jazz24), but with the "loopback" in "OFF" the CPU and Memory load (even after 3 hours) remain stable at the same value.
It is essential that there are no pauses during playback: if you "pause" or "stop" or change the source, the problem clears up..
I tried to search if there was already a "thread" on this problem, but I did not find anything: please excuse me if I am wrong.
Please let me know if it is appropriate to open a different thread.
Thank you all for your attention and greetings,
Francesco

No issues on my end after 4 1/2 hours. 

   

Code:

pi@sig:~ $ moodeutl -m
^CU: 1.2 GHz | LOAD: 2% | TEMP: 46°C | RAM_USED: 20% | DISK_USED: 38% | DISK_FREE: 4.3G | FPM_POOL: 12 workers  

[fdealexa]

Hello everybody,
since the functionality of the "loopback" option was released I have noticed some anomalies. After many tests, with various releases, software components, etc, I can now be sure that there is a problem related to enabling this option.
The last test I did today with a scratch configuration (8.0.2).
Configuration:
Raspberry pi: 4 - 4GB,
DAC hat: I tried with some cards,
no additional software components.
Symptom:
significant increase in CPU load and slight increase in memory occupation.
Repeatability:
with the "loopback" option set to "ON", starting to listen to a radio, the system freezes after some hours.
During this period of time, keeping under control with "TOP" you notice that the "MPD" process grows (in CPU and Memory occupation).
With the same configuration and the same radio station (Jazz24), but with the "loopback" in "OFF" the CPU and Memory load (even after 3 hours) remain stable at the same value.
It is essential that there are no pauses during playback: if you "pause" or "stop" or change the source, the problem clears up..
I tried to search if there was already a "thread" on this problem, but I did not find anything: please excuse me if I am wrong.
Please let me know if it is appropriate to open a different thread.
Thank you all for your attention and greetings,
Francesco

No issues on my end after 4 1/2 hours. 

Code:

pi@sig:~ $ moodeutl -m
^CU: 1.2 GHz | LOAD: 2% | TEMP: 46°C | RAM_USED: 20% | DISK_USED: 38% | DISK_FREE: 4.3G | FPM_POOL: 12 workers  

Thank you very much, Tim, for your answer.
I have to investigate better to create something that could be replicated... any way, my situation is as follow:
Best regards and thanks,
Francesco


  Prove mpd01.zip (Size: 1.57 MB / Downloads: 4)

  Prove mpd02.zip (Size: 1.07 MB / Downloads: 2)

[Tim Curtis]

Here is with Jazz24 and Loopback on. No issues after almost 5 hours. It's fresh r802 on a Pi-3B+ playing though an old IQaudiIO Pi DAC+.

   

The system in my earlier post was an r801 -> r802 updated system running on an Allo USBridge SIG (Pi-CM3+) playing through an Allo Revolution USB DAC. 

Another system I have that uses Loopback is a Pi-4 1.1 2GB It functions as a dedicated Multiroom Sender and plays all day long.

[Pbnmjk]

Hello, how can I avoid the upsample to work in the original bitrate only?

I have my music in 24 bit, but it's upsampled to 32 to return to 24 in the DAC, obviously it's unnecessary.

Thank you in advance.

[Tim Curtis]

You DAC's USB interface might only accept 32-bit.

[Pbnmjk]

You DAC's USB interface might only accept 32-bit.

Ok, I understand... thank you for your time.