Moode Audio Player for Raspberry Pi

Thanks for the follow up. Clearly it's something wrong with my setup, but I cannot figure it out. Just to complicate matters further, one album (out of five) does display the album art correctly. I too am using r26-tr5.

Does anybody have additional ideas? If all else fails, I might just convert the WMAs to FLACs using foobar2000.

Thanks.

I take it you don't have trouble with the identical Moode/NAS lashup displaying cover art for FLAC files, whether it's embedded or a separate cover.jpg?

My immediate reaction is that conversion is an extreme solution but that's just me, especially since you mention one album works ( WMA files or FLAC files?).

I'd be inclined to suspect your NAS configuration, but again that's just me.

Gotta run. Will think more about this tonight.

Regards,
Kent
 
Tim:

I'm lazy. Sometimes when I'm done listening to my Moode Player I'll just leave it paused for a long time rather than shutting it down. I've noticed the following behavior:

1) RPi3, HiFiBerry DAC+ audio out, internal WiFi connection (host 192.168.1.24). Ran all night in "pause" mode with Chromium browser connected from host 192.168.1.175.

A line like this one is recorded to /var/log/nginx/error.log roughly once an hour
Code:
2016/05/26 03:32:39 [error] 723#0: *281 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 192.168.1.175, server: , request: "GET /engine-mpd.php?state=stop&_=1464244361225 HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "192.168.1.24", referrer: "http://192.168.1.24/index.php"

While the player is in "play" mode, these don't appear. Roughly the time I clicked "play" this morning, which happened to be just after the last time-out message at 09:38:52, I got a different message to /var/log/nginx/error.log
Code:
2016/05/26 09:33:07 [error] 723#0: *281 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 192.168.1.175, server: , request: "GET /engine-mpd.php?state=stop&_=1464269583957 HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "192.168.1.24", referrer: "http://192.168.1.24/index.php"

What's interesting is that /var/log/moode.log shows the following message with the same time stamp
Code:
20160526 093307 watchdog: PHP restarted, fpm child limit 18 exceeded

I first noticed this yesterday morning but, oops, lost the moode.log info when I restarted the system.

2) RPi2B, USB audio out, Canakit WiFi adapter. Roughly same nginx behavior but I have not seen the child-limit message.

Both systems running R26-TR5. Besides the differences in hardware, the second system is 3 feet away from the Access Point, while the first is perhaps 20 feet away with obstructions. Haven't had time to reverse their positions as a test.

This is nothing urgent, just more forensic information to add to your pile (!) of notes.

Regards,
Kent

PS - I'm experimenting with rsyslog configuration to discard some annoying messages which unnecessarily fill the logs---one is the useless pcm512x module (for the HiFiBerry DAC+) warning there is no SCLK every time I start a selection, the other is the dhclient message set every 4 minutes about DHCP activity on my unconnected eth0 interface. This latter apparently is a result of us using the "allow-hotplug" option and has been complained about in various Debian forums for years. I could simply take the eth0 down by one means or another, but that seems extreme. I might actually need it while the system is up.
 
Tim:

I'm lazy. Sometimes when I'm done listening to my Moode Player I'll just leave it paused for a long time rather than shutting it down. I've noticed the following behavior:

1) RPi3, HiFiBerry DAC+ audio out, internal WiFi connection (host 192.168.1.24). Ran all night in "pause" mode with Chromium browser connected from host 192.168.1.175.

A line like this one is recorded to /var/log/nginx/error.log roughly once an hour
Code:
2016/05/26 03:32:39 [error] 723#0: *281 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 192.168.1.175, server: , request: "GET /engine-mpd.php?state=stop&_=1464244361225 HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "192.168.1.24", referrer: "http://192.168.1.24/index.php"

While the player is in "play" mode, these don't appear. Roughly the time I clicked "play" this morning, which happened to be just after the last time-out message at 09:38:52, I got a different message to /var/log/nginx/error.log
Code:
2016/05/26 09:33:07 [error] 723#0: *281 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 192.168.1.175, server: , request: "GET /engine-mpd.php?state=stop&_=1464269583957 HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "192.168.1.24", referrer: "http://192.168.1.24/index.php"

What's interesting is that /var/log/moode.log shows the following message with the same time stamp
Code:
20160526 093307 watchdog: PHP restarted, fpm child limit 18 exceeded

I first noticed this yesterday morning but, oops, lost the moode.log info when I restarted the system.

