UPnP question: the DMR supports audio/wav, but TB applies WavProxy. WHY?

[storaid]

Hello Tiki,

I’m a bit confused about why WAV files are being forced through the “WavProxy” process.

When I manually add audio/x-wav to the MIME types list, the issue disappears and the file is played directly without WavProxy.

After some testing, I eventually found this discussion:

hqplayerと連携してdsdが再生できない

From what I understand, it seems TuneBrowser performs some additional checks for certain formats.
However, according to RFC 6648, MIME types beginning with the x- prefix have been deprecated since 2012:

https://datatracker.ietf.org/doc/html/rfc6648

Because of this, some DMR devices—especially commercial international brands—no longer include any x-* MIME types in their supported format list.
Their MIME tables typically only contain the standardized types such as audio/wav.

This leads me to wonder:

Why does TuneBrowser require audio/x-wav to be present in order to avoid using WavProxy, even when the DMR advertises support for audio/wav?
Is TuneBrowser applying additional format validation beyond the MIME list provided by the DMR?

If you could clarify this behavior, it would help me understand the reasoning behind the WavProxy fallback.

Thank you very much for your continued development of TuneBrowser.

[storaid]

I did not see this issue when testing with version 5.8.1.

Please don’t strictly require MIME types that begin with the “x-” prefix.

There is no such rule in IANA, and RFC 6648 officially deprecated the “x-*” convention.

The reason many DMRs still list MIME types beginning with “x-” is simply due to historical legacy, not because they follow a formal standard.

Thank you very much for your excellent work.

[storaid]

The MIME type audio/dsf will never appear in the IANA registry because DSF is a proprietary format originally created by Sony.

It is indeed a peculiar situation.

DSD is not widely popular, and under normal circumstances its fate should have been similar to MQA.

However, the history of DSD is different: unlike MQA, its adoption was not tied to a strict commercial licensing scheme, and a large number of DACs and AVRs eventually added native support for it.
This widespread hardware compatibility is the main reason why the DSD/DSF format continues to survive today.

The HQPlayer developer (Signalyst) appeared to deflect the issue in his response.

Maybe..

He relied on the obsolete “x- prefix convention” — formally deprecated 14 years ago — as justification, which effectively masks either limitations in his parser implementation (I don’t think so..) or a decision not to support the format for business-related reasons.

In reality, Sony never submitted a formal media type registration for DSF to IANA.

Thank you

[storaid]

Hello,

If my attitude toward the “x-” prefix sounded a bit harsh, please accept my apology.
I don’t intend to criticize Jussi Laako (Signalyst) personally regarding Sony’s DSD format.
He is simply very much a fundamentalist when it comes to standards — IANA is essentially his “bible,” and he has a strong preference for strict determinism.

In the old specification era (RFC 2045), unregistered media types were indeed required to use the “x-” prefix.
However, this rule was officially abolished in 2012 with RFC 6648.

Therefore, his view on the “x-” prefix reflects Signalyst’s own interpretation, rather than the current industry practice.

Thank you!

[Tiki]

As you surmised, I have strictly enforced IANA compliance starting from 5.9.1. At that time, I’ve just realized that TuneBrowser being loose was the problem.

I’ll think about what to do.

[storaid]

Hello, Tiki,

The fragmentation of MIME standards is indeed a complex issue, and referencing relevant RFCs can be challenging. This is closely related to historical baggage—complete standardization is simply not feasible.

As you review different RFC documents, you may notice situations where:

1. There are occasional conflicts.
2. The specifications try to resolve or interpret each other.

Ultimately, there is no unified solution—this ideal does not exist in reality.

For instance, as highlighted in RFC 6648 Section 2 (“Recommendations for Implementers of Application Protocols”):
> Implementations of application protocols MUST NOT make any assumptions about the status of a parameter, nor take automatic action regarding a parameter, based solely on the presence or absence of “X-” or a similar construct in the parameter’s name.

The use of “MUST NOT” as defined by RFC 2119 carries a strong normative prohibition. RFC 6648 also clearly lays out the historical context for deprecating the “x-” prefix.

Signalyst’s reliance on custom types like “x-dsd/x-dff/x-dsf” is simply their interpretation, driven by their own commercial ecosystem (e.g., Roon), and should be considered only as a reference, not a universal standard.

Looking for further clarification, RFC 6838 offers guidance, though it’s admittedly long and complex. Section 3.4 (“Unregistered x. Tree”) and the grandfather clause (Appendix A, Grandfathered Media Types) expand on the importance of backward compatibility.

