[PROBLEM] Multi-room stream glitch

[cynch303]

Hello everyone,

As said in my presentation post, moOde has been the longest running service in the house. (Nearly) never disappointing ! It has been of everyday use since at least 6 or 7 years.

A recent multiroom upgrade has made the system even better, allowing for seamless listening of radio across the living room and office 

I have two things I want to to report here.

The first one is a question : I noticed that when I have the multi room rig enabled (which is all the time here), there's a continuous stream across my switch ports (presumably coming from the sender) even thought the player is paused/halted. Wouldn't there be a way to interrupt the network flow when the sender is not playing anything ?

I guess the uninterrupted flow is to reduce latency as soon as the sender starts playing something but in some configurations, it might be a bit overkill IMHO. Just a qestion though.

On the other hand, once every few days, the stream becomes garbled on some of the receivers, not necessarily all of them, not necessarily the same receiver all the time. I either have to restart the sender (heavy method) or interuppt the sending to the glitchy receiver (via the UI) and start it again (soft method) to sort things out and get a clean stream again.

Would there be a way to automatically do this with a remote command ? I already know about the REST API but couldn't find specific functions (such as halting multi room sending process and starting it again). I have a solid Home Assistant server running that could handle this task of periodically restarting the multi room stream to avoid such situtations but I'm not sure it's possible with the current API command set.

I would be happy to provide more info if needed.

Thanks again for maintaining such a killer piece of software !

[Tim Curtis]

Regarding:

1. "I noticed ... there's a continuous stream across my switch ports"

Are you using a Network sniffer to determine there is traffic across the switch?

2. "the stream becomes garbled on some of the receivers"

Stream breakup at the receiver suggests a throughput issue. It could be a network issue, maybe very uneven Round Trip Times (RTT) or a slow receiver or sender (like a Pi Zero).

I would run a fairly long ping test, like for at least a couple minutes, on the Sender to each of the receivers and then examine the stats.

High avg RTT  and high mdev (standard deviation) would indicate an issue. If the connections are all Eth then avg rtt and mdev should be <= 1ms. If the connections to the receivers are wireless then avg rtt should be around 4 or 5ms and mdev around 1 to 1.5 ms.

Here's an example of a short ping test from my network.

Sender is trx and receiver is sig.

Code:

