Hi @the_bertrum , @Tim Curtis
Having some more time to reply.
Thanks again for your input.
The discussion is going more and more into the direction of it-is-well-or-not-a-moode-or-mpd issue, which, imo, this is not the right approach. moOde users are looking for an audiophile experience. Period. At least this is what the website says: “Audiophile streamer for the wonderful Raspberry Pi family”. So most of the users don’t care whether it’s mpd or a toaster making music play, cause they’ve chosen “moOde”.
Myself being in SW dev (Oracle), I fully understand things are sometimes out of your span of control, and it has to be investigated on a case per case basis.
In this case I totally agree the issue is mpd related (evidence in the “mpd” logs; socket remains open), but… moOde is a layer on top of it, and is able to anticipate on this by stopping/starting the mpd service when this situation is detected. And yes, this may cause an interruption in the stream, but at least it keeps playing.
Before answering your questions. The patch Tim suggested made the monitor didn’t kick in anymore, didn’t retry anymore, causing a final “drop”. More specific, the connection didn’t drop, but kept on playing silence forever. This is also in my logs. I did a clean install, and get back to the origininal situation, where the monitor kicks in, but sometimes conflicts with a restarting mpd, with a crash and audio drop as result. This is basically the reason of my initial post.
There are a number of thing that come out of this discussion as I see it:
1. The xrun is not a problem in moOde, other users can run the same station and never see it, some stations will xrun predictably at specific points, people who see xruns will often have some stations that never see them, and so on. The evidence points to it being a stream plus location issue, i.e either the stream is poor somehow, or the delivery to moOde is poor somehow, or both. Diagnosing that is next to impossible and isn't a moOde issue anyhow.
Kurt: See my point of it's a moOde issue or not. Obviously location, but basically latency and bandwith are key. In my case I've the issue with a flac 96kHz/24bot station in Chile as well as with a ~96kb/s AAC stream here in Brussels at 30 km away.
2. The xrun condition affects other players on the same stream at the same location (There is evidence in this thread of a Naim system that didn't even try to recover). Further evidence that this isn't a moOde problem.
Kurt: Yes, Naim is horrible on that (I've still 2 muso's). An internet hick-up is enough to permantly drop the stream.
3. Certain streams in this discussion have an abnormally frequent rate of the xrun condition at a particular location.
Kurt: Correct. Although, according to Belgian standards, I've a decent bandwidth (300 mbit/s). But... this doesn't say anything about the quality/stability.
4. The stream monitor works. When it is enabled, it restarts the stream effectively.
Kurt: Correct. Point is that some restarts cause a crash of mpd, resulting in a permant audio drop, and the reason of opening this thread.
5. The stream monitor did have an issue where it might clash with the monitor that tried to detect MPD crashes, a situation Tim has fixed.
Kurt: Yes, @Tim Curtis identified a conflicting situation and proposed a patch. This patch actually caused the monitor not to intervene anymore, and mpd doing x-runs forever. So, no, this patch didn't work, hence my request to Tim to further investigate.
6. During the investigations, the system of Kurt1970 has managed to get in a state where the stream monitor no longer works.
Kurt: Correct. See 5. Hence, I did a fresh install.
@the_bertrum Now, I'll test your script. Give me some time, I'll come back on that.
Having some more time to reply.
Thanks again for your input.
The discussion is going more and more into the direction of it-is-well-or-not-a-moode-or-mpd issue, which, imo, this is not the right approach. moOde users are looking for an audiophile experience. Period. At least this is what the website says: “Audiophile streamer for the wonderful Raspberry Pi family”. So most of the users don’t care whether it’s mpd or a toaster making music play, cause they’ve chosen “moOde”.
Myself being in SW dev (Oracle), I fully understand things are sometimes out of your span of control, and it has to be investigated on a case per case basis.
In this case I totally agree the issue is mpd related (evidence in the “mpd” logs; socket remains open), but… moOde is a layer on top of it, and is able to anticipate on this by stopping/starting the mpd service when this situation is detected. And yes, this may cause an interruption in the stream, but at least it keeps playing.
Before answering your questions. The patch Tim suggested made the monitor didn’t kick in anymore, didn’t retry anymore, causing a final “drop”. More specific, the connection didn’t drop, but kept on playing silence forever. This is also in my logs. I did a clean install, and get back to the origininal situation, where the monitor kicks in, but sometimes conflicts with a restarting mpd, with a crash and audio drop as result. This is basically the reason of my initial post.
There are a number of thing that come out of this discussion as I see it:
1. The xrun is not a problem in moOde, other users can run the same station and never see it, some stations will xrun predictably at specific points, people who see xruns will often have some stations that never see them, and so on. The evidence points to it being a stream plus location issue, i.e either the stream is poor somehow, or the delivery to moOde is poor somehow, or both. Diagnosing that is next to impossible and isn't a moOde issue anyhow.
Kurt: See my point of it's a moOde issue or not. Obviously location, but basically latency and bandwith are key. In my case I've the issue with a flac 96kHz/24bot station in Chile as well as with a ~96kb/s AAC stream here in Brussels at 30 km away.
2. The xrun condition affects other players on the same stream at the same location (There is evidence in this thread of a Naim system that didn't even try to recover). Further evidence that this isn't a moOde problem.
Kurt: Yes, Naim is horrible on that (I've still 2 muso's). An internet hick-up is enough to permantly drop the stream.
3. Certain streams in this discussion have an abnormally frequent rate of the xrun condition at a particular location.
Kurt: Correct. Although, according to Belgian standards, I've a decent bandwidth (300 mbit/s). But... this doesn't say anything about the quality/stability.
4. The stream monitor works. When it is enabled, it restarts the stream effectively.
Kurt: Correct. Point is that some restarts cause a crash of mpd, resulting in a permant audio drop, and the reason of opening this thread.
5. The stream monitor did have an issue where it might clash with the monitor that tried to detect MPD crashes, a situation Tim has fixed.
Kurt: Yes, @Tim Curtis identified a conflicting situation and proposed a patch. This patch actually caused the monitor not to intervene anymore, and mpd doing x-runs forever. So, no, this patch didn't work, hence my request to Tim to further investigate.
6. During the investigations, the system of Kurt1970 has managed to get in a state where the stream monitor no longer works.
Kurt: Correct. See 5. Hence, I did a fresh install.
@the_bertrum Now, I'll test your script. Give me some time, I'll come back on that.