Due to the historical context of MIME, backward compatibility must be considered. Otherwise, strict adherence to only the types registered in the IANA registry would impact a very broad range of users and devices, with severe consequences.

Thank you very much for your excellent work.

[Tiki]

Hello.

Now TuneBrowser is supporting both audio/x-XXX and audio/XXX cases to determine to apply ProxyStream in 1821.

[storaid]

Hello, Tiki

I did a bit of investigation recently and captured some traffic using Wireshark.
I still need some time to further check the subscription mechanism, but I already have a few questions.

First, I extracted some packets from Wireshark for inspection.
Below is the HTTP GET handshake for a WAV file.

Request (DENON → TuneBrowser):

GET /TuneID/00018083-RFH-7CD83014.wav HTTP/1.1
User-Agent: GStreamer souphttpsrc 1.22.12 libsoup/3.6.5
Accept-Encoding: identity
Connection: Keep-Alive
Host: 10.1.1.166:29400

a bit tough! GStreamer..Orz

Response (TuneBrowser → DENON):

HTTP/1.1 200 OK
Accept-Ranges: bytes
Content-Range: 0-59773209/59773210
Content-Encoding: identity
Content-Type: audio/x-wav
TuneBrowserIFID: 09e42e96
Content-Length: 59773210

I have a couple of questions:

1. I am a bit confused about the Content-Type.
Why does it return audio/x-wav instead of audio/wav?

2. If we step outside the UPnP context and look purely at HTTP semantics,
is the Content-Range field in this response actually correct?

I am trying to recall my old TCP/IP knowledge, but I must admit that much of it has already been “returned to my professors.”
So my understanding and references are somewhat limited.

The main references I looked at are:

RFC 2616
https://datatracker.ietf.org/doc/html/rfc2616#section-14.16

RFC 7233
https://datatracker.ietf.org/doc/html/rfc7233#section-4.2

Could you please help double-check this behavior?

Thank you very much for your excellent work on TuneBrowser.

[storaid]

References:

https://stackoverflow.com/questions/43133321/can-content-range-header-be-sent-in-a-http-200-ok-response

https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/206

[storaid]

Interesting..

It’s my quess!

FLAC works fine because GStreamer can extract duration from the FLAC STREAMINFO header itself.

However, WAV and LPCM fail because they rely heavily on accurate HTTP metadata (Content-Length/Range) to determine duration.

The non-standard Content-Range in 200 OK is specifically breaking formats that depend on transport-level length signaling.

[storaid]

If my memory serves me correctly regarding HTTP semantics:
When playback initially starts, the DMR issues an HTTP GET request. In this case, the server should return 200 OK, and the Content-Range header is not required (and according to RFCs, it should not be present).

However, the situation changes when the Seekbar is moved. To handle seeking, the server is expected to return 206 Partial Content. In this scenario, the response structure is different; for instance, the Content-Range header becomes mandatory to define the specific byte range being delivered.

Since DENON relies on GStreamer (which uses libsoup for its HTTP/HTTPS implementation), it tends to be much more strict about protocol compliance compared to other players like MPD. GStreamer’s state machine might become confused or fail if it encounters a Content-Range within a 200 OK response, as this contradicts standard HTTP behavior.

[storaid]

Hello, Tiki,

If your HTTP/HTTPS functionalities are implemented using hand-written sockets or raw HTTP generators, I would like to offer a small suggestion. If not, please feel free to skip this message.

Maintaining clean and robust code helps avoid unexpected RFC edge case issues. By directly using modern and efficient HTTP libraries—such as Boost.Beast, libmicrohttpd, or cpp-httplib—you can prevent subtle mistakes commonly made with hand-crafted implementations, like generating non-standard header combinations or mismatched status codes and headers (for example, returning 200 OK with a Content-Range header).

Otherwise, you may encounter DMRs that use industry-standard commercial HTTP/HTTPS libraries, which can be much stricter about protocol compliance during handshakes.

Please consider this suggestion.

Thank you very much for your excellent work.

[Tiki]

1. I am a bit confused about the Content-Type.
Why does it return audio/x-wav instead of audio/wav?

I adjusted the MIME priority when applying ProxyStream. In this case, you’re probably playing the Wave file directly. In the next release, I’ll add an option to further adjust the MIME priority for you.

2. If we step outside the UPnP context and look purely at HTTP semantics,
is the Content-Range field in this response actually correct?