pi@trx:~ $ ping sig
PING sig.home (192.168.1.121) 56(84) bytes of data.
64 bytes from sig.home (192.168.1.121): icmp_seq=1 ttl=64 time=6.39 ms
64 bytes from sig.home (192.168.1.121): icmp_seq=2 ttl=64 time=4.22 ms
64 bytes from sig.home (192.168.1.121): icmp_seq=3 ttl=64 time=4.88 ms
64 bytes from sig.home (192.168.1.121): icmp_seq=4 ttl=64 time=5.13 ms
64 bytes from sig.home (192.168.1.121): icmp_seq=5 ttl=64 time=4.63 ms
64 bytes from sig.home (192.168.1.121): icmp_seq=6 ttl=64 time=4.25 ms
64 bytes from sig.home (192.168.1.121): icmp_seq=7 ttl=64 time=4.32 ms
64 bytes from sig.home (192.168.1.121): icmp_seq=8 ttl=64 time=4.23 ms
64 bytes from sig.home (192.168.1.121): icmp_seq=9 ttl=64 time=5.71 ms
64 bytes from sig.home (192.168.1.121): icmp_seq=10 ttl=64 time=4.59 ms
64 bytes from sig.home (192.168.1.121): icmp_seq=11 ttl=64 time=4.40 ms
64 bytes from sig.home (192.168.1.121): icmp_seq=12 ttl=64 time=4.42 ms
64 bytes from sig.home (192.168.1.121): icmp_seq=13 ttl=64 time=4.24 ms
64 bytes from sig.home (192.168.1.121): icmp_seq=14 ttl=64 time=4.23 ms
64 bytes from sig.home (192.168.1.121): icmp_seq=15 ttl=64 time=4.57 ms
64 bytes from sig.home (192.168.1.121): icmp_seq=16 ttl=64 time=5.04 ms
64 bytes from sig.home (192.168.1.121): icmp_seq=17 ttl=64 time=4.24 ms
64 bytes from sig.home (192.168.1.121): icmp_seq=18 ttl=64 time=1.32 ms
64 bytes from sig.home (192.168.1.121): icmp_seq=19 ttl=64 time=4.92 ms
64 bytes from sig.home (192.168.1.121): icmp_seq=20 ttl=64 time=5.68 ms
64 bytes from sig.home (192.168.1.121): icmp_seq=21 ttl=64 time=4.51 ms
64 bytes from sig.home (192.168.1.121): icmp_seq=22 ttl=64 time=1.26 ms
64 bytes from sig.home (192.168.1.121): icmp_seq=23 ttl=64 time=10.8 ms
64 bytes from sig.home (192.168.1.121): icmp_seq=24 ttl=64 time=5.24 ms
64 bytes from sig.home (192.168.1.121): icmp_seq=25 ttl=64 time=4.25 ms
64 bytes from sig.home (192.168.1.121): icmp_seq=26 ttl=64 time=1.19 ms
64 bytes from sig.home (192.168.1.121): icmp_seq=27 ttl=64 time=4.56 ms
64 bytes from sig.home (192.168.1.121): icmp_seq=28 ttl=64 time=4.24 ms
64 bytes from sig.home (192.168.1.121): icmp_seq=29 ttl=64 time=4.70 ms
64 bytes from sig.home (192.168.1.121): icmp_seq=30 ttl=64 time=4.47 ms
64 bytes from sig.home (192.168.1.121): icmp_seq=31 ttl=64 time=4.68 ms
64 bytes from sig.home (192.168.1.121): icmp_seq=32 ttl=64 time=7.28 ms
64 bytes from sig.home (192.168.1.121): icmp_seq=33 ttl=64 time=7.93 ms
64 bytes from sig.home (192.168.1.121): icmp_seq=34 ttl=64 time=4.24 ms
64 bytes from sig.home (192.168.1.121): icmp_seq=35 ttl=64 time=4.24 ms
64 bytes from sig.home (192.168.1.121): icmp_seq=36 ttl=64 time=4.78 ms
64 bytes from sig.home (192.168.1.121): icmp_seq=37 ttl=64 time=5.58 ms
64 bytes from sig.home (192.168.1.121): icmp_seq=38 ttl=64 time=4.22 ms
64 bytes from sig.home (192.168.1.121): icmp_seq=39 ttl=64 time=4.28 ms
64 bytes from sig.home (192.168.1.121): icmp_seq=40 ttl=64 time=4.25 ms
64 bytes from sig.home (192.168.1.121): icmp_seq=41 ttl=64 time=4.23 ms
64 bytes from sig.home (192.168.1.121): icmp_seq=42 ttl=64 time=5.00 ms
64 bytes from sig.home (192.168.1.121): icmp_seq=43 ttl=64 time=5.16 ms
64 bytes from sig.home (192.168.1.121): icmp_seq=44 ttl=64 time=4.41 ms
64 bytes from sig.home (192.168.1.121): icmp_seq=45 ttl=64 time=1.22 ms
64 bytes from sig.home (192.168.1.121): icmp_seq=46 ttl=64 time=7.93 ms
64 bytes from sig.home (192.168.1.121): icmp_seq=47 ttl=64 time=4.22 ms
64 bytes from sig.home (192.168.1.121): icmp_seq=48 ttl=64 time=4.26 ms
64 bytes from sig.home (192.168.1.121): icmp_seq=49 ttl=64 time=1.32 ms
64 bytes from sig.home (192.168.1.121): icmp_seq=50 ttl=64 time=4.25 ms
64 bytes from sig.home (192.168.1.121): icmp_seq=51 ttl=64 time=4.21 ms
64 bytes from sig.home (192.168.1.121): icmp_seq=52 ttl=64 time=4.22 ms
64 bytes from sig.home (192.168.1.121): icmp_seq=53 ttl=64 time=1.16 ms
64 bytes from sig.home (192.168.1.121): icmp_seq=54 ttl=64 time=4.20 ms
64 bytes from sig.home (192.168.1.121): icmp_seq=55 ttl=64 time=4.92 ms
64 bytes from sig.home (192.168.1.121): icmp_seq=56 ttl=64 time=4.24 ms
64 bytes from sig.home (192.168.1.121): icmp_seq=57 ttl=64 time=4.36 ms
64 bytes from sig.home (192.168.1.121): icmp_seq=58 ttl=64 time=4.21 ms
64 bytes from sig.home (192.168.1.121): icmp_seq=59 ttl=64 time=4.25 ms
64 bytes from sig.home (192.168.1.121): icmp_seq=60 ttl=64 time=4.94 ms
64 bytes from sig.home (192.168.1.121): icmp_seq=61 ttl=64 time=4.47 ms
64 bytes from sig.home (192.168.1.121): icmp_seq=62 ttl=64 time=4.23 ms
64 bytes from sig.home (192.168.1.121): icmp_seq=63 ttl=64 time=4.75 ms
64 bytes from sig.home (192.168.1.121): icmp_seq=64 ttl=64 time=4.78 ms
64 bytes from sig.home (192.168.1.121): icmp_seq=65 ttl=64 time=4.21 ms
64 bytes from sig.home (192.168.1.121): icmp_seq=66 ttl=64 time=4.24 ms
^C
--- sig.home ping statistics ---
66 packets transmitted, 66 received, 0% packet loss, time 65084ms
rtt min/avg/max/mdev = 1.159/4.507/10.835/1.494 ms
pi@trx:~ $

