Moode Audio Player for Raspberry Pi

michaelagiles · 2016-08-01 3:01 am

TimCurtis said:
Hi Kent,

Correct. Some history. Moode 2.5 used an app named usbmount to handle auto-mounting USB disks. Usbmount required fixed names for the mount points and thus the config was as follows:

MPD symlinks
/var/lib/mpd/music/USB --> /mnt/USB
/var/lib/mpd/music/USB2 --> /mnt/USB2
/var/lib/mpd/music/USB3 --> /mnt/USB3
/var/lib/mpd/music/USB4 --> /mnt/USB4

usbmount.conf
MOUNTPOINTS="/mnt/USB /mnt/USB2 /mnt/USB3 /mnt/USB4"

smb.conf
[USB]
path = /var/lib/mpd/music/USB
[USB2]
path = /var/lib/mpd/music/USB2
[USB3]
path = /var/lib/mpd/music/USB3
[USB4]
path = /var/lib/mpd/music/USB4

Example: Plugging in first USB disk results in it being mounted to /mnt/USB. Plug in second USB disk and its mounted to /mnt/USB2. Run MPD DB UPDATE and MPD indexes content of disks at /var/lib/mpd/music/USB --> /mnt/USB and /var/lib/mpd/music/USB2 --> /mnt/USB2.

1) This always resulted in free space being reported correctly since Samba share name referenced the USB disk root folder. This solution however had a couple of issues:

2) In the two disk example above, if we swap which USB ports the disks are plugged into and forget to re-run MPD DB UPDATE the MPD index will contain bad file paths.

3) Browse panel only showed USB - USB3 and not meaningful names.

Moode 2.6 uses udisks-glue to automount USB disks by their disk label to /media folder which fixes #2 and #3 above but seems to break #1 since the Samba share name no longer references the root folder of the disk but instead references parent folder /media.

Here is the current config:

MPD symlinks
/var/lib/mpd/music/USB --> /media

udisks-glue.conf
- this config file only specifies file system types and their mount options. Udisks-glue app by default mounts disks by their label to the /media folder.

smb.conf
[USB]
path = /var/lib/mpd/music/USB

Regards,
Tim

michaelagiles · 2016-08-01 3:04 am

Tim and Kent - I have the same issue - and I suspect that there is a solution in here somewhere! But darned if I can figure it out. Is there a way around this? I used to be able to add ripped and downloaded files to my USB HDD very easily - now its a problem!
Thanks! MG

TimCurtis · 2016-08-01 3:47 am

michaelagiles said:
Tim and Kent - I have the same issue - and I suspect that there is a solution in here somewhere! But darned if I can figure it out. Is there a way around this? I used to be able to add ripped and downloaded files to my USB HDD very easily - now its a problem!
Thanks! MG

Hi MG,

Connect directly to the subfolder of the USB share. For example if your USB disk is labeled MyDisk then connect as follows:

Windows

x: --> \\moode\USB\MyDisk

Mac

cifs://moode/USB/MyDisk

Regards,
Tim

ms2204 · 2016-08-01 8:06 pm

Problems with python script for controling amplifier from MoOde mpd status

Hi.

Im hoping someone can help me with this python script for MoOde, that doesn't do quite what it is supposed to.

The purpose is just a loop, that pulls the status from mpd and if MoOde is not playing, a counter starts to rise. When the counter reaches 4, it sets some GPIO pins, that trigers a relay, which then turns the Amplifier off. It then uses MPDClient.idle to wait for a response from mpd. When it gets a response, it switches the amplifier on again, and continues.

The problem is, that assuming, that MoOde is playing, when I start the script, the if statement (if counter >= 4) repeats twice, before the client.idle statement actually pauses and waits for a responce (the first time there is no pause). If I add a client.idle statement right after the if statement, the if statement repeats only once, and executes correctly.

While this is fine if MoOde is playing (although I fail to understand why), it does not work if Moode is not playing. Then it stops allready at the first client.idle statement, and again at the second, thus reversing the functionality.

