Moode Audio Player for Raspberry Pi

Moode is working well here, but I have a question.

Using RPi/Moode as an AP with an Android phone. Phone connects to Moode SSID with no problem, Moode UI works, plays tunes, etc. However, after a period of about an hour or so, the phone will often disconnect from the Moode, whether Moode is playing music or not. All I have to do to reconnect is go to the network settings in the phone, tell the phone to reconnect, and it does so with no problems.

When the phone loses connection to the Moode SSID, the Moode UI does not shut off or stop playing, it just won't respond to input (won't open settings, stop, ff/rw, etc.) until the network connection has been restored.

Any ideas why this behavior occurs? It's probably a setting in the phone, but perhaps this is a known issue with known causes/solution?

Thanks.
--
 
Last edited:
Moode is working well here, but I have a question.

Using RPi/Moode as an AP with an Android phone. Phone connects to Moode SSID with no problem, Moode UI works, plays tunes, etc. However, after a period of about an hour or so, the phone will often disconnect from the Moode, ...
Thanks.
--

This isn't much information [1], rongon, but first...

have you tried to isolate the problem to either the phone or the RPi/Moode/AP? For example, do you have access to any other WiFi AP, and if so, once associated with it does your phone stay connected it for longer periods? Do you have any other WiFi-capable device, like a laptop or tablet, which you can associate with your RPi/Moode/AP and, if so, does it stay connected for longer periods?

I run 3 different Android devices here (all Android 6.x or 7.x) with zero problems, but I run Moode in AP mode only long enough to configure it as a client on my home WiFi network, so I have no data relevant to your time scale of "an hour or so".

Regards,
Kent

[1] you know, like what version of Moode, what model RPi, what WiFi adapter, what model phone, what version of Android, other apps running on the phone, signal path and obstacles in it, whether your phone is stationary or moving, yada yada yada. Note: You can run Android apps akin to "WiFi Analyzer" to get a feel for your received signal; I think some even show the signal level over time.
 
Thanks for the reply.

Re: [1] -- phone is a Motorola Moto E (2nd gen) running Android 5.1 (highest level that can be run on this phone). Moode 3.1 on an RPi 3 model B (the kind with the built in WiFi). The audio interface is a lowly Behringer UCA-202.

The phone is right next to the Pi. Line of sight, no obstacles. Phone is stationary. Plugged in and charging, or not connected to USB power, makes no difference. This is in an office in which everybody has smartphones, with a couple of WiFi networks running. I made the phone 'forget' the office WiFi (erased its password).
______________________

I have an older tablet at home, running Android 4.4.1. I'll connect to the Moode AP from that one too, to compare (this evening). Perhaps the tablet will drop the same way, perhaps it won't.

I can config my PC to be an AP/hotspot and see if the phone connects/drops.

I'll connect the RPi/Moode to my home router's WiFi network and see if it drops that connection after a while.

I know the RPi/Moode connects without interruption to the home network through Ethernet (I've been transferring files that way over the last week or so).

Thanks for the testing ideas. I'll report back.
--
 
Hi,

International shipping to 28 countries is now available for MoodeCase :) The service is USPS Commercial $18 USD with delivery avg 4-7 days from entry.

-Tim

Countries:

Australia
Belgium
Brazil
Canada
Croatia
Denmark
Estonia
Finland
France
Germany
Gibraltar
Great Britain
Hong Kong
Hungary
Ireland
Israel
Italy
Latvia
Lithuania
Luxembourg
Malaysia
Malta
Netherlands
New Zealand
Portugal
Singapore
Spain
Sweden
Switzerland
 

Attachments

  • moodecase-r10-intl-shipping.png
    moodecase-r10-intl-shipping.png
    201.4 KB · Views: 276
forked-daapd pulse audio <> moode

Dear Tim,

I have tested Moode and Volume and definitely prefer Moode!
I would like to use Moode on the same RPi 3 alongside forked-daapd. See: https://www.raspberrypi.org/forums/viewtopic.php?t=49928
Forked-daapd is handy as it is compatible with iTunes on my mac, iPad and iPhone. Forked-daapd however requires PulseAudio.

I have a couple of questions:
- can I use the 2 softwares on the same Pi?
- can I run Moode Audio with pulse audio?
- can i setup moode from the command line (using the terminal)?

Thank you and compliments on a great job!

Fred
 
Dear Tim,

I have tested Moode and Volume and definitely prefer Moode!
I would like to use Moode on the same RPi 3 alongside forked-daapd. See: https://www.raspberrypi.org/forums/viewtopic.php?t=49928
Forked-daapd is handy as it is compatible with iTunes on my mac, iPad and iPhone. Forked-daapd however requires PulseAudio.

I have a couple of questions:
- can I use the 2 softwares on the same Pi?
- can I run Moode Audio with pulse audio?
- can i setup moode from the command line (using the terminal)?

Thank you and compliments on a great job!

Fred

Hi Fred,

What is the usage scenario?

-Tim
 
Hi Tim,

My digital CD collection is on a NAS. On this NAS i have 2 NFS shares with music in FLAC format.

Moode Audio as well as Forked-daapd are installed on the Pi3. The Pi3 connects to the NAS to access my FLAC libraries. The libraries are shared via NFS.