2) RPi2B, USB audio out, Canakit WiFi adapter. Roughly same nginx behavior but I have not seen the child-limit message.

Both systems running R26-TR5. Besides the differences in hardware, the second system is 3 feet away from the Access Point, while the first is perhaps 20 feet away with obstructions. Haven't had time to reverse their positions as a test.

This is nothing urgent, just more forensic information to add to your pile (!) of notes.

Regards,
Kent

PS - I'm experimenting with rsyslog configuration to discard some annoying messages which unnecessarily fill the logs---one is the useless pcm512x module (for the HiFiBerry DAC+) warning there is no SCLK every time I start a selection, the other is the dhclient message set every 4 minutes about DHCP activity on my unconnected eth0 interface. This latter apparently is a result of us using the "allow-hotplug" option and has been complained about in various Debian forums for years. I could simply take the eth0 down by one means or another, but that seems extreme. I might actually need it while the system is up.

Hi Kent,

Nice log analysis. There are various timeouts in the system.

- NGINX configured for 1 hour connection timeout
- PHP configured for 30 sec execution timeout and 60 sec connection timeout.
- MPD idle state suspends connection timeouts

Note that in engine-mpd.php when PHP makes the specific connection to MPD for entering idle state the socket timeout is set to 600000 secs (7 days) so PHP does not time out the socket at the default 60 sec mark and thus from a practical perspective allows MPD to remain in idle state "forever".

The condition "fpm child limit 18 exceeded" is somewhat rare but can happen when there are multiple clients running the UI. The condition can also be forced by rapidly refreshing Browser so that the number of instances of engine-mpd.php stays ahead of PHP killing off the idle ones every 10 secs.

The pcm512x messages I think come from the device driver so probably not much that can be done. You will also see red messages in DMESG from i2s and wlan drivers. From what I understand these are debug messages left in by the dev's and probably should be removed in newer releases.

And as for unconfigured eth0 asking for DHCP at regular intervals, it could be avoided by automatically downing the adapter during startup in worker.php if worker determined that eth0 was not being used, or alternatively providing a System config setting to manually down the adapter.

I think its better to have eth0 always available since the periodic DHCP requests have no real impact on performance. Maybe there is a way to increase the period.

Regards,
Tim
 
Hi,

Below is final bugfix/update list for the TR's up to and including TR5. There is one unresolved issue with samba in the 2016-05-10 Jessie-Lite release that TR5 is based on that causes connections to the Moode samba shares to fail when using newer versions of Windows or Mac OS X. WIndows 7 connections to the shares works ok. I'm not planning to regress the samba version to the earlier one but rather release 2.6 with the issue and wait for next J-Lite release which should have issue fixed and then use this for Moode 2.7

1) FIX: etc/dhcpcd.conf static wlan0 address not commented out on fresh image
2) FIX: incorrect worker log message when eth0 does not exist
3) FIX: cfg_radio missing 1st record
4) FIX: lib/systemd/system/mpd.service and .socket have +x 0755 and should be 0644
5) FIX: WiFi "No security" setting causing connection to fail

1) UPD: MPD socket connection handling
2) UPD: USB audio hot-plug management

NOTES:

Update #1 uses some of AndiG's nice socket handling code from Moode 3 prototype and will probably fix a few issues including the rare php-cpu-hog condition.

Update #2 is a greatly simplified handler for USB audio hot-plug made possible by upd #5.

Regards,
Tim
 
Hi,
There is one unresolved issue with samba in the 2016-05-10 Jessie-Lite release that TR5 is based on that causes connections to the Moode samba shares to fail when using newer versions of Windows or Mac OS X. WIndows 7 connections to the shares works ok.

Odd one. I've had no problems connecting to my Moodey Pi from from Windows 10.

Phil
 
I'd be inclined to suspect your NAS configuration, but again that's just me.

Regards,
Kent

It's clearly something to do with my NAS configuration. If I copy all of the misbehaving albums to a USB drive and mount that directly on the Pi then all of album art displays correctly. I cannot figure out the basis of the problem when the files are served from the NAS which is a Netgear ReadyNAS Duo v2 in case that helps with prompting suggestions.

Many thanks,

Raymond
 
Thanks for the follow up. Clearly it's something wrong with my setup, but I cannot figure it out. Just to complicate matters further, one album (out of five) does display the album art correctly. I too am using r26-tr5.

Does anybody have additional ideas? If all else fails, I might just convert the WMAs to FLACs using foobar2000.

Thanks.