Can anybody tell me, what I'm doing wrong here, and why the first client.idle statement is skipped, if MoOde is playing?????

Code:

# Import the libraries to use time delays, send os commands and access GPIO pins
# Script checks mpd status, and if status is not playing, after a certain time
# the script sets amplifier in standby and waits for idle to change, 
# whereafter it turns the amplifier on again  

import RPi.GPIO as GPIO 
import time 
import os 
import mpd 

RedLedPin = 13 #Indicates Standby
GreenLedPin = 15 #Indicates Playing
MainRelayPin = 11 #Drives Relay for mains to Amp
counter = 0
 
GPIO.setmode(GPIO.BOARD) # Set pin numbering to board numbering 
GPIO.setup(MainRelayPin, GPIO.OUT) # Setup pin MainRelayPin as an output 
GPIO.setup(RedLedPin, GPIO.OUT) # Setup pin RedLedPin as an output 
GPIO.setup(GreenLedPin, GPIO.OUT) # Setup pin GreenLedPin as an output 

client = mpd.MPDClient() # create client object 
client.connect("localhost", 6600) # connect to localhost:6600 

GPIO.output(MainRelayPin, GPIO.HIGH) 
GPIO.output(RedLedPin, GPIO.LOW)
GPIO.output(GreenLedPin, GPIO.HIGH) 

while True: # Setup a while loop 

    Status = client.status()
    counter = counter + 1
    print ("counter = {0}".format(counter))

    if Status['state'] == "play": # Reset counter if Moodeaudio is playing
        counter = 0
        print ("Reseting counter = {0}".format(counter))

    if counter >= 4:
        Id = client.idle('player') #This is the line that I don't understand, but if ommited the loop is circled twice before stopping at client.idle
        print "Entering idle loop"
        GPIO.output(MainRelayPin, GPIO.LOW)
        GPIO.output(GreenLedPin, GPIO.LOW)
        GPIO.output(RedLedPin, GPIO.HIGH)
        Id = client.idle('player') #Code waits here for a change response from mpd
        print Id #Just to know that mpd have exited idle state
        GPIO.output(MainRelayPin, GPIO.HIGH)
        GPIO.output(RedLedPin, GPIO.LOW)
        GPIO.output(GreenLedPin, GPIO.HIGH)
        counter = 0

    time.sleep(2) # Allow a sleep time of 2 seconds to reduce CPU usage

client.close() # send the close command
client.disconnect() # disconnect from the server

TheOldPresbyope · 2016-08-02 2:10 am

ms2204 said:
Hi.

Im hoping someone can help me with this python script for MoOde, that doesn't do quite what it is supposed to.

The purpose is just a loop, that pulls the status from mpd and if MoOde is not playing, a counter starts to rise. When the counter reaches 4, it sets some GPIO pins, that trigers a relay, which then turns the Amplifier off. It then uses MPDClient.idle to wait for a response from mpd. When it gets a response, it switches the amplifier on again, and continues.

The problem is, that assuming, that MoOde is playing, when I start the script, the if statement (if counter >= 4) repeats twice, before the client.idle statement actually pauses and waits for a responce (the first time there is no pause). If I add a client.idle statement right after the if statement, the if statement repeats only once, and executes correctly.

While this is fine if MoOde is playing (although I fail to understand why), it does not work if Moode is not playing. Then it stops allready at the first client.idle statement, and again at the second, thus reversing the functionality.

Can anybody tell me, what I'm doing wrong here, and why the first client.idle statement is skipped, if MoOde is playing?????

Code:

# Import the libraries to use time delays, send os commands and access GPIO pins # Script checks mpd status, and if status is not playing, after a certain time # the script sets amplifier in standby and waits for idle to change, # whereafter it turns the amplifier on again import RPi.GPIO as GPIO import time import os import mpd RedLedPin = 13 #Indicates Standby GreenLedPin = 15 #Indicates Playing MainRelayPin = 11 #Drives Relay for mains to Amp counter = 0 GPIO.setmode(GPIO.BOARD) # Set pin numbering to board numbering GPIO.setup(MainRelayPin, GPIO.OUT) # Setup pin MainRelayPin as an output GPIO.setup(RedLedPin, GPIO.OUT) # Setup pin RedLedPin as an output GPIO.setup(GreenLedPin, GPIO.OUT) # Setup pin GreenLedPin as an output client = mpd.MPDClient() # create client object client.connect("localhost", 6600) # connect to localhost:6600 GPIO.output(MainRelayPin, GPIO.HIGH) GPIO.output(RedLedPin, GPIO.LOW) GPIO.output(GreenLedPin, GPIO.HIGH) while True: # Setup a while loop Status = client.status() counter = counter + 1 print ("counter = {0}".format(counter)) if Status['state'] == "play": # Reset counter if Moodeaudio is playing counter = 0 print ("Reseting counter = {0}".format(counter)) if counter >= 4: Id = client.idle('player') #This is the line that I don't understand, but if ommited the loop is circled twice before stopping at client.idle print "Entering idle loop" GPIO.output(MainRelayPin, GPIO.LOW) GPIO.output(GreenLedPin, GPIO.LOW) GPIO.output(RedLedPin, GPIO.HIGH) Id = client.idle('player') #Code waits here for a change response from mpd print Id #Just to know that mpd have exited idle state GPIO.output(MainRelayPin, GPIO.HIGH) GPIO.output(RedLedPin, GPIO.LOW) GPIO.output(GreenLedPin, GPIO.HIGH) counter = 0 time.sleep(2) # Allow a sleep time of 2 seconds to reduce CPU usage client.close() # send the close command client.disconnect() # disconnect from the server

Just starting to feel my way around your code. I assume you used apt-get to load the python-mpd package from the raspbian repo.

Regards,
Kent

TimCurtis · 2016-08-02 3:11 am

ms2204 said:
Hi.

Im hoping someone can help me with this python script for MoOde, that doesn't do quite what it is supposed to.

The purpose is just a loop, that pulls the status from mpd and if MoOde is not playing, a counter starts to rise. When the counter reaches 4, it sets some GPIO pins, that trigers a relay, which then turns the Amplifier off. It then uses MPDClient.idle to wait for a response from mpd. When it gets a response, it switches the amplifier on again, and continues.

The problem is, that assuming, that MoOde is playing, when I start the script, the if statement (if counter >= 4) repeats twice, before the client.idle statement actually pauses and waits for a responce (the first time there is no pause). If I add a client.idle statement right after the if statement, the if statement repeats only once, and executes correctly.

While this is fine if MoOde is playing (although I fail to understand why), it does not work if Moode is not playing. Then it stops allready at the first client.idle statement, and again at the second, thus reversing the functionality.

Can anybody tell me, what I'm doing wrong here, and why the first client.idle statement is skipped, if MoOde is playing?????

Code:

# Import the libraries to use time delays, send os commands and access GPIO pins # Script checks mpd status, and if status is not playing, after a certain time # the script sets amplifier in standby and waits for idle to change, # whereafter it turns the amplifier on again import RPi.GPIO as GPIO import time import os import mpd RedLedPin = 13 #Indicates Standby GreenLedPin = 15 #Indicates Playing MainRelayPin = 11 #Drives Relay for mains to Amp counter = 0 GPIO.setmode(GPIO.BOARD) # Set pin numbering to board numbering GPIO.setup(MainRelayPin, GPIO.OUT) # Setup pin MainRelayPin as an output GPIO.setup(RedLedPin, GPIO.OUT) # Setup pin RedLedPin as an output GPIO.setup(GreenLedPin, GPIO.OUT) # Setup pin GreenLedPin as an output client = mpd.MPDClient() # create client object client.connect("localhost", 6600) # connect to localhost:6600 GPIO.output(MainRelayPin, GPIO.HIGH) GPIO.output(RedLedPin, GPIO.LOW) GPIO.output(GreenLedPin, GPIO.HIGH) while True: # Setup a while loop Status = client.status() counter = counter + 1 print ("counter = {0}".format(counter)) if Status['state'] == "play": # Reset counter if Moodeaudio is playing counter = 0 print ("Reseting counter = {0}".format(counter)) if counter >= 4: Id = client.idle('player') #This is the line that I don't understand, but if ommited the loop is circled twice before stopping at client.idle print "Entering idle loop" GPIO.output(MainRelayPin, GPIO.LOW) GPIO.output(GreenLedPin, GPIO.LOW) GPIO.output(RedLedPin, GPIO.HIGH) Id = client.idle('player') #Code waits here for a change response from mpd print Id #Just to know that mpd have exited idle state GPIO.output(MainRelayPin, GPIO.HIGH) GPIO.output(RedLedPin, GPIO.LOW) GPIO.output(GreenLedPin, GPIO.HIGH) counter = 0 time.sleep(2) # Allow a sleep time of 2 seconds to reduce CPU usage client.close() # send the close command client.disconnect() # disconnect from the server

Hi,

The most recent Moode update added MPD 'state' to currentsong.txt. You could parse this file in a loop and check the state. Moode worker.php loops at 3 sec intervals and among other things checks for changes in MPD state, song title and volume and then updates currentsong.txt.

pi@rp1:~ $ cat /var/www/currentsong.txt
file=http://ice1.somafm.com/groovesalad-128-mp3
artist=Radio station
album=Groove Salad: a nicely chilled plate of ambient beats and grooves. [SomaFM]
title=Sunburn In Cyprus - Your Smile (Sodapop Remix By Modo Azul)
coverurl=http://somafm.com/img3/groovesalad-400.jpg
track=
date=
composer=
encoded=VBR
volume=10
mute=0
state=play

Regards,
Tim

TimCurtis · 2016-08-02 3:21 am

Hi,

@TheOldPresbyope donated a Hifiberry DAC+Pro for the purpose of investigating the issue "Pi3 WiFi fails with DAC+Pro". Many thanks Kent

I was able to reproduce the issue on three virgin Raspbian Jessie Lite images as listed below.

2016-05-27 4.4.11
2016-05-10 4.4.9
2016-03-18 4.1.19

CONFIGURATION

1) Add the following to /boot/config.txt
dtoverlay=hifiberry-dacplus

2) Add the following to /etc/wpa_supplicant/wpa_supplicant.conf
network={
ssid="AirnetN2"
psk="the password"
}

FAILURE CASE

The telltale entries in syslog indicating failure to associate with AP. No ip address is assigned or APIPA address is assigned (see NOTE 1 below).

Aug 2 00:07:32 raspberrypi wpa_supplicant[498]: wlan0: Trying to associate with SSID 'AirnetN2'
Aug 2 00:07:33 raspberrypi wpa_supplicant[498]: wlan0: CTRL-EVENT-ASSOC-REJECT status_code=16

SUCCESS CASE

1) Remove the following in /boot/config.txt
dtoverlay=hifiberry-dacplus

Syslog entries indicating successful association with AP. Valid IP address is subsequently assigned.

Aug 2 00:27:10 raspberrypi wpa_supplicant[435]: wlan0: Trying to associate with SSID 'AirnetN2'
Aug 2 00:27:11 raspberrypi wpa_supplicant[435]: wlan0: Associated with 60:a4:4c:29:fa:d0
Aug 2 00:27:11 raspberrypi wpa_supplicant[435]: wlan0: WPA: Key negotiation completed with 60:a4:4c:29:fa:d0 [PTK=CCMP GTK=CCMP]
Aug 2 00:27:11 raspberrypi wpa_supplicant[435]: wlan0: CTRL-EVENT-CONNECTED - Connection to 60:a4:4c:29:fa:d0 completed [id=0 id_str=]

