About reading the total duration for the seekbar

[storaid]

Hello Tiki,

I’ve opened a new thread to discuss the issue regarding how TuneBrowser obtains the total track duration.
The previous thread can remain focused on the Re-SUBSCRIBE mechanism.

I have been using Wireshark to analyze the behavior, and since it’s difficult for me to fully understand how TuneBrowser handles on-the-fly transcoding internally, I would like to share some observations—especially regarding certain highly commercial DMR devices.

For these devices, a fallback mechanism similar to BubbleUPnP may be necessary to ensure UI stability and predictable behavior.

The unfortunate reality is that many DMRs do not return structurally reliable or standards-compliant metadata.

In other words:

DO NOT TRUST THE DMR.

Assume the DMR is foolish—and often quite limited.

Below is a conceptual fallback flow that may help:

Fallback Logic Proposal

Layer 1: Read TrackDuration from DMR (real-time truth)

This reflects what the DMR “actually decodes,” and is the most reliable indicator of playback progress after buffering.

Failure conditions:
Returns 0
Returns “0:00:00”
Returns “NOT_IMPLEMENTED”

Common reasons:
DMR cannot parse transcoded WAVProxy streams
Inability to handle WAV extensible header
Incorrect parsing of CUESHEET-derived chunks

My Wireshark observation
Example frame:

Frame 476691: Packet, 52846 bytes on wire (422768 bits), 52846 bytes captured (422768 bits) on interface \Device\NPF_{F72F7E96-A31B-45F4-8A26-5325F88F3FEB}, id 0
Ethernet II, Src: ASUSTekCOMPU_07:ba:f0 (c8:7f:54:07:ba:f0), Dst: ca:da:eb:bf:02:e7 (ca:da:eb:bf:02:e7)
Internet Protocol Version 4, Src: 10.1.1.166, Dst: 10.1.1.96
Transmission Control Protocol, Src Port: 29400, Dst Port: 39720, Seq: 83176520, Ack: 213, Len: 52780
[2065 Reassembled TCP Segments (83229299 bytes): #455688(183), #455689(13032), #455691(1448), #455693(24616), #455695(2896), #455697(39096), #455699(50680), #455701(62264), #455703(63712), #455704(10136), #455706(63712), #455707(13032), ]
Hypertext Transfer Protocol
HTTP/1.1 200 OK\r\n
Response Version: HTTP/1.1
Status Code: 200
[Status Code Description: OK]
Response Phrase: OK
Accept-Ranges: bytes\r\n
Content-Range: 0-83229115/83229116\r\n
Content-Encoding: identity\r\n
Content-Type: audio/wav\r\n
TuneBrowserIFID: 0077b524\r\n
Content-Length: 83229116\r\n
[Content length: 83229116]
\r\n
File Data: 83229116 bytes
Resource Interchange File Format
Magic: RIFF
File Size: 83229108 bytes
File Type: WAVE
fmt Chunk
Chunk ID: fmt
Chunk Size: 40 bytes
Chunk Data: 0100020044ac00009809040006001800060000000300000000000000000000000000000000000000
data Chunk
Chunk ID: data
Chunk Size: 83229048 bytes
Chunk Data […]: 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

I suspect two possible issues that could confuse certain DMRs:
1. fmt Chunk Size = 40 bytes
This indicates a WAV extensible format.
Some commercial DMRs cannot parse this correctly.
2. Large silence at the beginning
The data chunk begins with a long region of zeros (silence).
Some DMR parsers misinterpret this as invalid or corrupted audio when examining the first few buffers.

These issues are difficult to analyze in detail, and unfortunately Denon/Marantz are no longer as responsive in technical support as they once were.
I have contacted their tech support regarding similar issues, but they often do not reply.

Layer 2: Read DIDL-Lite res@duration (declared metadata)

Failure conditions:
Missing attribute
Wrong format
Broken DIDL (e.g., Denon’s double-nested DIDL)
Duration = 0

This layer is unstable, but sometimes useful as a fallback for DMRs that “can play but cannot report duration.”

Layer 3: Use Playlist Manager / Local Metadata (ground truth)

This is the most reliable source.
Regardless of transcoding, the original metadata stored in TuneBrowser is always accurate.

Even if the DMR behaves unpredictably, the “true duration” exists in the local database.

 

Use LastChange to detect track end

The controller may have to rely on its own timer, using the internal duration as a reference (e.g., 312 seconds), and let LastChange confirm end-of-track events.

 

This is just a reference idea that may help future improvements.
Thank you very much for your ongoing work and development of TuneBrowser.

[投稿者]

投稿