03-Mar-2022, 10:29
@Jean-Marie
We've had very different experiences with the problem and our own experience plays a large part in the reasoning and conclusions we each reach.
In my case the problem only occurred if I streamed music at 24/192 when it occurred quickly and repeatedly. Going back to streaming at native resolution (I had no 24/192 content on my server and Tidal didn't offer anything higher than 24/96, even after letting Roon do the first MQA decode) ensured the problem occurred incredibly rarely, as in once in several months. I can't remember if I had to restart everything including the server as well as going back to streaming at native resolution but, in my case, the trigger for the problem was very definitely a 24/192 stream.
Having read your post above I can see why you would think that the Devialet is triggering an abnormal condition in Roon. My experience does not suggest that and I don't know how many other people's experience aligns with your experience, or how many's experience aligns with mine. We simply don't have the data. The error message itself only tells us there is a problem and tells us nothing about the cause or location of the problem. In addition the wording of the error message is pretty generic and I have no doubt that there is more than one condition which could interrupt playback and result in the generation of that message. For example, the wording of the message would seem to be appropriate if there are problems between Tidal's or any other service's servers and between your Roon device and Roon isn't receiving data from the server in a timely manner.
Let's say that you are correct that the Devialet's behaviour is triggering an abnormal condition in Roon. Whose problem is it. If the Devialet's behaviour is inappropriate, if the Devialet isn't handling the stream correctly and it is that problem which triggers a fault in Roon, then it would seem that the proper solution would be to fix the problem in Devialet's code so that the Devialet does not exhibit that behaviour. On the other hand, if there's some behaviour of the Devialet which is not inappropriate but for some reason an appropriate response from the Devialet to Roon triggers the abnormal condition in Roon, then the proper solution would be for Roon to fix their code. We don't know whether the problem is arising in the Devialet or in Roon, logically it has to be in one of them, but we don't know. The fact that restarting the Roon server fixes the problem doesn't prove that the problem lies in Roon. Ancillary devices have been known to trigger faults in computers which require rebooting the computer to clear the fault condition, even though the cause of the problem lies elsewhere.
As I said in my first paragraph, your experience of the problem is different to mine and @mdconnelly 's experience is different again. Don't forget that this problem not only got through Devialet's beta testing but then got through Roon's certification process without being discovered by either company.
In the end the only things which are clear is that Roon stated soon after the problem was first noticed that the cause of the problem was not in Roon and Devialet, while saying little, has acknowledged the problem, been working on a fix, and has released a FW update which they said went some way to fixing it. That strongly suggests to me that the problem which needs fixing lies in Devialet's code rather than in Roon's.
I don't know if my reasoning is better or worse than yours. There's an old gag line which says "I think our problem is a lack of information but I have nothing to base that on" and after more than 2 years with this problem causing issues for many users none of us users appear to have any solid information to say where the problem lies. All any of us can do is to consider the facts as we know them, heavily influenced as we are by our own experience, and try to come up with a conclusion that we think makes some kind of sense out of what is a very confusing problem which has affected lots of users in a number of different ways.
We've had very different experiences with the problem and our own experience plays a large part in the reasoning and conclusions we each reach.
In my case the problem only occurred if I streamed music at 24/192 when it occurred quickly and repeatedly. Going back to streaming at native resolution (I had no 24/192 content on my server and Tidal didn't offer anything higher than 24/96, even after letting Roon do the first MQA decode) ensured the problem occurred incredibly rarely, as in once in several months. I can't remember if I had to restart everything including the server as well as going back to streaming at native resolution but, in my case, the trigger for the problem was very definitely a 24/192 stream.
Having read your post above I can see why you would think that the Devialet is triggering an abnormal condition in Roon. My experience does not suggest that and I don't know how many other people's experience aligns with your experience, or how many's experience aligns with mine. We simply don't have the data. The error message itself only tells us there is a problem and tells us nothing about the cause or location of the problem. In addition the wording of the error message is pretty generic and I have no doubt that there is more than one condition which could interrupt playback and result in the generation of that message. For example, the wording of the message would seem to be appropriate if there are problems between Tidal's or any other service's servers and between your Roon device and Roon isn't receiving data from the server in a timely manner.
Let's say that you are correct that the Devialet's behaviour is triggering an abnormal condition in Roon. Whose problem is it. If the Devialet's behaviour is inappropriate, if the Devialet isn't handling the stream correctly and it is that problem which triggers a fault in Roon, then it would seem that the proper solution would be to fix the problem in Devialet's code so that the Devialet does not exhibit that behaviour. On the other hand, if there's some behaviour of the Devialet which is not inappropriate but for some reason an appropriate response from the Devialet to Roon triggers the abnormal condition in Roon, then the proper solution would be for Roon to fix their code. We don't know whether the problem is arising in the Devialet or in Roon, logically it has to be in one of them, but we don't know. The fact that restarting the Roon server fixes the problem doesn't prove that the problem lies in Roon. Ancillary devices have been known to trigger faults in computers which require rebooting the computer to clear the fault condition, even though the cause of the problem lies elsewhere.
As I said in my first paragraph, your experience of the problem is different to mine and @mdconnelly 's experience is different again. Don't forget that this problem not only got through Devialet's beta testing but then got through Roon's certification process without being discovered by either company.
In the end the only things which are clear is that Roon stated soon after the problem was first noticed that the cause of the problem was not in Roon and Devialet, while saying little, has acknowledged the problem, been working on a fix, and has released a FW update which they said went some way to fixing it. That strongly suggests to me that the problem which needs fixing lies in Devialet's code rather than in Roon's.
I don't know if my reasoning is better or worse than yours. There's an old gag line which says "I think our problem is a lack of information but I have nothing to base that on" and after more than 2 years with this problem causing issues for many users none of us users appear to have any solid information to say where the problem lies. All any of us can do is to consider the facts as we know them, heavily influenced as we are by our own experience, and try to come up with a conclusion that we think makes some kind of sense out of what is a very confusing problem which has affected lots of users in a number of different ways.
Roon Nucleus+, Devilalet Expert 140 Pro CI, Focal Sopra 2, PS Audio P12, Keces P8 LPS, Uptone Audio EtherREGEN with optical fibre link to my router, Shunyata Alpha NR and Sigma NR power cables, Shunyata Sigma ethernet cables, Shunyata Alpha V2 speaker cables, Grand Prix Audio Monaco rack, RealTRAPS acoustic treatment.
Brisbane, Qld, Australia