NOTES:

1) When the failure case occurs, a cold boot sometimes results in an APIPA (Automatic Private IP Addressing) 169... address being assigned. This will be unreachable from clients.

2) Pi3 + other dac boards including Hifiberry DAC+, no issues.

If anyone has a working config with a virgin Raspbian Jessie Lite image please post the config and I'll test.

Regards,
Tim

Bedlore · 2016-08-02 3:27 am

mRqS said:
You have to click on the cover in the library. It's not mouse over.

Marek
(via Tapatalk)

Yup, perhaps I misunderstood, I thought Tim indicated I could play albums, even genres from the Library, but I only have the capability to play tracks.

TimCurtis · 2016-08-02 3:36 am

Bedlore said:
Yup, perhaps I misunderstood, I thought Tim indicated I could play albums, even genres from the Library, but I only have the capability to play tracks.

Hi,

Very odd. Screen shot shows Genre that can be played, added.

-Tim

Zootalaws · 2016-08-02 3:39 am

TimCurtis said:
Hi Mike,

Looks pretty straight forward. Does this also replace the kernel driver 8188cu.ko?

-Tim

I don't believe so, but I can't be sure.

I've ordered a bunch of Pi3s, when I get them I will rebuild my Pi2 and go through the process again and take more notice

One question for you, does streaming radio use the same buffer/percent params as streaming NAS source content?

I'm getting NAS content fine, but radio dies within a couple of seconds. My MPD params are set at 8192k and 30%

I'm using an 8188-based micro USB adapter and the reception is for **** in my cave

TimCurtis · 2016-08-02 3:45 am

Zootalaws said:
I don't believe so, but I can't be sure.

I've ordered a bunch of Pi3s, when I get them I will rebuild my Pi2 and go through the process again and take more notice

One question for you, does streaming radio use the same buffer/percent params as streaming NAS source content?

I'm getting NAS content fine, but radio dies within a couple of seconds. My MPD params are set at 8192k and 30%

I'm using an 8188-based micro USB adapter and the reception is for **** in my cave

Hi Mike,

Network issue for sure and not MPD buffering, thats only for files AFIAK.

I compiled the alt hostapd and examined the makefile and it does not install a "driver.ko" so thats goodness. I have not tested with EDIMax yet but will get to it in a few days

-Tim

Zootalaws · 2016-08-02 4:08 am

TimCurtis said:
Hi,

@TheOldPresbyope donated a Hifiberry DAC+Pro for the purpose of investigating the issue "Pi3 WiFi fails with DAC+Pro". Many thanks Kent

I was able to reproduce the issue on three virgin Raspbian Jessie Lite images as listed below.

2016-05-27 4.4.11
2016-05-10 4.4.9
2016-03-18 4.1.19

CONFIGURATION

1) Add the following to /boot/config.txt
dtoverlay=hifiberry-dacplus

2) Add the following to /etc/wpa_supplicant/wpa_supplicant.conf
network={
ssid="AirnetN2"
psk="the password"
}

FAILURE CASE

The telltale entries in syslog indicating failure to associate with AP. No ip address is assigned or APIPA address is assigned (see NOTE 1 below).

Aug 2 00:07:32 raspberrypi wpa_supplicant[498]: wlan0: Trying to associate with SSID 'AirnetN2'
Aug 2 00:07:33 raspberrypi wpa_supplicant[498]: wlan0: CTRL-EVENT-ASSOC-REJECT status_code=16

SUCCESS CASE

1) Remove the following in /boot/config.txt
dtoverlay=hifiberry-dacplus

Syslog entries indicating successful association with AP. Valid IP address is subsequently assigned.

