Moode Player Help

[struth]

I think Dab, like tv etc uses PIP's(programme information platform) for metadata. the internet streams might not

[killie99]

Hi Stuart,

The symptom "cannot access by name and must use ip address" suggests a configuration issue in the router or that the router does not include either DNS or mDNS name resolution services.

Moode WebUI is basically a web site accessed via standard http port 80. There are three urls that can be used to access Moode depending on how names are resolved on the network.

(1) http://moode
(2) http://moode.local
(3) http://IP-ADDRESS-OF-PI

For example on my home network, my router, an ASUS RT-N66U, includes a DNS name resolution service that automatically places the host name of the Pi in its database when the Pi receives its ip address from the router. This allows the router to resolve the host name "moode" to its ip address in the url http://moode.

Another approach used by routers is to include a name resolution service called Multicast DNS or mDNS instead of DNS (Unicast DNS). This service performs name resolution for host names with a .local suffix. In this case http://moode.local should work.

Lastly, if name resolution service is not present in the router, the ip address can be used.

Regards,
Tim

Hi Tim, I use a Netgear WNR3500L but I don't see anything about mDNS in the menu's. I think I can use Tomato firmware on it, I'll need to see if that might work.

[robtweed]

Tim

Many thanks for the responses to my earlier questions!

One further question - or more like looking for tips. I have some live material I've recorded at uncompressed 96/24. If I store the files on my NAS source (actually a USB drive attached to a Mac Mini on my home network), I can't play them without serious sound break-up: it would seem that even though everything is connected over hard-wired Ethernet, either the file isn't being streamed to Moode on the Raspberry Pi fast enough, or the buffer on Moode isn't correctly sized. I've tried all sorts of buffer sizes on Moode, from very small to very large, with some improvements here and there, but I still get break-up.

Perhaps there are options I can use when defining the NAS source on Moode that would allow me to tune how the files are sent to the Raspberry Pi over TCP - eg packet size etc? Any suggestions / advice welcome.

Placing the files on a local USB drive on the Pi solves the problem, so it's not entirely critical. 44/16 sources (both uncompressed and Apple Lossless) stream just fine from the Mac by the way, so it's clearly an issue with the sheer rate of streaming that's required with 96/24 files that's the issue.

Cheers

Rob

[robtweed]

Tim

Your suggestion on random play worked perfectly. I'd missed that trick of adding the entire source to the playlist - nice one! By the way. it seems to cope with my iTunes library of >11,000 tracks just fine.

Now I'm very happy! I'm now getting all audio sources being sent bit-perfectly and un-tampered-with to my Caiman II DAC via the Pi/Moode/Digi+. All other solutions I'd used did things like re-sampling to 48/16 (eg Apple TV), or were impossible to determine if/how they were tampering with the original stream.

This is a great, and crazily low-cost streaming solution! A great combination with the Caiman II too - I have it connected from the Digi+ via the co-ax wired connection (pro 75 Ohm cable), simply because the 2 Toslink connections on the Caiman were already in use for other devices with only Toslink connections.

One suggestion - on the play screen, it might be an idea to have the playlist in its own separate scrollable div tag so you can still scroll up and down in the main area where the play and volume controls reside. I think it might help make that screen more usable with very large playlists. Alternatively have a view option where you can disable / turn off the playlist display altogether from that screen so the responsiveness of the screen isn't affected by having to cope with a very large playlist.

I'm tempted, Tim, to see what I could do with a bit of Node.js on the back-end, and React.js / React Native on the front.... but then again work has a habit of getting in the way of such fun stuff!

Thanks, BTW, to this forum and its participants which is how I discovered all about these options, components and tricks/suggestions in the first place.

Rob

[TimCurtis]

Tim

Many thanks for the responses to my earlier questions!

One further question - or more like looking for tips. I have some live material I've recorded at uncompressed 96/24. (1) If I store the files on my NAS source (actually a USB drive attached to a Mac Mini on my home network), I can't play them without serious sound break-up: it would seem that even though everything is connected over hard-wired Ethernet, either the file isn't being streamed to Moode on the Raspberry Pi fast enough, or the buffer on Moode isn't correctly sized. I've tried all sorts of buffer sizes on Moode, from very small to very large, with some improvements here and there, but I still get break-up.

Perhaps there are options I can use when defining the NAS source on Moode that would allow me to tune how the files are sent to the Raspberry Pi over TCP - eg packet size etc? Any suggestions / advice welcome.