Are you saying there’s a problem with the existence of this parameter itself, or with the value of this parameter?

Regarding the values, I believe I calculated them meticulously, including the Wave format header, but errors are still possible. Please point it out if you find any.

As for the existence of parameters, I don’t consider it a problem since the receiving side can simply ignore them if they’re not interested. I believe “TuneBrowserIFID” is similarly ignored.

[storaid]

Hello Tiki,

Thank you for the clarification.
Let me try to restate my question more precisely, as I think there may have been a misunderstanding.

I am not questioning the correctness of the calculated values (first/last byte positions or total length).
I understand that those were carefully computed, including the WAV header.

My concern is purely about HTTP semantics, independent of UPnP or implementation tolerance.

Specifically, my question is:

In HTTP/1.1 semantics, is it valid for a response with status
200 OK to include a Content-Range header at all?

According to my understanding of RFC 2616 §14.16 and RFC 7233, Content-Range is defined to describe a partial entity-body, and is normally associated with 206 (Partial Content) or 416 responses.

(Or RFC9110: https://datatracker.ietf.org/doc/html/rfc9110#name-content-range)

So my question is not whether a client can ignore the header, but whether this header/status-code combination has a defined meaning in the HTTP specification, or if it falls into an undefined / non-standard area that some clients may handle differently.

I hope this clarifies what I was trying to ask.
Thank you again for your time and for the excellent work on TuneBrowser.

[storaid]

Hello Tiki,

In this case,

DENON uses GStreamer with libsoup 3, which is an HTTP library.

Compared to libsoup 2, libsoup 3 is more strict about HTTP protocol compliance. This change can affect commercial DMRs that rely on such libraries.

Because of this, it may be necessary to follow the HTTP specification more closely.

For example, in an HTTP 200 OK response, the Content-Range header is not something that can be added arbitrarily according to RFC 2616, RFC 7233, and RFC 9110.

Thank you.

[Tiki]

Thank you storaid,

As an amateur developer, I think that in today’s resource-rich environment, it’s perfectly fine to simply ignore parameters that don’t interest you. On the other hand, I also understand that if there are rules, it’s better to follow them.

Then, if the request includes a RANGE parameter, it will return a 206 response with a Content-Range parameter. Otherwise, it will return a 200 response without a Content-Range parameter. Is that acceptable?

[storaid]

Hello Tiki,

Thank you for your reply.

Since reading RFC 9110 in full can be quite time-consuming, it may be easier to confirm this part of the HTTP specification using the MDN documentation, which is widely regarded as an authoritative reference:

https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/206

(JP: https://developer.mozilla.org/ja/docs/Web/HTTP/Reference/Status/206)

MDN states:

The HTTP 206 Partial Content successful response status code is sent in response to a range request. The response body contains the requested ranges of data as specified in the Range header of the request.

The format of the response depends on the number of ranges requested. If a single range is requested, the Content-Type of the entire response is set to the type of the document, and a Content-Range is provided. If several ranges are requested, the Content-Type is set to multipart/byteranges, and each fragment covers one range, with its own Content-Range and Content-Type headers describing it.

From this description, we can see that Content-Range is used with a 206 Partial Content response, and that this behavior depends on whether the DMR (client) actually sends a Range request header.
If no Range header is present in the request, the server should return 200 OK instead.

For example, MDN provides the following request:

GET /z4d4kWk.gif HTTP/1.1
Host: images.example.com
Range: bytes=21010-

Here, the client explicitly includes a Range header, so the server responds with:

HTTP/1.1 206 Partial Content
Date: Wed, 15 Nov 2015 06:25:24 GMT
Last-Modified: Wed, 15 Nov 2015 04:58:08 GMT
Content-Range: bytes 21010-47021/47022
Content-Length: 26012
Content-Type: image/gif
ETag: "abc123"
Accept-Ranges: bytes

From this response, we can also note that Content-Range is required in a 206 response, and that its format is important.
According to RFC 9110, the syntax is defined as:

Content-Range = range-unit SP ( range-resp / unsatisfied-range )

This means a range-unit (for example, bytes) must be present.
Following the MDN example:

Content-Range: bytes 21010-47021/47022

is a valid Content-Range header, whereas a format such as:

Content-Range: 0-59773209/59773210

is not compliant. On stricter DMR implementations, such a header may lead to state-machine confusion or timing-related side effects.

 

As a practical comparison, here is an example of a UPnP WAV streaming exchange using foobar2000:

Client request:

GET /04EBE99C-6FDA-4F3B-8A2D-29E013CC686E/stream.wav HTTP/1.1
User-Agent: GStreamer souphttpsrc 1.22.12 libsoup/3.6.5
Accept-Encoding: identity
Connection: Keep-Alive
Host: 10.1.1.166:62738

Server response:

HTTP/1.1 200 OK
TransferMode.dlna.org: Streaming
Server: PFCv2/1.0
Content-Type: audio/wav
Content-Length: 4294967294
Connection: close
Accept-Ranges: none

Ignoring the DLNA-specific headers (which are not relevant here), we can see that the 200 OK response does not include a Content-Range header, which is consistent with the HTTP specification.

Thank you

[Tiki]

Hello.

Then I will take the following actions.

Then, if the request includes a RANGE parameter, it will return a 206 response with a Content-Range parameter. Otherwise, it will return a 200 response without a Content-Range parameter. Is that acceptable?

[Tiki]

I have released 1823.

I adjusted the MIME priority when applying ProxyStream. In this case, you’re probably playing the Wave file directly. In the next release, I’ll add an option to further adjust the MIME priority for you.

Please set this option to “No”. The MIME type that comes first in alphabetical order will be used.

– TreeItem: Basic – Network
– Property: OpenHome/UPnP – Prefer IANA MIME types

And also Content-Range matter is improved.

[Tiki]

If there are no critical issues, I plan to release this as the official version.

[storaid]

Hello, Tiki

In my case,

HTTP/1.1 200 OK

Accept-Ranges: bytes

Content-Encoding: identity

Content-Type: audio/wav

TuneBrowserIFID: 0aeb740c

Content-Length: 74508492

I’ve verified that the original WAV file size is 48,623,616 bytes.
However, the HTTP response for the TuneID URI reports:

Content-Length: 74,508,492

Could you please clarify whether this TuneID URI is serving:
1) the original WAV file as-is, or
2) a dynamically generated WAV / PCM stream (e.g. decoded or reformatted audio)?