Aug 2 00:27:10 raspberrypi wpa_supplicant[435]: wlan0: Trying to associate with SSID 'AirnetN2'
Aug 2 00:27:11 raspberrypi wpa_supplicant[435]: wlan0: Associated with 60:a4:4c:29:fa:d0
Aug 2 00:27:11 raspberrypi wpa_supplicant[435]: wlan0: WPA: Key negotiation completed with 60:a4:4c:29:fa:d0 [PTK=CCMP GTK=CCMP]
Aug 2 00:27:11 raspberrypi wpa_supplicant[435]: wlan0: CTRL-EVENT-CONNECTED - Connection to 60:a4:4c:29:fa:d0 completed [id=0 id_str=]

NOTES:

1) When the failure case occurs, a cold boot sometimes results in an APIPA (Automatic Private IP Addressing) 169... address being assigned. This will be unreachable from clients.

2) Pi3 + other dac boards including Hifiberry DAC+, no issues.

If anyone has a working config with a virgin Raspbian Jessie Lite image please post the config and I'll test.

Regards,
Tim

I found this, which may help diagnose : https://www.raspberrypi.org/forums/viewtopic.php?f=66&t=140237

TL/DR: try changing the WiFi channel to 6 and see if the problem persists. Looks like it might be power related, when the BCM chip is operating at the edge of the wifi spectrum.

TimCurtis · 2016-08-02 4:12 am

Zootalaws said:
I found this, which may help diagnose : https://www.raspberrypi.org/forums/viewtopic.php?f=66&t=140237

TLR: try changing the WiFi channel to 6 and see if the problem persists. Looks like it might be power related, when the BCM chip is operating at the edge of the wifi spectrum.

Hi Mike,

Very odd that DAC+Pro board and driver is sensitive to a specific WiFi channel. How would users deal with that?

Other boards and drivers are OK.

-Tim

TheOldPresbyope · 2016-08-02 5:05 am

TimCurtis said:
Hi,

The most recent Moode update added MPD 'state' to currentsong.txt. You could parse this file in a loop and check the state. Moode worker.php loops at 3 sec intervals and among other things checks for changes in MPD state, song title and volume and then updates currentsong.txt.

pi@rp1:~ $ cat /var/www/currentsong.txt
file=http://ice1.somafm.com/groovesalad-128-mp3
artist=Radio station
album=Groove Salad: a nicely chilled plate of ambient beats and grooves. [SomaFM]
title=Sunburn In Cyprus - Your Smile (Sodapop Remix By Modo Azul)
coverurl=http://somafm.com/img3/groovesalad-400.jpg
track=
date=
composer=
encoded=VBR
volume=10
mute=0
state=play

Regards,
Tim

ms2204 This sounds like a good direction to go. When I experimented with your code, I ran into several issues. First, it's corrupt. Apparently, the two lines which begin

Code:

Id = client.idle('play

are supposed to be simply

Code:

Id = client.idle('play')

I commented out the first instance of this line and removed the SUBSYSTEM argument in the second. When I run my modified script, I see the idle method reporting multiple combinations of changes in state. For example, if I 1) run player, 2) start script, 3) pause player, and 4) resume player, I get the following output:

Code:

...
counter = 1
Reseting counter = 0
counter = 1
counter = 2
counter = 3
counter = 4
Entering idle loop
['playlist', 'player']    <---immediate report upon entering the if clause
counter = 1
counter = 2
counter = 3
counter = 4
Entering idle loop        <---hang here until play is resumed
['player']                <---then report
counter = 1
Reseting counter = 0
...

The documentation is ambiguous (what does "Waits until there is a noteworthy change" mean in terms of timing?) I'd have to pore through the mpd source code to understand the underlying state machine and the Python MPDClient code to understand the call-back mechanism. Can't say I'm eager to do that. Tim's suggestion sounds easier!

Regards,
Kent

TheOldPresbyope · 2016-08-02 5:27 am

TimCurtis said:
Hi Mike,

Very odd that DAC+Pro board and driver is sensitive to a specific WiFi channel. How would users deal with that?

Other boards and drivers are OK.

