Hi Antoine,
just FYI the issue is currently with their R&D department.
Will keep you posted.
Hi @Antoine,
do you have any updates on this bug? I have looped the support team in the conversation with the Trinnov support but see no input from Audirvana tech support.
What is the best way forward to get this investigated?
Cheers,
Max
What is Trinnov telling you?
They said they can’t replicate it. I have now done a very thorough test and debugged the logs (everything from the next paragraph has been drafted with the help of ChatGPT, which analysed the various logs and coordinated the testing).
I have now reproduced and documented two separate behaviours:
-
With the Trinnov manufacturer settings and Universal Gapless Playback enabled, seeking initially works, but after seeking again Audirvana stops the current track and moves to the next one without playing it.
-
With the manufacturer settings overridden and Universal Gapless Playback disabled, seeking works reliably. However, when a track finishes, the next track plays correctly through the Trinnov while Audirvana continues displaying the previous track.
I also tested Audirvana’s “Fix for devices with unwanted playback stops” option, but this did not resolve the first issue.
I collected screen recordings, Audirvana status reports, detailed session logs and a network packet capture for both configurations. The capture appears to show that:
-
in Universal Gapless mode, a later seek results in Audirvana opening the requested partial stream but closing it without sending the audio payload; and
-
with Universal Gapless disabled, the next track is played correctly, but Audirvana reports errors parsing the Trinnov’s AVTransport metadata events.
I have forwarded the complete testing dataset and a summary of these findings to both Audirvana and Trinnov support so that their engineering teams can review the interaction from both sides.
I will post another update when either team responds.
If Trinnov cannot replicate the condition, why are they not helping you sort-out your network configuration? Especially, if their testing was done with Audirvāna in your contextual playback scenario…
Why do you think there’s a network configuration problem? Do you mean on the router side or on the Trinnov side?
Based on the analysis of the logs, the original issue (seeking not working) seems to be caused by Audirvana. Below the analysis of the packet capture log:
The packet capture shows:
-
The first seek succeeds. The Trinnov sends a valid HTTP Range request, Audirvana returns audio data and playback continues from the requested position.
-
On a subsequent seek, the Trinnov again sends a valid Range request.
-
Audirvana replies with
206 Partial Contentheaders and advertises a large response body, but no audio payload is then transferred before the server-side connection closes. -
Only after this does the Trinnov report position
00:00:00and transport stateSTOPPED.
The Audirvana session log appears to describe the same event: the requested audio is already loaded, but Audirvana records that it returned zero bytes for a 1 MB request.
This suggests that the immediate cause of the seeking failure is within Audirvana’s Universal Gapless HTTP-stream handling, possibly its state management after repeated seeks.
I offered Trinnov to have a call and connect remotely so I can replicate the issue for them.
Well… You stated that Trinnov could not replicate the condition… either they did, or they did not, use Audirvāna in a replica of your playback scenario… which one is it?
That’s a good question which I can’t answer. It seems to be more a firmware/product version clash rather than a network issue (and it’s not occasional, I can replicate it deterministically).
That’s why I’ve performed all the analysis and debugging, provided them with logs and screen recordings (besides volunteering screen sharing).
Let’s see…