[[Sorry, folks, the limited functionality of the "quote in reply" option makes it too hard to maintain a running summary of a subthread. You'll just have to keep up <grin>.]]

After a series of experiments, I've convinced myself there are subtle differences in the way Moode Player (or more likely the plugins in the MPD server at the core of Moode Player) deals with album art associated with WMA and MP3 files.

case 1: take some WMA files which have neither text tags nor embedded album art, put them in a folder on my NAS, update the MPD DB, point Moode Player at the folder, and hit "clear/play". It plays the WMA files while displaying the default "moOde audio player" graphic.

case 2: add an image file named Folder.jpg to the folder containing the WMA files. Try various things to update Moode just in case. Now Moode player displays this image while playing the WMA files.

case 3: start over again with a new set of WMA files which do have text tags and embedded album art, put them in a folder on my NAS, update the MPD DB, point Moode Player at the folder, and hit "clear/play". It plays the WMA files while displaying their embedded album art.

case 4: add an image file named Folder.jpg to the folder containing these new WMA files. Try various things to update Moode just in case. Now Moode player displays this image while playing the WMA files, *despite* the fact that the individual files still have their own embedded album art (or if they have none, as in the first trial I reported to leicray).

case 5: delete the Folder.jpg file, repeat the various things to update just in case, and --- uh oh --- now Moode player displays the default "moOde audio player" graphic while playing the WMA files, again *despite* the fact that the individual files still have their own embedded album art.

At this point I don't seem to be able to do anything which will restore my folder to case 3. I can however, reliably alternate between case 4 and case 5. Seriously, I've cleared caches, updated MPD DB, restarted the NAS, the PC, the Moode Player, yada yada yada. If there's a magic combination to clear all relevant caches I missed, then in my opinion it's too complicated to belong in an "appliance." (To be honest, I didn't think these actions would make any difference, but I didn't want to leave the door open.)

Contrast this to my test cases with MP3 handling. Moode player, while playing my test MP3 files, displays the embedded album art if it is present, else the Folder.jpg image if it is present, else the default "moOde audio player" image, regardless of the order in which I do things. I confess I haven't tested as thoroughly with MP3 as with WMA and didn't even consider FLAC but that's just because I'm growing weary of all the clicking, typing, and, um, swearing.

Until liecray first reported his difficulty, I had worked only with MP3 and FLAC files, already prepped with metadata including embedded album art, organized into folders with appropriate Folder.jpg files, and then copied to my NAS. Everything "just worked". It's clear to me in retrospect that the combination of my workflow and my choice of encoding/file format probably minimized my risk of falling into similar difficulty. Blissful ignorance!

Regards,
Kent
 
[[Sorry, folks, the limited functionality of the "quote in reply" option makes it too hard to maintain a running summary of a subthread. You'll just have to keep up <grin>.]]

After a series of experiments, I've convinced myself there are subtle differences in the way Moode Player (or more likely the plugins in the MPD server at the core of Moode Player) deals with album art associated with WMA and MP3 files.

case 1: take some WMA files which have neither text tags nor embedded album art, put them in a folder on my NAS, update the MPD DB, point Moode Player at the folder, and hit "clear/play". It plays the WMA files while displaying the default "moOde audio player" graphic.

case 2: add an image file named Folder.jpg to the folder containing the WMA files. Try various things to update Moode just in case. Now Moode player displays this image while playing the WMA files.

case 3: start over again with a new set of WMA files which do have text tags and embedded album art, put them in a folder on my NAS, update the MPD DB, point Moode Player at the folder, and hit "clear/play". It plays the WMA files while displaying their embedded album art.

case 4: add an image file named Folder.jpg to the folder containing these new WMA files. Try various things to update Moode just in case. Now Moode player displays this image while playing the WMA files, *despite* the fact that the individual files still have their own embedded album art (or if they have none, as in the first trial I reported to leicray).

case 5: delete the Folder.jpg file, repeat the various things to update just in case, and --- uh oh --- now Moode player displays the default "moOde audio player" graphic while playing the WMA files, again *despite* the fact that the individual files still have their own embedded album art.

At this point I don't seem to be able to do anything which will restore my folder to case 3. I can however, reliably alternate between case 4 and case 5. Seriously, I've cleared caches, updated MPD DB, restarted the NAS, the PC, the Moode Player, yada yada yada. If there's a magic combination to clear all relevant caches I missed, then in my opinion it's too complicated to belong in an "appliance." (To be honest, I didn't think these actions would make any difference, but I didn't want to leave the door open.)

Contrast this to my test cases with MP3 handling. Moode player, while playing my test MP3 files, displays the embedded album art if it is present, else the Folder.jpg image if it is present, else the default "moOde audio player" image, regardless of the order in which I do things. I confess I haven't tested as thoroughly with MP3 as with WMA and didn't even consider FLAC but that's just because I'm growing weary of all the clicking, typing, and, um, swearing.

Until liecray first reported his difficulty, I had worked only with MP3 and FLAC files, already prepped with metadata including embedded album art, organized into folders with appropriate Folder.jpg files, and then copied to my NAS. Everything "just worked". It's clear to me in retrospect that the combination of my workflow and my choice of encoding/file format probably minimized my risk of falling into similar difficulty. Blissful ignorance!

Regards,
Kent

Hi Kent,

#3 can't happen because Zend media plugin that is used by coverart.php module to extract cover art does not support WMA format. Take a look at /var/www/coverart.php. U were experiencing "cache not really being cleared syndrome".

WMA is sort of a zombie format anyway. Thankfully MPD can still decode it.

-Tim
 
It's clearly something to do with my NAS configuration. If I copy all of the misbehaving albums to a USB drive and mount that directly on the Pi then all of album art displays correctly. I cannot figure out the basis of the problem when the files are served from the NAS which is a Netgear ReadyNAS Duo v2 in case that helps with prompting suggestions.

Many thanks,

Raymond

Actually, after the testing I just reported, I think I was too quick to blame the NAS configuration in and of itself [1] but it's going to take some more work, or some insight from Tim, or both to figure out what's going on. Now that you mention it, I should have repeated my test cases using a directly connected USB drive.

At the time of my first reply, I was thinking this might be a permissions/ACL issue, but that doesn't square with the results of my test case sequence 3/4/5 nor with the differences I observed between WMA and MP3 files. As well, during this testing, I was always able to access the same WMA files on the NAS from another host running, say, VLC player and see the embedded album art as the files play, so involvement of Moode/MPD seems indicated. What I also didn't do was bring up MPD on a regular Linux host and see if it exhibits the same behavior.

Isn't this fun !?!

Regards,
Kent

[1] My late wife used to complain that I sound like I know what I'm talking about even when I didn't. This may have annoyed her but it was considered an asset by my upper management, especially when it came time to pitch research projects to prospective sponsors!
 
Hi Kent,

#3 can't happen because Zend media plugin that is used by coverart.php module to extract cover art does not support WMA format. Take a look at /var/www/coverart.php. U were experiencing "cache not really being cleared syndrome".

WMA is sort of a zombie format anyway. Thankfully MPD can still decode it.

-Tim

Whoa. That's the trouble with trying to do naive black-box testing. I feel like one of the proverbial blind men feeling the elephant. It might be a blessing if MPD simply dropped the ability to decode WMA, but you didn't hear it from me ;)

Thanks for setting me straight.

Regards,
Kent
 
Hi Tim,

I've got Moode Audio Player (2.6 Test Release 4) installed and working on my Raspberry Pi 3, with Kazoo on Windows and iPad as the control point and Minimserver running on a QNAP NAS.

I want to use the Openhome multi-room feature to sync the Pi with my Linn DS, with the Linn DS as the master. Should this work as I'm having some problems?

Kazoo on Windows shows the Pi renderer but without the group button underneath it.

Kazoo on iPad shows the Pi renderer with the group button, but only the option of having my main system play what the Pi is playing. Selecting this causes Kazoo to crash and is actually the opposite of what I want, as I want the Pi to play what the main system is playing.

Thanks
Paul
 
Accessing NAS via NFS

Have Pi 3 connected to wifi and it works great except I am unable to access the music files on Synology NAS. The error message seems to indicate that NAS is looking for certain credentials i. e. account name and password. At least I think that is the issue. I have included a couple of screen shots and would like some comments and suggestions on how to solve connection between Pi 3 and NAS. Thanks


MAC OSx
Synology DS415play
Pi 3
Hifi berry DAC Pro
Moode TR5
 

Attachments

  • Screen Shot 2016-05-28 at 7.10.10 AM.png
    Screen Shot 2016-05-28 at 7.10.10 AM.png
    87 KB · Views: 165
  • Screen Shot 2016-05-28 at 7.13.55 AM.png
    Screen Shot 2016-05-28 at 7.13.55 AM.png
    55.9 KB · Views: 152