When working on iMacs or Macbook I use iTunes to access my music libraries, via forked-daapd. When Playing music on my stereo I use Moode to play music via the Aune DAC. The DAC is connected to my stereo. Airplay on Moode allows visitors to play Music via the stereo.

Hope this clarifies the set-up.

Thank you.

Tjerk
 
Hi,

I made the switch from volumio to moode and I'm really pleased with it.
One thing that I'm missing is a dedicated sleep timer.
I currently using the "clock radio" feature for it, but I find that a bit cumbersome.
Also a 24h format for the time would be nice.

Best regards,
Holger
 
Hi Tim,

My digital CD collection is on a NAS. On this NAS i have 2 NFS shares with music in FLAC format.

Moode Audio as well as Forked-daapd are installed on the Pi3. The Pi3 connects to the NAS to access my FLAC libraries. The libraries are shared via NFS.

When working on iMacs or Macbook I use iTunes to access my music libraries, via forked-daapd. When Playing music on my stereo I use Moode to play music via the Aune DAC. The DAC is connected to my stereo. Airplay on Moode allows visitors to play Music via the stereo.

Hope this clarifies the set-up.

Thank you.

Tjerk

Hi Tjerk,

Why not just configure iTunes to directly access your music collection on NAS?

Then you could play it through Moode Airplay receiver, or just use Moode UI.

-Tim
 
quick question: if I want to use Moode with LMS through squeezelite, do I only have to enable "Squeezelite renderer" in the Audio config, or is there anything else?

Somehow it's not discovered by the LMS

Hi,

Correct, just turn on Squeezelite renderer.

To verify its running, use cmd below.

pi@rp3:~ $ pgrep -l squeezelite
14903 squeezelite-arm

I just ran quick test and no issues discovering renderer and playing songs. I'm using LMS on Mac.

-Tim
 
Hi,

I made the switch from volumio to moode and I'm really pleased with it.
One thing that I'm missing is a dedicated sleep timer.
I currently using the "clock radio" feature for it, but I find that a bit cumbersome.
Also a 24h format for the time would be nice.

Best regards,
Holger

Hi,

Sleep timer has been on my TODO list for a long time but keeps getting bumped by a huge number of higher priority items. Maybe someone will contrib the code.

-Tim
 
Hi,

Correct, just turn on Squeezelite renderer.

To verify its running, use cmd below.

pi@rp3:~ $ pgrep -l squeezelite
14903 squeezelite-arm

I just ran quick test and no issues discovering renderer and playing songs. I'm using LMS on Mac.

-Tim

Thanks Tim - it doesn't seem to be running. How can I debug this? It's an old Pi I had lying around, one of the first versions. Playback works normally though
This might be related: Jan 5 02:39:28 moode squeezelite-armv6l[824]: [02:39:28.529806] output_init_common:351 unable to malloc output buffer
It's an older Pi 1
 
Last edited:
Thanks Tim - it doesn't seem to be running. How can I debug this? It's an old Pi I had lying around, one of the first versions. Playback works normally though
This might be related: Jan 5 02:39:28 moode squeezelite-armv6l[824]: [02:39:28.529806] output_init_common:351 unable to malloc output buffer
It's an older Pi 1

Hi,

I tested on Pi-1B 512 MB and no issues.

Open Audio config > Configure Squeezelite settings and try lowering Output buffers.

-Tim
 
what values do you recommend? I keep getting now:
Jan 5 08:38:22 moode systemd[1]: squeezelite-armv6l.service: main process exited, code=killed, status=9/KILL
Jan 5 08:38:22 moode systemd[1]: Unit squeezelite-armv6l.service entered failed state.

nevermind - that's the message caused by the restart I guess - it seems to be running now

what are meaningful/sufficient values to use?
 
what values do you recommend? I keep getting now:
Jan 5 08:38:22 moode systemd[1]: squeezelite-armv6l.service: main process exited, code=killed, status=9/KILL
Jan 5 08:38:22 moode systemd[1]: Unit squeezelite-armv6l.service entered failed state.

nevermind - that's the message caused by the restart I guess - it seems to be running now

what are meaningful/sufficient values to use?

Hi,

Output buffer values 40000:100000 seem to work fine on Pi-1B 512 MB which is the lowest hardware spec that I test on. They can also be bumped up on Pi models with 1GB RAM.

As far as going lower, I really don't know what would be best but below is explanation of the buffers from an old forum post.
http://www.diyaudio.com/forums/pc-b...le-music-server-player-os-66.html#post4093532

"There are two buffers - the first one stores the raw stream (compressed) audio, the second the decode audio. PCM is a special case as the process of decoding is just unpacking samples into the second buffer so they are in 32bit format which is used in the output thread, but this is only a special case of decoding. The decode process thread runs whenever there is enough data in the first buffer and enough free space in the second one.

So if you want to stream the whole file at the start then probably make the first one big and keep the second one smaller (defaults at 10 seconds). If you want to stream and decode the whole file at the start then make the second one big.

The second buffer is really only needed to allow crossfade to happen and to separate the high priority output thread from the rest of the processing. Note that it uses 8 bytes per sample (2x32bits) whereas the first buffer uses the native sample rate and so will use less memory for the same amount of audio."

-Tim