-Tim

What a can of worms this is turning out to be. Lots of variables, few good diagnostic tools, and the usual mishmash of Internet reports which suggest the old story of the blind men feeling the elephant. Good hunting!

Regards,
Kent

Bedlore · 2016-08-02 5:28 am

cbueche said:
Now I see the update CHECK link, and when I try it, it says I'm up-to-date and the "About" shows Release: 2.6 2016-06-07, Update: (2016-07-28). It needed two reboots to show the newest update (after the first one it had an empty update date).

Thank you cbuech, I also suffered from the non existent update check. Very helpful.

ms2204 · 2016-08-02 8:57 am

TheOldPresbyope said:
Just starting to feel my way around your code. I assume you used apt-get to load the python-mpd package from the raspbian repo.

Regards,
Kent

Yes sorry. I should have mentioned that. I used the package from:
https://pypi.python.org/pypi/python-mpd/

WGET https://pypi.python.org/packages/d3...0.tar.gz#md5=5b3849b131e2fb12f251434597d65635

tar -xvf python-mpd-0.3.0.tar.gz

cd python-mpd-0.3.0

python setup.py install

for the GPIO i use:

sudo su

wget http://sourceforge.net/projects/ras...eezy/python-rpi.gpio_0.6.2~wheezy-1_armhf.deb

dpkg -i python-rpi.gpio_0.6.2~wheezy-1_armhf.deb

The GPIO stuff works fine though, so for testing purposes it could just be commented out and replaced with print commands.

Perhaps I should also mention that the 2 second delay is also just for testing. For practical purposes it is great if the state is checked once a minute when MoOde is playing. On the other hand, when MoOde i not playing, the script needs to react almost instantaneously, because otherwise the music might be cut off by the delay. Which is why I’m trying to get the idle statement to work, because it reacts as soon as something starts to play and does not use a lot of CPU.

ms2204 · 2016-08-02 9:15 am

TimCurtis said:
Hi,

The most recent Moode update added MPD 'state' to currentsong.txt. You could parse this file in a loop and check the state. Moode worker.php loops at 3 sec intervals and among other things checks for changes in MPD state, song title and volume and then updates currentsong.txt.

pi@rp1:~ $ cat /var/www/currentsong.txt
file=http://ice1.somafm.com/groovesalad-128-mp3
artist=Radio station
album=Groove Salad: a nicely chilled plate of ambient beats and grooves. [SomaFM]
title=Sunburn In Cyprus - Your Smile (Sodapop Remix By Modo Azul)
coverurl=http://somafm.com/img3/groovesalad-400.jpg
track=
date=
composer=
encoded=VBR
volume=10
mute=0
state=play

Regards,
Tim

Hi Tim

Thanks for the suggestion. It would seem to work great when MoOde is playing something, because the script would only need to check once a minute probably, but if MoOde is idle and the amplifier is off. It needs to be able to turn on immediately, when something starts playing as not to cut off the start of the song.

To be able to do this, I would need to parse the file continuously without delay, when MoOde is not playing, which would use a lot of CPU and kind of defeat the purpose of the script.

This is the reason I’m trying to use the MPDClient.idle statement because it waits for a change so the code stops and resumes immediately.

For some reason, which still eludes me, the idle statement does not stop and wait the first time it is called, if moode is playing to begin with. If on the other hand MoOde is not playing. The idle statement works, and I can’t seem to figure out why.

TimCurtis · 2016-08-02 1:52 pm

TimCurtis said:
Hi,

@TheOldPresbyope donated a Hifiberry DAC+Pro for the purpose of investigating the issue "Pi3 WiFi fails with DAC+Pro". Many thanks Kent

I was able to reproduce the issue on three virgin Raspbian Jessie Lite images as listed below.

2016-05-27 4.4.11
2016-05-10 4.4.9
2016-03-18 4.1.19

CONFIGURATION

1) Add the following to /boot/config.txt
dtoverlay=hifiberry-dacplus