[cynch303]

Thanks Tim !

About the network traffic across the switch ports : I just see the traffic LEDs blinking non stop (-:

If I unplug the sender, LEDs stop blinking continuously and come back to a "traffic only" flicker.

I'll try pinging for a long time as soon as I get back home and report back here but my network is, AFAIK, pretty solid :

- Wired devices
- Sender is a RPi4
- Both receivers are RPi3B+
- I'm using IQAudio DAC+ on both receivers

I never noticed ping dropoputs on other devices but, to be honest, I never investigated very thoroughly.

"Corrupted" stream output, when it starts happening will go on until disconnect/reconnect of sender/receiver. Don't get me wrong : sound is recognizable but "garbled".

Will report ping my ping tryouts.

[cynch303]

Ping statistics from my 2 receivers (from the sender) look more than ok :

From receiver 1 :

Code:

4 bytes from 192.168.1.22: icmp_seq=1818 ttl=64 time=0.330 ms
64 bytes from 192.168.1.22: icmp_seq=1819 ttl=64 time=0.310 ms
64 bytes from 192.168.1.22: icmp_seq=1820 ttl=64 time=0.361 ms
64 bytes from 192.168.1.22: icmp_seq=1821 ttl=64 time=0.393 ms
^C
--- 192.168.1.22 ping statistics ---
1821 packets transmitted, 1821 received, 0% packet loss, time 1863289ms
rtt min/avg/max/mdev = 0.263/0.377/0.674/0.052 ms

From receiver 2 :

Code:

64 bytes from 192.168.1.32: icmp_seq=2752 ttl=64 time=0.414 ms
64 bytes from 192.168.1.32: icmp_seq=2753 ttl=64 time=0.386 ms
64 bytes from 192.168.1.32: icmp_seq=2754 ttl=64 time=0.448 ms
64 bytes from 192.168.1.32: icmp_seq=2755 ttl=64 time=0.437 ms
64 bytes from 192.168.1.32: icmp_seq=2756 ttl=64 time=0.489 ms
64 bytes from 192.168.1.32: icmp_seq=2757 ttl=64 time=0.557 ms
^C
--- 192.168.1.32 ping statistics ---
2757 packets transmitted, 2755 received, 0.0725426% packet loss, time 2820830ms
rtt min/avg/max/mdev = 0.280/0.455/1.618/0.079 ms

Glitchy output hasn't occured since a few days now on any of the two...

Where should I look (log output or other) when it happens again ?

Yours,


Jérôme

[Tim Curtis]

The multiroom sender and receiver don't generate any persistent log data but you could try checking the MPD log on the sender to see if there any errors correlating in time to when the glitch occurs.