If it is the latter, that would explain the size difference and would help clarify how Content-Length is currently being calculated.

[storaid]

Hello Tiki,

Based on the GET request issued by the DMR, I accessed the following URI directly:

[audio src="http://10.1.1.166:29400/TuneID/00018084-RFH-0BC02582.wav" /]

After downloading it manually, I confirmed that the file size is 46.3 MB (48,623,616 bytes), which matches the size of the original WAV file exactly.

Given this, I’m a bit unclear about how the following header value is being calculated:

Content-Length: 74,508,492

Could you please clarify how this Content-Length value is derived?

Thank you!

[storaid]

Hello Tiki,

I would like to report an observation related to WAV / LPCM / L16 playback behavior.

When I call GetPositionInfo, the returned TrackDuration is always 00:00:00 for WAV / LPCM / L16 streams, while most other formats return a valid duration as expected(STREAMINFO/metadata).

* WAV / LPCM / L16

libsouphttpsrc
↓
typefind
↓
wavparse / qtdemux / decodebin

My suspicion is that this behavior may be related to the stricter requirements of DENON’s GStreamer / libsoup3 stack.
When I tested with several MPD-based DMRs, the same content worked correctly and TrackDuration was reported as expected.

One notable difference is that MPD does not rely on HTTP Content-Length to determine media duration.
Instead, duration is derived from metadata (such as DIDL-Lite res@duration) or from decoder-level information, which makes it more tolerant of non-file-based streaming semantics.

I also noticed that some UPnP development tools explicitly use Transfer-Encoding: chunked for WAV / LPCM streams, which avoids the need to declare a precise Content-Length when the final size is not known in advance.

For comparison, foobar2000’s UPnP implementation works reliably in all cases.
Its design is quite deliberate: it intentionally sets a sentinel Content-Length (around 4 GB) as a fake length, and it does not trust the renderer’s DIDL res@duration or TrackDuration at all.
Instead, foobar2000 calculates and maintains the true track duration internally based on the original file metadata.

This difference in design may explain why some renderers (especially those based on GStreamer / libsoup3) react differently to WAV / LPCM streams.

I hope this information is useful as a reference, and I would be happy to provide additional test data if needed.

Thank you!

[storaid]

Hello,

So strange….!! =_=

I tested the exact same WAV URI with another DMR, iFi audio ZEN Stream, which is MPD-based.
In this case, the HTTP response returned a Content-Length that matches the approximately actual file size:

HTTP/1.1 200 OK
Accept-Ranges: bytes
Content-Encoding: identity
Content-Type: audio/wav
TuneBrowserIFID: 0b8aa17f
Content-Length: 48620028

File Size: 46.3 MB (48,623,616 bytes)

After downloading the URI directly, I confirmed that the actual file size is approximately 48.6 MB, which is consistent with this value.

However, when the same URI is requested by the DENON DMR (GStreamer + libsoup3), the response is:

User-Agent: GStreamer souphttpsrc 1.22.12 libsoup/3.6.5
Content-Length: 74508492

Since:

• the URI is identical,
• the HTTP status is 200 OK in both cases,
• and no Range request is involved,

this suggests that TuneBrowser is applying different Content-Length calculation strategies depending on the client (User-Agent).

The MPD-based path clearly demonstrates that TuneBrowser can provide the correct file-based Content-Length for WAV content.
The GStreamer/libsoup3 path, however, appears to use an estimated something-based length instead, which does not match the actual payload and causes issues with strict HTTP clients.

I hope this comparison is helpful, and I’m happy to run additional tests if needed.

Thank you

[storaid]

Sorry

but I don’t really get it!

v5.8.1 (GStreamer souphttpsrc 1.22.12 libsoup/3.6.5)

HTTP/1.1 200 OK

Accept-Ranges: bytes

...

TuneBrowserIFID: 0ba67ab5

Content-Length: 48620028

v5.9.2 (GStreamer souphttpsrc 1.22.12 libsoup/3.6.5)

HTTP/1.1 200 OK

Accept-Ranges: bytes

...

TuneBrowserIFID: 0ba85cb4

Content-Length: 74508492

[storaid]

Hello,

Sorry! Tiki

I still have a question regarding how TuneBrowser determines the Content-Length value in HTTP 200 OK responses for WAV/LPCM/L16 files.

As described in RFC9110 Section 8.6, the Content-Length header should indicate the total length of the HTTP response’s message body in bytes. This length should reflect exactly the number of octets being transmitted as content, including all file header and data chunks, matching the actual file size as stored on disk.

For reference, RFC9110 states:

“The ‘Content-Length’ header field indicates the associated representation’s data length as a decimal non-negative integer number of octets. … When transferring a representation as content, Content-Length refers specifically to the amount of data enclosed so that it can be used to delimit framing.”

“A sender MUST NOT forward a message with a Content-Length header field value that is known to be incorrect.”

RFC9110: https://www.rfc-editor.org/rfc/rfc9110.html#name-content-length

MDN: https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Content-Length

Given this, I would appreciate it if you could clarify how TuneBrowser calculates Content-Length. For example, is it based on the actual file size reported by the operating system, or is it derived from a calculation based on the file’s internal structure or audio chunks?

In my testing, I’ve noticed incongruities between the Content-Length header and the file size reported by Windows File Explorer or file system APIs.

Something-based Content-Length (v5.9.2): 74508492

Content-Length: 48620028

File Size (from Windows): 46.3 MB (48,623,616 bytes)

 

Thank you for your continued support and development!

[Tiki]

Hello.

Content-Length value uses the file size during file transfer. During decoding, it calculates and applies the size at the time of decoding.

Please save the log from the button in the upper-left corner of the Log View and attach it. The logs may be insufficient to confirm the situation, but I’ll check.

[Tiki]

Please handle the case with Content-Length: 74,508,492.

[storaid]

Hello, Tiki

Here is the log file with handling Content-Length: 74508492 case

Plz check it!

Thank you

Attachments:

1. 202602021807TuneBrowserLog.tblgz

[Tiki]

Thank you. I’ll check it.

[Tiki]

I checked the log.

Your Wireshark capture shows that the renderer is gettting next track ((03) [KOKIA] 愛のメロディー (soundtrack ver.).wav).

Your renderer is checking first track and next track at almost same time. I think what you saw was the second GET.

Time        : Thread: Log
-------------------------
18:05:24,200: T0e9c8: HTTPServer: [10.1.1.142:41848]: [GET] /TuneID/00018084-RFH-0BC02582.wav (47,481 KB)
18:05:24,200: T0e9c8: HTTPServer: [10.1.1.142:41848]: Tune: 00018084-RFH-0BC02582.wav
18:05:24,200: T0e9c8: HTTPServer: [10.1.1.142:41848]: -> \\10.1.1.125\music\KOKIA - 愛のメロディー／調和 oto ～with reflection～\(02) [KOKIA] 調和 oto ~with reflection~.wav
18:05:24,201: T0e9c8: HTTPServer: [10.1.1.142:41848]: Begin monitoring playback.

18:05:24,531: T0f420: HTTPServer: [10.1.1.142:41858]: [GET] /TuneID/00018085-RFH-64EA360E.wav (72,763 KB)
18:05:24,531: T0f420: HTTPServer: [10.1.1.142:41858]: Tune: 00018085-RFH-64EA360E.wav
18:05:24,531: T0f420: HTTPServer: [10.1.1.142:41858]: -> \\10.1.1.125\music\KOKIA - 愛のメロディー／調和 oto ～with reflection～\(03) [KOKIA] 愛のメロディー (soundtrack ver.).wav
18:05:24,533: T0f420: HTTPServer: [10.1.1.142:41858]: Begin monitoring playback.

18:05:34,815: T0e9c8: HTTPServer: [10.1.1.142:41848]: Sent 4194304 bytes. ← Sending "(02) [KOKIA] 調和 oto ~with reflection~.wav"
18:05:45,432: T0e9c8: HTTPServer: [10.1.1.142:41848]: Sent 6291456 bytes.
18:05:56,721: T0e9c8: HTTPServer: [10.1.1.142:41848]: Sent 8388608 bytes.
18:06:08,570: T0e9c8: HTTPServer: [10.1.1.142:41848]: Sent 10485760 bytes.

[storaid]

Hello Tiki,

I checked the log.

Your Wireshark capture shows that the renderer is gettting next track ((03) [KOKIA] 愛のメロディー (soundtrack ver.).wav).

Your renderer is checking first track and next track at almost same time. I think what you saw was the second GET.

Thank you very much for reviewing the logs and confirming the actual HTTP transaction details.

Upon double-checking my Wireshark capture and refining my filtering criteria, I’ve realized my mistake:

I mistakenly analyzed the GET request for the next URI, not the actively playing track.
After properly isolating the initial URI, I can confirm the Content-Length provided by TuneBrowser was entirely correct.

I apologize for the confusion—sometimes with Wireshark’s rapid packet updates and multi-threaded track management, it’s easy to mix up request contexts.

Unfortunately, with the DENON HEOS (GStreamer/libsoup3) environment, TrackDuration for WAV/LPCM/L16 still consistently returns 00:00:00, but I think that this may relate to DLNA tag support.

It’s not a pure UPnP Renderer.

Denon & Marantz Group devices…Orz

Based on my guess (I’m not sure!), it appears that the HEOS system (which uses GStreamer/libsoup3 under the hood) relies heavily on commercial DLNA metadata, particularly DIDL-Lite attributes and DLNA-specific headers/flags, to accurately detect and report track duration and seek capabilities. When these DLNA extensions, such as contentFeatures.dlna.org and DLNA.ORG_OP, are missing from the server’s response, HEOS treats the incoming stream as a live or linear broadcast, resulting in zero duration and disabling seeking functions.

Since TuneBrowser does not support commercial DLNA metadata extensions—by design, and as you mentioned long time ago— maybe this is the root cause of the missing duration metadata and seekbar issues in HEOS and similar devices.

Thank you again for your patience and confirmation!

[storaid]

I would like to express my disappointment with my recent experience with DENON support.
The DENON support I interacted with years ago — which was capable of understanding protocol-level UPnP issues — appears to no longer exist.

I contacted them regarding a UPnP issue strictly limited to WAV / LPCM / L16, yet the response I received consisted of questions such as:

1. Whether the same problem occurs with MP3
2. Whether the same problem occurs with FLAC
3. Whether a specific FLAC sample can be provided
4. Requests for HEOS diagnostic logs
5. Requests for a list of network devices
6. Questions about the third-party seek bar
7. Requests for generic reproduction steps

Given the context, these questions were extremely basic and largely irrelevant to the issue being reported.
They indicate that the original description was either not carefully read or not technically understood.

I had already provided detailed technical background, clearly explaining that this is a format-specific UPnP behavior affecting uncompressed PCM formats, not a general playback or content-compatibility problem.

In the past, when I raised UPnP-related questions to DENON support, they were at least able to grasp the technical intent and respond accordingly.
With the current level of interaction, I can only lower my expectations to the minimum.

🙁

 

[storaid]

Hello Tiki,

Please feel free to close this topic.

Given the current UPnP-compliant design, I think it is an appropriate time to conclude this discussion.

Thank you.

[Tiki]

Okay. Thanks.

[投稿者]

投稿