(2) Placing the files on a local USB drive on the Pi solves the problem, so it's not entirely critical. 44/16 sources (both uncompressed and Apple Lossless) stream just fine from the Mac by the way, so it's clearly an issue with the sheer rate of streaming that's required with 96/24 files that's the issue.

Cheers

Rob

Hi Rob,

The two symptoms below suggest a bottleneck either in the Mac Mini, the file sharing protocol or configuration being used in the Mini, or less likely but still possible, an issue in the network device (router or switch) that connects both the Pi and the Mini.

(1) If I store the files on my NAS source (actually a USB drive attached to a Mac Mini on my home network), I can't play them without serious sound break-up

(2) Placing the files on a local USB drive on the Pi solves the problem

It's not a streaming protocol (like what a radio station uses) that occurs between NAS and Pi but rather a file transfer protocol (like a file copy). The Pi believes the NAS is a locally attached disk even though it is somewhere else on the network. The sample rate of the song file is not a factor and buffer changes in MPD should never be required.

To troubleshoot this I would start with a 30 sec ping test initiated on the Pi and to the Mini while playing a song located on the Mini in Moode to see what the round trip times look like and also whether there is any packet loss. We want to see 0% packet loss :-)

Stress Test Comparator: this is what a ping test looks like from a Pi-1B (OC'd to 1GHz) over WiFi to my file server (ms1) while Moode is playing a 120MB DSF (DSD rip) song file located on the server. This Pi is connected to a BerryNOS Red TDA1543 DAC and configured for SoX resampling at 16/176.4 kHz. CPU runs at 75% for DSF resampled. I play DSF, 24/96 FLAC, etc from file server to this Pi and never any audio glitches.

Authenticated to rp1 ([192.168.1.51]:22).
Linux rp1 4.1.10+ #820 PREEMPT Sun Oct 4 15:33:59 BST 2015 armv6l

___ ___ ___
/ _ \ / _ \< /
/ , _// ___// /
/_/|_|/_/ /_/

Moode Audio Player
Release 2.4

This software is provided for free by
the copyright holders and contributors
and comes with no expressed or implied
warranties or any other guarantees.

Last login: Tue Oct 20 11:09:52 2015 from 192.168.1.155
root@rp1:~# ping ms1
PING ms1.home.local (192.168.1.21) 56(84) bytes of data.
64 bytes from ms1.home.local (192.168.1.21): icmp_req=1 ttl=128 time=3.01 ms
64 bytes from ms1.home.local (192.168.1.21): icmp_req=2 ttl=128 time=5.54 ms
64 bytes from ms1.home.local (192.168.1.21): icmp_req=3 ttl=128 time=2.40 ms
64 bytes from ms1.home.local (192.168.1.21): icmp_req=4 ttl=128 time=4.97 ms
64 bytes from ms1.home.local (192.168.1.21): icmp_req=5 ttl=128 time=5.71 ms
64 bytes from ms1.home.local (192.168.1.21): icmp_req=6 ttl=128 time=2.72 ms
64 bytes from ms1.home.local (192.168.1.21): icmp_req=7 ttl=128 time=5.00 ms
64 bytes from ms1.home.local (192.168.1.21): icmp_req=8 ttl=128 time=5.49 ms
64 bytes from ms1.home.local (192.168.1.21): icmp_req=9 ttl=128 time=3.25 ms
64 bytes from ms1.home.local (192.168.1.21): icmp_req=10 ttl=128 time=1.13 ms
64 bytes from ms1.home.local (192.168.1.21): icmp_req=11 ttl=128 time=5.43 ms
64 bytes from ms1.home.local (192.168.1.21): icmp_req=12 ttl=128 time=5.95 ms
64 bytes from ms1.home.local (192.168.1.21): icmp_req=13 ttl=128 time=6.26 ms
64 bytes from ms1.home.local (192.168.1.21): icmp_req=14 ttl=128 time=5.18 ms
64 bytes from ms1.home.local (192.168.1.21): icmp_req=15 ttl=128 time=5.54 ms
64 bytes from ms1.home.local (192.168.1.21): icmp_req=16 ttl=128 time=4.31 ms
64 bytes from ms1.home.local (192.168.1.21): icmp_req=17 ttl=128 time=3.92 ms
64 bytes from ms1.home.local (192.168.1.21): icmp_req=18 ttl=128 time=5.62 ms
64 bytes from ms1.home.local (192.168.1.21): icmp_req=19 ttl=128 time=2.86 ms
64 bytes from ms1.home.local (192.168.1.21): icmp_req=20 ttl=128 time=2.36 ms
^C
--- ms1.home.local ping statistics ---
20 packets transmitted, 20 received, 0% packet loss, time 19031ms
rtt min/avg/max/mdev = 1.131/4.336/6.268/1.462 ms
root@rp1:~#

Regards,
Tim

[TimCurtis]

Tim

Your suggestion on random play worked perfectly. I'd missed that trick of adding the entire source to the playlist - nice one! By the way. it seems to cope with my iTunes library of >11,000 tracks just fine.

Now I'm very happy! I'm now getting all audio sources being sent bit-perfectly and un-tampered-with to my Caiman II DAC via the Pi/Moode/Digi+. All other solutions I'd used did things like re-sampling to 48/16 (eg Apple TV), or were impossible to determine if/how they were tampering with the original stream.

This is a great, and crazily low-cost streaming solution! A great combination with the Caiman II too - I have it connected from the Digi+ via the co-ax wired connection (pro 75 Ohm cable), simply because the 2 Toslink connections on the Caiman were already in use for other devices with only Toslink connections.

One suggestion - on the play screen, it might be an idea to have the playlist in its own separate scrollable div tag so you can still scroll up and down in the main area where the play and volume controls reside. I think it might help make that screen more usable with very large playlists. Alternatively have a view option where you can disable / turn off the playlist display altogether from that screen so the responsiveness of the screen isn't affected by having to cope with a very large playlist.

I'm tempted, Tim, to see what I could do with a bit of Node.js on the back-end, and React.js / React Native on the front.... but then again work has a habit of getting in the way of such fun stuff!

Thanks, BTW, to this forum and its participants which is how I discovered all about these options, components and tricks/suggestions in the first place.

Rob

Hi Rob,

Playlist is scrollable separate from the main playback panel. Are u not getting any scrollbars or scrolling action when the huge playlist is loaded?

Regards,
Tim

[robtweed]

Sorry, Tim, you're right - the Playlist is separately scrollable.

However I am finding that having such a huge playlist loaded into the browser is clobbering the performance of the rest of the page (I'm using Chrome on a Macbook Air) - everything becomes really sluggish

Rob

[robtweed]

Thanks Tim

Well I'm getting 0% packet loss on all tests, but when I get the audio glitches, it's at times when the ping time spikes occasionally above 15-20ms. Most of the time the ping time is around 4ms, during which time the sound is just fine as you'd expect.

The servers upstairs are connected through an ethernet powerline extender, so I guess that might be a culprit for the occasional long round trips. The Mac Mini does nothing else but act as a music server, so there shouldn't be any problem there. I can only otherwise assume there's other network traffic causing some occasional congestion.

BTW what's your recommended MPD buffer settings (I can't remember what the original settings were)

Rob

[TimCurtis]

Sorry, Tim, you're right - the Playlist is separately scrollable.

However I am finding that having such a huge playlist loaded into the browser is clobbering the performance of the rest of the page (I'm using Chrome on a Macbook Air) - everything becomes really sluggish

Rob

Hi Rob,

The sluggish performance is due to the design of the Playlist loader in Moode. It reads the entire Playlist into the Browsers memory space. This is ok 99% of the time since typical Playlist is not too large.

I like your suggestion for an option to "turn off the Playlist [loader]". This would effectively solve the performance issue. The Playlist would still exist on the server (Pi) and random play would still work from an entire NAS or USB source.

I'll have to play around with this a bit and see what happens :-)

Regards,
Tim

[TimCurtis]

Thanks Tim

Well I'm getting 0% packet loss on all tests, but when I get the audio glitches, it's at times when the ping time spikes occasionally above 15-20ms. Most of the time the ping time is around 4ms, during which time the sound is just fine as you'd expect.

The servers upstairs are connected through an ethernet powerline extender, so I guess that might be a culprit for the occasional long round trips. The Mac Mini does nothing else but act as a music server, so there shouldn't be any problem there. I can only otherwise assume there's other network traffic causing some occasional congestion.

BTW what's your recommended MPD buffer settings (I can't remember what the original settings were)

Rob

Hi Rob,

The result of the ping test and the presence of Powerline adapters strongly suggests the bottleneck is the Powerline adapters.

Default MPD settings:
- Audio buffer size (KB) 2048
- Buffer fill before play 20%

Regards,
Tim