Devialet Air seek broken since 931 [Roon Investigating]

Roon Core Machine

Linux box / docker

Networking Gear & Setup Details

Ubiquity all wired

Connected Audio Devices

Devlalet Expert 200

Number of Tracks in Library

±10,000 Qobuz

Description of Issue

Since upgrading to 931, seeking back or forth during a playback seems to crash core, music stops playing and pause/play button becomes unresponsive on the devialet expert, not on other (e.g ropieee XL, works ok).
My only solution is to restart core after a seek action.

1 Like

I have the same problem (with a Devialet Expert 440 Pro).

Hello,

I have the same problem, with any iPhone or iPad Client with a Devialet D200, so not core, and ROCK Nuc server.
Was working like a charm before.
Need to restart Roon Server Software from http page.

Best regards,Arnaud

To complete, if I “pause” the play and then move the cursor to a different position within the track timeline, I can “play” again from the new time/position. But if the seek/move in the track is done during playback, then the issue occurs.

Same for me with with AIR, as @Arnaud says using pause works around the problem.

1 Like

@support is this a know issue with this release?

@support, did you acknowledged this issue, is it in your backlog?

I had posted this elsewhere and then found this thread. Here is a description of the problem in detail, in case it helps. I’ll delete the other thread.

Roon Core Machine

NUC 8i7, 8G RAM

Networking Gear & Setup Details

NUC, Synology NAS, and Devialet Expert 250 all connected to Orbi router via CAT-6

Connected Audio Devices

Devialet Expert 250, iMac, iPhone, several Google Chromecast Audios

Number of Tracks in Library

131K

Description of Issue

This began yesterday, with no changes to any part of the system beyond updating Roon and Remotes to the latest versions whenever available. No other changes at all.

When a track is playing, from either Tidal or my library, clicking in the progress bar to advance or “rewind” playback freezes playback. All transport controls (Play/Pause, FF, REW) become inoperable. Signal path “light” goes grey and the signal path shows only the endpoint, with no audio information.

No changes after several minutes of waiting.

Clicking in the progress bar in MacOS Remote OR moving the slider in iOS Remote freezes everything throughout the Roon system — including control of ANY endpoint by the original Remote on which the error began, or by any other Remotes.

Other controls appear operable. E.g., transferring from one endpoint to another appears to be an option — but selecting a transfer (from any endpoint TO any endpoint) freezes, with the screen hanging at “Transferring…”

Restarting Roon Server resets the problem… until the next time. The situation is 100% replicable, i.e., it happens the same way every time.

Reinstalled Roon OS on the NUC. Rebuilt database. Reinstalled Remote on both MacOS and iOS. No changes to behavior from any of those steps.

Thanks for any ideas.

1 Like

@phantomtides thank you :+1:

This is very “annoying” when the Roon remote is used by wife, family, friends… Very bad image for Roon (and… myself) I have to explain, justify why I use Roon :frowning:

Hello gang!

Thank you for getting in touch with us about this. I’ve passed your reports on to our hardware expert to see if he’s able to replicate what you’re seeing. I’ll be back in touch with more details after he’s had time to test.

3 Likes

Thanks for the reply, I fully understand that Devialet Air is legacy code and probably a nightmare to maintain, it is a pity the burden is on you guys and not on devialet for not fixing their 8 year old unstable streaming implementation without forcing users to an expensive HW upgrade - i will roll back to fronting it with a ropiee Raspberry Pi in the meantime.

1 Like

I’m not able to regulate volume from the app (both Apple/Androide) with Air on my 220 pro. OK from hw remote with Air and with RAAT from app.

Devialet AIR is running perfectly with Roon (including hires 192/24) this is the reason why I bought liftime license in 2019.
Thanks again Roon team!!!
It’s the first time I face an issue so I’m still very very happy😀

1 Like

Hello again @fver, @DanielAvasilichioaei , @Arnaud, @Kevin_Hughes, @phantomtides (sorry for missing your report on this)

Our hardware expert was able to reproduce this on our in-house equipment and we’ve put a ticket in. Thank you again for the heads-up. We appreciate it!

5 Likes

@jamie You didn’t miss my report. I opened a new topic and then found this thread shortly thereafter, so I deleted my first post and pasted it here — no need to have two threads on the same subject.

Many thanks to you and the gang for being so on top of this.

2 Likes

Hi @phantomtides,

Thank you for that! It’s a team effort for sure, we appreciate your issue reports. There’s no way we could catch this kind of thing as quickly without your help. :pray:t2:

2 Likes

@support

INFO - I don’t know if it’s related to the current issue or not:
Over time, the Devialet AIR protocol has always required LESS network traffic than the Roon RAAT protocol.
Since the latest Roon versions, this has changed radically: the Devialet AIR protocol requires substantially MORE network traffic than the Roon RAAT protocol.

1 Like

I’m not seeing that, air still looks about 10% more efficient on my system. Have you checked upsampling and mqa unfolding are set the same?

1 Like

I’m not using upsampling and MQA, and settings are the same for both audio devices/protocols.
My Roon Core is installed on Intel NUC running Linux OS.

@jamie Do you have an ETA for the resolution? It will help to wait :slight_smile: Many thanks for your support :pray: