- このトピックには28件の返信、2人の参加者があり、最後ににより11ヶ月、 2週前に更新されました。
-
投稿
-
Hello, Tiki
plz try this sample link:
https://1drv.ms/u/s!AvA1navurakAiKhWJYeW_kQUPN0Jwg?e=QNovbd
{ "creatingLibrary":{"name":"MediaInfoLib","version":"23.10","url":"https://mediaarea.net/MediaInfo"}, "media":{"@ref":"D:\\OneDrive\\Private\\01_チア・チア_やくしまるえつこ.wav","track":[{"@type":"General","AudioCount":"1", "FileExtension":"wav", "Format":"Wave", "Format_Settings":"PcmWaveformat", "FileSize":"78894853", "Duration":"102.727", "OverallBitRate_Mode":"CBR", "OverallBitRate":"6144040", "StreamSize":"333", "Title":"01_????_????????", "Album":"[Hi-Res]やくしまるえつこ - チア・チア", "Track":"01_チア・チア_やくしまるえつこ", "Performer":"やくしまるえつこ", "Director":"????????", "File_Created_Date":"2023-11-15 13:42:48.762 UTC", "File_Created_Date_Local":"2023-11-15 21:42:48.762", "File_Modified_Date":"2019-10-10 09:38:16.470 UTC", "File_Modified_Date_Local":"2019-10-10 17:38:16.470", "OriginalSourceForm_Name":"[Hi-Res]???????? - ????"},{"@type":"Audio","Format":"PCM", "Format_Profile":"Float", "CodecID":"3", "Duration":"102.727", "BitRate_Mode":"CBR", "BitRate":"6144000", "Channels":"2", <strong>"SamplingRate":"96000"</strong>, "SamplingCount":"9861815", <strong>"BitDepth":"32"</strong>, "StreamSize":"78894520"}]} }I got an error message “Unsupported format” from DENON HEOS App
Test devices:
1. Denon: no response
2. iFi Streamer: SuccessfulI tried.
It seems that the TuneBrowser handled this file without any problems. Please ask to the device vendor.
However, I’m curious as to why the on-the-fly transcoding does not occur?
The reason is that whether to apply audio/L16 or not is based on the information in MIME.
At the MIME level, Renderer seems supporting wav.
Logging:
2023/11/16 21:49:30,359: UL00515: T0f728: UPnP_P: PlayerLogToUPnP is enabled. 2023/11/16 21:49:30,360: UL00517: T0f728: UPnP_P: Created player object: [UPnP: Denon Home 350] 2023/11/16 21:49:30,363: UL00520: T0f728: UPnP_P: Stage: [InitializePlayer] (omitted because of too long)Capture from wireshark:
As I said above, renderer is supporting wav. So TuneBrowser is using original wav file.
http-get:*:audio/wav:*
The renderer does not return an error. So, the TuneBrowser cannot detect error.
I attached the log you uploaded above.
No errors have occurred in UPnP (SOAP and GENA) processing.
I think the RST was generated during the HTTP file transfer, but the TuneBrowser does not determine from this behavior that the renderer is not capable of playing the file.
What actually happens next when the TuneBrowser player receives no errors?
The TuneBrowser’s Media Server (HTTP Server) sends the file. And stops sending when the renderer stops receiving or some error occurs or the connection is closed.
It is necessary to consider the possibility that the stop was made by another controller.
?
Could these triggered events above have been caused by playback, resulting in the stopping of playback?
It is necessary to consider the possibility that the stop was made by another controller.
I was taking about triggered events in your log.
As I said first, the TuneBrowser is working well for your file. At this time, I think there is no “further fine-tune”.
If you want to adjust by changing the setting:
– TreeItem: Playback settings – External UPnP renderer settings
– Property: External UPnP renderer settings – Use audio/L16If set this item to “If possible”, your file will play by your renderer as audio/L16. But most other files will also play as audio/L16. Perhaps that is not the result you want.
Thank you for your understanding.
I have added a USE_AUDIO_L16 tag support into the TuneBrowser 5.4.2.
If you set the value of this tag to 1, the TuneBrowser will tell the UPnP Renderer to use audio/L16.
Maybe this behavior will help you.
Hello, Tiki
Thank you for your help.
However, this improvement in functionality does not resolve my issue.
This is because it’s a problem caused by format unsupported.
The issue arises because Denon does not support 32-bit sources; Denon Home only supports PCM format up to 192k/24bit.
I am not sure if TuneBrowser can detect this problem.
I have captured packets with Wireshark and indeed, it returned a large number of RST packets.
Packet dump file(Wireshark):
https://1drv.ms/u/s!AvA1navurakAiKkyzo_EU0ylg74uDQ?e=JO5uJ4
Thanks
Thanks for the confirmation and your time.
I’m sorry it didn’t help.
That’s all of I can do about this matter.
UPnP controler (=TuneBrowser) determines which file to send based on only MIME information.
Before playback, controler sends SetAVTransportURI SOAP command to renderer. This command includes resource info like sample rate. If renderer accepts this command, then controler sends “Play” SOAP command.
On the other hand, UPnP media server (is also TuneBrowser) sends file when http get request is received.
Renderer can return error to controler as response of SOAP command.
These are almost all of the processes.
Hello, Tiki
I have used some UPnP development tools for testing and I think I have identified the clues.
Although the renderer is unable to do successful playback and is returning a large number of RST packets, the problem is that the SOAP call to ‘Play’ does not return any errors, nor are any exceptions thrown.
This apparently leads TuneBrowser to be unaware of the actual status of the renderer.
I believe this could explain why TuneBrowser assumes that the ‘Play’ SOAP operation is proceeding without any anomalies.
I can’t understand from the screenshot, but if an RST is being returned, it will be to the media server.
Anyway, it is sure that the TuneBrowser cannot detect problem from this control situation.
Can I close this topic ?
Thank you for your understanding and P.S. info.
- トピック「Playing 96KHz/32bits wav file failed!」には新しい返信をつけることはできません。