2) Add the following to /etc/wpa_supplicant/wpa_supplicant.conf
network={
ssid="AirnetN2"
psk="the password"
}

FAILURE CASE

The telltale entries in syslog indicating failure to associate with AP. No ip address is assigned or APIPA address is assigned (see NOTE 1 below).

Aug 2 00:07:32 raspberrypi wpa_supplicant[498]: wlan0: Trying to associate with SSID 'AirnetN2'
Aug 2 00:07:33 raspberrypi wpa_supplicant[498]: wlan0: CTRL-EVENT-ASSOC-REJECT status_code=16

SUCCESS CASE

1) Remove the following in /boot/config.txt
dtoverlay=hifiberry-dacplus

Syslog entries indicating successful association with AP. Valid IP address is subsequently assigned.

Aug 2 00:27:10 raspberrypi wpa_supplicant[435]: wlan0: Trying to associate with SSID 'AirnetN2'
Aug 2 00:27:11 raspberrypi wpa_supplicant[435]: wlan0: Associated with 60:a4:4c:29:fa:d0
Aug 2 00:27:11 raspberrypi wpa_supplicant[435]: wlan0: WPA: Key negotiation completed with 60:a4:4c:29:fa:d0 [PTK=CCMP GTK=CCMP]
Aug 2 00:27:11 raspberrypi wpa_supplicant[435]: wlan0: CTRL-EVENT-CONNECTED - Connection to 60:a4:4c:29:fa:d0 completed [id=0 id_str=]

NOTES:

1) When the failure case occurs, a cold boot sometimes results in an APIPA (Automatic Private IP Addressing) 169... address being assigned. This will be unreachable from clients.

2) Pi3 + other dac boards including Hifiberry DAC+, no issues.

If anyone has a working config with a virgin Raspbian Jessie Lite image please post the config and I'll test.

Regards,
Tim

Hi,

Just a friendly bump.

Anyone have Pi3 integrated WiFi working with Hifiberry DAC+Pro?

-Tim

TheOldPresbyope · 2016-08-02 2:26 pm

ms2204 said:
Yes sorry. I should have mentioned that. I used the package from:
https://pypi.python.org/pypi/python-mpd/

WGET https://pypi.python.org/packages/d3...0.tar.gz#md5=5b3849b131e2fb12f251434597d65635

tar -xvf python-mpd-0.3.0.tar.gz

cd python-mpd-0.3.0

python setup.py install

for the GPIO i use:

sudo su

wget http://sourceforge.net/projects/ras...eezy/python-rpi.gpio_0.6.2~wheezy-1_armhf.deb

dpkg -i python-rpi.gpio_0.6.2~wheezy-1_armhf.deb

The GPIO stuff works fine though, so for testing purposes it could just be commented out and replaced with print commands.

Perhaps I should also mention that the 2 second delay is also just for testing. For practical purposes it is great if the state is checked once a minute when MoOde is playing. On the other hand, when MoOde i not playing, the script needs to react almost instantaneously, because otherwise the music might be cut off by the delay. Which is why I’m trying to get the idle statement to work, because it reacts as soon as something starts to play and does not use a lot of CPU.

I understand the reasoning behind your approach (although I don't know how instantaneously your amp can respond). We just don't know enough about what causes the idle() method to return.

I'm volunteering at Project Reboot all day today (we refurbish computers for the poor and disabled) and don't have time to experiment, but if I did, I'd first try extending your code to test whether the state is "play" when the idle() method returns and, if not, to reenter the idle() method. Usual caveats about getting locked in a loop apply.

As an alternative, one might stick a probe into Tim's code to trigger when it detects the user has selected "play", but I'm a php noob.

Regards,
Kent

Moode Audio Player for Raspberry Pi

Member

Member

Member

Member

Member

Member

Member

Member

Member

Attachments

Member

Member

Member

Member

Member

Member

Member

Member

Member

Member

Member