Seekbar Question about TuneBrowser using DIDL-Lite

フォーラム › TuneBrowser › Seekbar Question about TuneBrowser using DIDL-Lite

  • このトピックには30件の返信、2人の参加者があり、最後にstoraidにより3時間、 39分前に更新されました。
31件の投稿を表示中 - 1 - 31件目 (全31件中)
  • 投稿者
    投稿
  • 2025-11-29 23:10 #17162
    storaid
    参加者

    Hi Tiki,

    I have question..

    Does TuneBrowser currently use the duration from DIDL-Lite metadata (<res duration=”…”>)?

    When I inspected the UPnP traffic, it seemed that TuneBrowser retrieves DIDL metadata returned in GetPositionInfo, and may be using the duration attribute from the <res> element. It’s right?

    Denon support responded to my inquiry and stated the following:

    The seekbar should be rely on AVTransport values such as TrackDuration and RelTime / AbsTime.
    DIDL metadata should not be used for seekbar calculation, because DIDL duration is only descriptive metadata and may not match the renderer’s actual playback behavior.

    This matches the UPnP AV, which classify DIDL <res> attributes (including duration) as optional descriptive metadata, while playback state and timeline information must come from AVTransport.

    https://upnp.org/specs/av/UPnP-av-ContentDirectory-v1-Service.pdf

    Page 9, res is not required, but multiple values is valid.

    2025-11-30 20:22 #17171
    Tiki
    キーマスター

    Hello.

    Does TuneBrowser currently use the duration from DIDL-Lite metadata (<res duration=”…”>)?

    Yes, TuneBrowser is using it from AVTransport event and GetPositionInfo SOAP command.

    I found from your comment that res is not required. However, TuneBrowser requires DIDL res information when importing unknown musics. And you know, duration is a static information of music file, so it is stored in database. Elapsed time like RelTime is a dynamic information and it is checked and updated each time during playback. As app for managing music files in a database, these are different nature.

    2025-11-30 21:53 #17172
    storaid
    参加者

    Hi Tiki,

    Thank you for your explanation.

    Elapsed time like RelTime is a dynamic information and it is checked and updated each time during playback.

    Yes, RelTime is dynamic, but TrackDuration is not, right?

    Actually, one reason I am concerned about relying on the DIDL-Lite metadata for seekbar duration is that, in practice, the content of DIDL from various vendors is not standardized.

    Each device or server can provide very different structures, attributes, or even omit certain metadata fields. For example, the <res duration> attribute is optional and often implemented inconsistently.

    Because DIDL is so flexible and open to vendor-specific extensions, using it for playback control (such as the seekbar’s total duration) can sometimes lead to compatibility problems—especially when there are multiple <res> tags or unexpected attribute values.

    That’s why I think using TrackDuration from the AVTransport, which is designed to provide the accurate total time of the currently playing track, is more robust and reliable for seekbar control.

    Is it possible to use TrackDuration as the total duration of the seekbar?

    Thanks..

    2025-12-02 20:21 #17175
    Tiki
    キーマスター

    Thank you for sharing your thoughts.

    I’d like to consider what can I do.

    2025-12-20 17:36 #17212
    Tiki
    キーマスター

    Hello storaid,

    I have tried using TrackDuration in 1817. Please try it when you have time.

    Thank you.

    2025-12-22 10:27 #17217
    storaid
    参加者

    Hi,

    Thank you for implementing TrackDuration support in TuneBrowser 1817.

    I have tested it with both ifi-audio ZenStream (very OLD volumio) and Denon Home Speaker (HEOS).

    Previously, due to inconsistent or nested DIDL structures and missing duration metadata, the seekbar was unreliable and often failed.

    After updating, the seekbar now works consistently and correctly in my environment.

    I appreciate your effort and responsiveness!

    Thanks

    2025-12-22 19:31 #17218
    Tiki
    キーマスター

    Great. Thank you for confirming.

    2025-12-29 19:26 #17222
    storaid
    参加者

    Hi, Tiki

    I’ve been testing this for about a week and I think I may have found something worth checking.

    For some Japanese DMRs (especially Denon/Marantz), the reported TrackDuration often has small precision errors, which seems to affect their internal EOF detection. As a result, even when playback has actually finished, the device sometimes does not move on to the next track.

    This made me wonder:
    Does TuneBrowser currently monitor the AVTransport LastChange event?

    During testing, I noticed that although the device sometimes fails to advance the track on its own, it does correctly send:

    

6:15 PM Denon Home 350/urn:upnp-org:serviceId:AVTransport LastChange

<Event xmlns="urn:schemas-upnp-org:metadata-1-0/AVT/"><InstanceID val="0"><TransportState val="STOPPED"/></InstanceID></Event>

    in the LastChange event.

    So I’m thinking that subscribing to LastChange and using TransportState=STOPPED as a trigger might help handle these cases.

    I’m not sure if TuneBrowser already uses this mechanism, so I wanted to ask in case this observation is useful.

    Thank you as always for your great work.

    2025-12-31 08:02 #17224
    Tiki
    キーマスター

    Hi,

    TuneBrowser is subscribing events including AVTransport.

    Thanks.

    2025-12-31 09:33 #17226
    storaid
    参加者

    Hi, Tiki

    Thank you for your reply.

    I did notice that even when playback is finished (for example, 251 sec / 251 sec, playback actually stopped), the seek bar remains at the end and the next track does not automatically start.

    It seems to be related to the DMR’s internal EOF detection.

    For reference:

    

251 sec / 251 sec
251 sec / 251 sec
251 sec / 251 sec
251 sec / 251 sec
251 sec / 251 sec

    I have confirmed in my log that the DMR does send TransportState=STOPPED in LastChange.

    Does TuneBrowser’s current event handling trigger next-track/track advance logic on TransportState=STOPPED (from LastChange), or does it only rely on position polling something internal logic?

    It looks like in this case, manual intervention is required to go to the next track, so I guess the event may not be used for this scenario.

    Thank you very much for your help!

    2025-12-31 10:08 #17227
    storaid
    参加者

    Tested Devices and Results:

    ifi-audio Zen Stream (old: v3): Works as expected
    Volumio (new): Works as expected
    moOde: Works as expected
    Holo RED: Works as expected
    WiiM Plus (Linkplay): Works as expected
    DENON Device: For some tracks, does not move on to the next track (likely due to internal EOF detection caused by TrackDuration’s small precision errors), but does send TransportState=STOPPED in the LastChange event when playback is completed.
    Marantz Device: Same behavior as DENON

    Thank you for your attention and your great support.

    If you need any further details or logs, I’d be happy to provide them.

    2025-12-31 21:29 #17229
    Tiki
    キーマスター

    Does TuneBrowser’s current event handling trigger next-track/track advance logic on TransportState=STOPPED (from LastChange), or does it only rely on position polling something internal logic?

    Event STOPPED is trigger to the next track when device is under control.

    You can save a log file by toolbar button of the Log View (This log file contains several files shown in Log View tabs). Please attach this file. I’d like to check it in a few days.

    2025-12-31 22:11 #17230
    storaid
    参加者

    Hello Tiki,

    I used Wireshark to analyze TuneBrowser’s UPnP event behavior with different DMR devices.
    During testing, I noticed that devices based on upmpdcli (Volumio, moOde, RED OS, etc.) tend to behave more leniently with UPnP event subscriptions — even if the controller does not renew the subscription, these devices often continue sending LastChange events without interruption.

    However, when testing with Denon/Marantz devices, I observed a different behavior that seems strictly aligned with the UPnP Eventing specification:

    1. Timeout handling
    TuneBrowser sends TIMEOUT: Second-360, but Denon/Marantz responds with TIMEOUT: Second-300, which is valid per UPnP specifications.

    2. No SUBSCRIBE renewal observed
    In Wireshark, I did not see TuneBrowser sending a SUBSCRIBE renewal with the assigned SID before the 300-second timeout returned by the DMR.

    3. Subscription expiration
    Exactly at 300 seconds, Denon/Marantz stops sending AVTransport LastChange events.
    When a track is longer than 300 seconds, TuneBrowser does not receive the final TransportState=STOPPED, which prevents automatic track advance.

    Does TuneBrowser currently implement automatic renewal of AVTransport subscriptions based on the TIMEOUT value returned by the DMR (rather than the value sent by TuneBrowser)?

    If renewal is already implemented, perhaps Denon’s strict timeout behavior requires a slightly different handling.

    Denon/Marantz devices seems like to follow the specification very strictly. Orz

    Thank you very much for your excellent work on TuneBrowser!

    UPnP Log:

    

2025/12/31 21:07:41,512: UL43712: T01df8: UPnP_M: USNID_03 is new. Poll description to device: uuid:aedc4ed9-0c85-48c5-8cf8-a7ff09ab5b7d::urn:schemas-upnp-org:device:WANConnectionDevice:2
2025/12/31 21:07:41,512: UL43713: T01df8: UPnP_M: *** Processing USNID_02 by NOTIFY from: 10.1.1.15 : [uuid:aedc4ed9-0c85-48c5-8cf8-a7ff09ab5b7c::urn:schemas-upnp-org:device:WANDevice:2]
2025/12/31 21:07:41,512: UL43714: T01df8: UPnP_M: This is TargetURN: NT: [urn:schemas-upnp-org:device:WANDevice:2]
2025/12/31 21:07:41,512: UL43715: T01df8: UPnP_M: ProcDeviceUSN: USNID_02 STAY ( 1): [IPv4]: FN:[] USN:[uuid:aedc4ed9-0c85-48c5-8cf8-a7ff09ab5b7c::urn:schemas-upnp-org:device:WANDevice:2]
2025/12/31 21:07:41,512: UL43716: T01df8: UPnP_M: USNID_02 is new. Poll description to device: uuid:aedc4ed9-0c85-48c5-8cf8-a7ff09ab5b7c::urn:schemas-upnp-org:device:WANDevice:2
2025/12/31 21:07:41,514: UL43718: T03694: UPnP_M: Poll device to: 10.1.1.15 [http://10.1.1.15:46721/rootDesc.xml]
2025/12/31 21:07:41,528: UL43719: T02774: UPnP_M: Description contains 2 devices.
2025/12/31 21:07:41,528: UL43720: T02774: UPnP_M: - deviceType(URN) is TargetURN: [urn:schemas-upnp-org:device:WANDevice:2]
2025/12/31 21:07:41,528: UL43721: T02774: UPnP_M: Not interested service 1: urn:schemas-upnp-org:service:WANCommonInterfaceConfig:1
2025/12/31 21:07:41,528: UL43722: T02774: UPnP_M: No interested services found.
2025/12/31 21:07:41,528: UL43723: T02774: UPnP_M: - deviceType(URN) is TargetURN: [urn:schemas-upnp-org:device:WANConnectionDevice:2]
2025/12/31 21:07:41,528: UL43724: T02774: UPnP_M: Not interested service 1: urn:schemas-upnp-org:service:WANIPConnection:2
2025/12/31 21:07:41,528: UL43725: T02774: UPnP_M: Not interested service 2: urn:schemas-upnp-org:service:WANIPv6FirewallControl:1
2025/12/31 21:07:41,528: UL43726: T02774: UPnP_M: No interested services found.
2025/12/31 21:07:41,529: UL43727: T02774: UPnP_M: - NOT Target device: 10.1.1.15 [10.1.1.15]
2025/12/31 21:07:41,529: UL43728: T02774: UPnP_M: - DeviceType : [urn:schemas-upnp-org:device:WANConnectionDevice:2]
2025/12/31 21:07:41,529: UL43729: T02774: UPnP_M: - Location : [http://10.1.1.15:46721/rootDesc.xml]
2025/12/31 21:07:41,529: UL43730: T02774: UPnP_M: - USN : [uuid:aedc4ed9-0c85-48c5-8cf8-a7ff09ab5b7b::urn:schemas-upnp-org:device:InternetGatewayDevice:2]
2025/12/31 21:07:41,529: UL43731: T02774: UPnP_M: - USNID : [USNID_04]
2025/12/31 21:07:41,530: UL43733: T02774: UPnP_M: Poll device to: 10.1.1.15 [http://10.1.1.15:46721/rootDesc.xml]
2025/12/31 21:07:41,533: UL43734: T02774: UPnP_M: Description contains 2 devices.
2025/12/31 21:07:41,533: UL43735: T02774: UPnP_M: - deviceType(URN) is TargetURN: [urn:schemas-upnp-org:device:WANDevice:2]
2025/12/31 21:07:41,534: UL43736: T02774: UPnP_M: Not interested service 1: urn:schemas-upnp-org:service:WANCommonInterfaceConfig:1
2025/12/31 21:07:41,534: UL43737: T02774: UPnP_M: No interested services found.
2025/12/31 21:07:41,534: UL43738: T02774: UPnP_M: - deviceType(URN) is TargetURN: [urn:schemas-upnp-org:device:WANConnectionDevice:2]
2025/12/31 21:07:41,534: UL43739: T02774: UPnP_M: Not interested service 1: urn:schemas-upnp-org:service:WANIPConnection:2
2025/12/31 21:07:41,534: UL43740: T02774: UPnP_M: Not interested service 2: urn:schemas-upnp-org:service:WANIPv6FirewallControl:1
2025/12/31 21:07:41,534: UL43741: T02774: UPnP_M: No interested services found.
2025/12/31 21:07:41,534: UL43742: T02774: UPnP_M: - NOT Target device: 10.1.1.15 [10.1.1.15]
2025/12/31 21:07:41,534: UL43743: T02774: UPnP_M: - DeviceType : [urn:schemas-upnp-org:device:WANConnectionDevice:2]
2025/12/31 21:07:41,534: UL43744: T02774: UPnP_M: - Location : [http://10.1.1.15:46721/rootDesc.xml]
2025/12/31 21:07:41,534: UL43745: T02774: UPnP_M: - USN : [uuid:aedc4ed9-0c85-48c5-8cf8-a7ff09ab5b7c::urn:schemas-upnp-org:device:WANDevice:2]
2025/12/31 21:07:41,534: UL43746: T02774: UPnP_M: - USNID : [USNID_02]
2025/12/31 21:07:41,754: UL43747: T01df8: UPnP_M: *** Processing USNID_02 by NOTIFY from: 10.1.1.15 : [uuid:aedc4ed9-0c85-48c5-8cf8-a7ff09ab5b7c::urn:schemas-upnp-org:device:WANDevice:2]
2025/12/31 21:07:41,762: UL43748: T01df8: UPnP_M: This is TargetURN: NT: [urn:schemas-upnp-org:device:WANDevice:2]
2025/12/31 21:07:41,762: UL43749: T01df8: UPnP_M: ProcDeviceUSN: USNID_02 STAY ( 1): [IPv4]: FN:[] USN:[uuid:aedc4ed9-0c85-48c5-8cf8-a7ff09ab5b7c::urn:schemas-upnp-org:device:WANDevice:2]
2025/12/31 21:07:41,762: UL43750: T01df8: UPnP_M: USNID_02 is new. Poll description to device: uuid:aedc4ed9-0c85-48c5-8cf8-a7ff09ab5b7c::urn:schemas-upnp-org:device:WANDevice:2
2025/12/31 21:07:41,762: UL43752: T02774: UPnP_M: Poll device to: 10.1.1.15 [http://10.1.1.15:46721/rootDesc.xml]
2025/12/31 21:07:41,764: UL43753: T01df8: UPnP_M: *** Processing USNID_03 by NOTIFY from: 10.1.1.15 : [uuid:aedc4ed9-0c85-48c5-8cf8-a7ff09ab5b7d::urn:schemas-upnp-org:device:WANConnectionDevice:2]
2025/12/31 21:07:41,764: UL43754: T01df8: UPnP_M: This is TargetURN: NT: [urn:schemas-upnp-org:device:WANConnectionDevice:2]
2025/12/31 21:07:41,764: UL43755: T01df8: UPnP_M: ProcDeviceUSN: USNID_03 STAY ( 1): [IPv4]: FN:[] USN:[uuid:aedc4ed9-0c85-48c5-8cf8-a7ff09ab5b7d::urn:schemas-upnp-org:device:WANConnectionDevice:2]
2025/12/31 21:07:41,764: UL43756: T01df8: UPnP_M: USNID_03 is new. Poll description to device: uuid:aedc4ed9-0c85-48c5-8cf8-a7ff09ab5b7d::urn:schemas-upnp-org:device:WANConnectionDevice:2
2025/12/31 21:07:41,764: UL43757: T01df8: UPnP_M: *** Processing USNID_04 by NOTIFY from: 10.1.1.15 : [uuid:aedc4ed9-0c85-48c5-8cf8-a7ff09ab5b7b::urn:schemas-upnp-org:device:InternetGatewayDevice:2]
2025/12/31 21:07:41,764: UL43758: T01df8: UPnP_M: This is TargetURN: NT: [urn:schemas-upnp-org:device:InternetGatewayDevice:2]
2025/12/31 21:07:41,764: UL43759: T01df8: UPnP_M: ProcDeviceUSN: USNID_04 STAY ( 1): [IPv4]: FN:[] USN:[uuid:aedc4ed9-0c85-48c5-8cf8-a7ff09ab5b7b::urn:schemas-upnp-org:device:InternetGatewayDevice:2]
2025/12/31 21:07:41,764: UL43760: T01df8: UPnP_M: USNID_04 is new. Poll description to device: uuid:aedc4ed9-0c85-48c5-8cf8-a7ff09ab5b7b::urn:schemas-upnp-org:device:InternetGatewayDevice:2
2025/12/31 21:07:41,771: UL43761: T02774: UPnP_M: Description contains 2 devices.
2025/12/31 21:07:41,771: UL43762: T02774: UPnP_M: - deviceType(URN) is TargetURN: [urn:schemas-upnp-org:device:WANDevice:2]
2025/12/31 21:07:41,772: UL43763: T02774: UPnP_M: Not interested service 1: urn:schemas-upnp-org:service:WANCommonInterfaceConfig:1
2025/12/31 21:07:41,772: UL43764: T02774: UPnP_M: No interested services found.
2025/12/31 21:07:41,772: UL43765: T02774: UPnP_M: - deviceType(URN) is TargetURN: [urn:schemas-upnp-org:device:WANConnectionDevice:2]
2025/12/31 21:07:41,772: UL43766: T02774: UPnP_M: Not interested service 1: urn:schemas-upnp-org:service:WANIPConnection:2
2025/12/31 21:07:41,772: UL43767: T02774: UPnP_M: Not interested service 2: urn:schemas-upnp-org:service:WANIPv6FirewallControl:1
2025/12/31 21:07:41,772: UL43768: T02774: UPnP_M: No interested services found.
2025/12/31 21:07:41,772: UL43769: T02774: UPnP_M: - NOT Target device: 10.1.1.15 [10.1.1.15]
2025/12/31 21:07:41,772: UL43770: T02774: UPnP_M: - DeviceType : [urn:schemas-upnp-org:device:WANConnectionDevice:2]
2025/12/31 21:07:41,772: UL43771: T02774: UPnP_M: - Location : [http://10.1.1.15:46721/rootDesc.xml]
2025/12/31 21:07:41,772: UL43772: T02774: UPnP_M: - USN : [uuid:aedc4ed9-0c85-48c5-8cf8-a7ff09ab5b7c::urn:schemas-upnp-org:device:WANDevice:2]
2025/12/31 21:07:41,772: UL43773: T02774: UPnP_M: - USNID : [USNID_02]
2025/12/31 21:07:41,772: UL43775: T02774: UPnP_M: Poll device to: 10.1.1.15 [http://10.1.1.15:46721/rootDesc.xml]
2025/12/31 21:07:41,774: UL43776: T02774: UPnP_M: Description contains 2 devices.
2025/12/31 21:07:41,774: UL43777: T02774: UPnP_M: - deviceType(URN) is TargetURN: [urn:schemas-upnp-org:device:WANDevice:2]
2025/12/31 21:07:41,774: UL43778: T02774: UPnP_M: Not interested service 1: urn:schemas-upnp-org:service:WANCommonInterfaceConfig:1
2025/12/31 21:07:41,774: UL43779: T02774: UPnP_M: No interested services found.
2025/12/31 21:07:41,774: UL43780: T02774: UPnP_M: - deviceType(URN) is TargetURN: [urn:schemas-upnp-org:device:WANConnectionDevice:2]
2025/12/31 21:07:41,774: UL43781: T02774: UPnP_M: Not interested service 1: urn:schemas-upnp-org:service:WANIPConnection:2
2025/12/31 21:07:41,774: UL43782: T02774: UPnP_M: Not interested service 2: urn:schemas-upnp-org:service:WANIPv6FirewallControl:1
2025/12/31 21:07:41,774: UL43783: T02774: UPnP_M: No interested services found.
2025/12/31 21:07:41,774: UL43784: T02774: UPnP_M: - NOT Target device: 10.1.1.15 [10.1.1.15]
2025/12/31 21:07:41,774: UL43785: T02774: UPnP_M: - DeviceType : [urn:schemas-upnp-org:device:WANConnectionDevice:2]
2025/12/31 21:07:41,774: UL43786: T02774: UPnP_M: - Location : [http://10.1.1.15:46721/rootDesc.xml]
2025/12/31 21:07:41,774: UL43787: T02774: UPnP_M: - USN : [uuid:aedc4ed9-0c85-48c5-8cf8-a7ff09ab5b7d::urn:schemas-upnp-org:device:WANConnectionDevice:2]
2025/12/31 21:07:41,775: UL43788: T02774: UPnP_M: - USNID : [USNID_03]
2025/12/31 21:07:41,776: UL43790: T02774: UPnP_M: Poll device to: 10.1.1.15 [http://10.1.1.15:46721/rootDesc.xml]
2025/12/31 21:07:41,778: UL43791: T02774: UPnP_M: Description contains 2 devices.
2025/12/31 21:07:41,778: UL43792: T02774: UPnP_M: - deviceType(URN) is TargetURN: [urn:schemas-upnp-org:device:WANDevice:2]
2025/12/31 21:07:41,778: UL43793: T02774: UPnP_M: Not interested service 1: urn:schemas-upnp-org:service:WANCommonInterfaceConfig:1
2025/12/31 21:07:41,778: UL43794: T02774: UPnP_M: No interested services found.
2025/12/31 21:07:41,778: UL43795: T02774: UPnP_M: - deviceType(URN) is TargetURN: [urn:schemas-upnp-org:device:WANConnectionDevice:2]
2025/12/31 21:07:41,779: UL43796: T02774: UPnP_M: Not interested service 1: urn:schemas-upnp-org:service:WANIPConnection:2
2025/12/31 21:07:41,779: UL43797: T02774: UPnP_M: Not interested service 2: urn:schemas-upnp-org:service:WANIPv6FirewallControl:1
2025/12/31 21:07:41,779: UL43798: T02774: UPnP_M: No interested services found.
2025/12/31 21:07:41,779: UL43799: T02774: UPnP_M: - NOT Target device: 10.1.1.15 [10.1.1.15]
2025/12/31 21:07:41,779: UL43800: T02774: UPnP_M: - DeviceType : [urn:schemas-upnp-org:device:WANConnectionDevice:2]
2025/12/31 21:07:41,779: UL43801: T02774: UPnP_M: - Location : [http://10.1.1.15:46721/rootDesc.xml]
2025/12/31 21:07:41,779: UL43802: T02774: UPnP_M: - USN : [uuid:aedc4ed9-0c85-48c5-8cf8-a7ff09ab5b7b::urn:schemas-upnp-org:device:InternetGatewayDevice:2]
2025/12/31 21:07:41,779: UL43803: T02774: UPnP_M: - USNID : [USNID_04]
2025/12/31 21:07:41,826: UL43804: T03694: UPnP_M: Description contains 2 devices.
2025/12/31 21:07:41,826: UL43805: T03694: UPnP_M: - deviceType(URN) is TargetURN: [urn:schemas-upnp-org:device:WANDevice:2]
2025/12/31 21:07:41,827: UL43806: T03694: UPnP_M: Not interested service 1: urn:schemas-upnp-org:service:WANCommonInterfaceConfig:1
2025/12/31 21:07:41,827: UL43807: T03694: UPnP_M: No interested services found.
2025/12/31 21:07:41,827: UL43808: T03694: UPnP_M: - deviceType(URN) is TargetURN: [urn:schemas-upnp-org:device:WANConnectionDevice:2]
2025/12/31 21:07:41,827: UL43809: T03694: UPnP_M: Not interested service 1: urn:schemas-upnp-org:service:WANIPConnection:2
2025/12/31 21:07:41,827: UL43810: T03694: UPnP_M: Not interested service 2: urn:schemas-upnp-org:service:WANIPv6FirewallControl:1
2025/12/31 21:07:41,827: UL43811: T03694: UPnP_M: No interested services found.
2025/12/31 21:07:41,827: UL43812: T03694: UPnP_M: - NOT Target device: 10.1.1.15 [10.1.1.15]
2025/12/31 21:07:41,827: UL43813: T03694: UPnP_M: - DeviceType : [urn:schemas-upnp-org:device:WANConnectionDevice:2]
2025/12/31 21:07:41,827: UL43814: T03694: UPnP_M: - Location : [http://10.1.1.15:46721/rootDesc.xml]
2025/12/31 21:07:41,827: UL43815: T03694: UPnP_M: - USN : [uuid:aedc4ed9-0c85-48c5-8cf8-a7ff09ab5b7d::urn:schemas-upnp-org:device:WANConnectionDevice:2]
2025/12/31 21:07:41,827: UL43816: T03694: UPnP_M: - USNID : [USNID_03]
2025/12/31 21:07:42,327: UL43818: T06a3c: UPnP_P: [Proc:RelTime ] <POL>: Elapsed: 00:05:18 -> 318.0 / 318.0 sec
2025/12/31 21:07:43,326: UL43820: T06a3c: UPnP_P: [Proc:RelTime ] <POL>: Elapsed: 00:05:18 -> 318.0 / 318.0 sec
2025/12/31 21:07:44,326: UL43822: T06a3c: UPnP_P: [Proc:RelTime ] <POL>: Elapsed: 00:05:18 -> 318.0 / 318.0 sec
2025/12/31 21:07:45,325: UL43824: T06a3c: UPnP_P: [Proc:RelTime ] <POL>: Elapsed: 00:05:18 -> 318.0 / 318.0 sec
2025/12/31 21:07:46,324: UL43826: T06a3c: UPnP_P: [Proc:RelTime ] <POL>: Elapsed: 00:05:18 -> 318.0 / 318.0 sec
2025/12/31 21:07:47,322: UL43828: T06a3c: UPnP_P: [Proc:RelTime ] <POL>: Elapsed: 00:05:18 -> 318.0 / 318.0 sec
2025/12/31 21:07:48,322: UL43830: T06a3c: UPnP_P: [Proc:RelTime ] <POL>: Elapsed: 00:05:18 -> 318.0 / 318.0 sec
2025/12/31 21:07:49,321: UL43833: T06a3c: UPnP_P: [Proc:RelTime ] <POL>: Elapsed: 00:05:18 -> 318.0 / 318.0 sec
2025/12/31 21:07:50,319: UL43837: T06a3c: UPnP_P: [Proc:RelTime ] <POL>: Elapsed: 00:05:18 -> 318.0 / 318.0 sec
2025/12/31 21:07:51,318: UL43850: T06a3c: UPnP_P: [Proc:RelTime ] <POL>: Elapsed: 00:05:18 -> 318.0 / 318.0 sec
2025/12/31 21:07:52,317: UL43852: T06a3c: UPnP_P: [Proc:RelTime ] <POL>: Elapsed: 00:05:18 -> 318.0 / 318.0 sec
2025/12/31 21:07:53,316: UL43860: T06a3c: UPnP_P: [Proc:RelTime ] <POL>: Elapsed: 00:05:18 -> 318.0 / 318.0 sec
    2025-12-31 22:16 #17231
    Tiki
    キーマスター

    Please attach a log file saved by Toolbar button of Log View.

    2025-12-31 22:18 #17232
    storaid
    参加者

    Hi,

    Here is the log file!

    Thanks

    Attachments:
    1. TuneBrowserLog.tblgz
    2025-12-31 23:22 #17234
    Tiki
    キーマスター

    Thank you.

    2026-01-03 12:05 #17239
    Tiki
    キーマスター

    Hello storaid.

    Thank you for your analysis and attaching the log file.

    As you mentioned, TuneBrowser does not re-subscribe to events after a timeout. I understood that this needs to be implemented, so I will consider addressing it in a release in the (near) future.

    Thank you.

    2026-01-17 10:22 #17303
    Tiki
    キーマスター

    Hi,

    I have released preliminay release of 5.9.2. I tried to improve this matter. Please try it when you have time.

    Thanks.

    2026-01-17 11:55 #17304
    storaid
    参加者

    Hello Tiki,

    Thank you very much for the improvement.
    I’m currently testing the new behavior, so please give me a little time to analyze it in detail.

    I also have a small suggestion regarding the wording of the new setting:

    SUBSCRIBE Advance (sec)
    “Specify the margin (advance) in seconds relative to the specified SUBSCRIBE timeout.
    Re-SUBSCRIBE operation will be performed advanced by the number of seconds specified here.”

    The naming and description feel a bit unnatural in English.
    Perhaps using a different term would make the meaning clearer. For example:

    Resubscribe Margin (sec)
    “Specify how many seconds before the timeout TuneBrowser should renew the event subscription.”

    The word “Advance” can be slightly confusing in this context, while terms like “Margin” or “Lead Time” more clearly express a buffer before the subscription expires.

    In addition, I noticed something interesting during testing.

    When “Redo SUBSCRIBE before playback” is disabled,

    TuneBrowser sends the initial SUBSCRIBE after startup and then continually listens for events.
    However, sometimes in some cases I encountered the following errors:

    

2026/01/17 10:45:58,148: UL33471: T02fd0: Warning: UPnP_P: [SOAP Request]: XMLReader detected error: 0xc00cee2b (WC_E_XMLCHARACTER)
2026/01/17 10:45:58,148: UL33473: T02fd0: Warning: UPnP_P: [SOAP Request]: - OS Error: [illegal xml character]
2026/01/17 10:45:58,148: UL33475: T02fd0: Warning: UPnP_P: [SOAP Request]: - Source : [10.1.1.142 [http://10.1.1.142:60006/upnp/control/renderer_dvc/AVTransport]]
2026/01/17 10:45:58,148: UL33477: T02fd0: Warning: UPnP_P: [SOAP Request]: - At line 5, column 351
2026/01/17 10:45:58,148: UL33479: T02fd0: Warning: UPnP_P: [SOAP Request]: - Line:5 : [<TrackMetaData><DIDL-Lite xmlns=&quot;urn:schemas-upnp-org:metadata-1-0/DIDL-(...)]

    Could you please take a look when you have time?
    It seems the renderer might be sending an invalid XML character inside TrackMetaData.

    Thank you again for your continued work on TuneBrowser!

    Attachments:
    1. TuneBrowserLog_NoRedo.tblgz
    2026-01-17 12:04 #17306
    storaid
    参加者

    Other Examples:

    [Property Name]

    a. Re-SUBSCRIBE Margin (sec)

    b. Subscription Renewal Margin (sec)

    c. Subscription Renewal (sec)

    [Description]

    a. Specify how many seconds before the SUBSCRIBE timeout TuneBrowser should perform the re-SUBSCRIBE.

    b. Specifies the number of seconds before the SUBSCRIBE timeout at which TuneBrowser will send a re-SUBSCRIBE request.

    2026-01-17 17:09 #17310
    storaid
    参加者

    Hello, Tiki

    Maybe I found a potential UI bug in v5.9.2: The value for ‘SUBSCRIBE Advance (sec)’ cannot be changed or saved; it reverts to 3 every time. Please check if this field is incorrectly set to read-only.

    Thanks

    2026-01-17 20:02 #17312
    storaid
    参加者

    Hello Tiki

    I checked the SUBSCRIBE packet in v5.9.2 via Wireshark. It seems it is performing a new subscription instead of a renewal.
    1. It contains CALLBACK and NT headers (which should only be in the first subscription).
    2. It is missing the SID header from the previous subscription.

    TuneBrowser Example:

    Re-SUBSCRIBE

    

SUBSCRIBE /upnp/event/renderer_dvc/AVTransport HTTP/1.1\r\n
Request Method: SUBSCRIBE
Request URI: /upnp/event/renderer_dvc/AVTransport
Request Version: HTTP/1.1
HOST: 10.1.1.142:60006\r\n
USER-AGENT: Windows/10.0 UPnP/1.1 ohNet/1.0 TuneBrowser/1.0\r\n
CALLBACK: <http://10.1.1.166:29500/SR_AVTransport.notify>\r\n
NT: upnp:event\r\n
TIMEOUT: Second-360\r\n
Content-Length: 0\r\n
[Content length: 0]
\r\n

    RE-SUBSCRIBE Example:

    AFAIK, Renewal should only contain the SID and TIMEOUT, and must exclude CALLBACK/NT.

    Otherwise, it will be a new subscription..

     

    Thank you very much for your great work on TuneBrowser!

    2026-01-17 20:29 #17313
    storaid
    参加者

    From a UPnP-specification perspective:
    If a controller repeatedly performs “initial SUBSCRIBE” instead of sending a renewal with the existing SID, some DMR devices may internally register multiple subscriptions before their timeout expires.
    On most modern devices this is handled safely, but on certain hardware-limited DMRs it could potentially lead to resource issues over long playback sessions.

    Therefore, implementing the standard SID-based renewal process would provide the highest compatibility and long-term stability across all types of DMRs.

    Thank you again for continuing to improve TuneBrowser — the software keeps getting better with every release.

     

    2026-01-17 21:04 #17314
    Tiki
    キーマスター

    Development is difficult. Which part of the specifications should I refer to in order to understand the operation you mentioned?

    2026-01-17 21:27 #17315
    storaid
    参加者

    Hello, Tiki

    Here is what I know about UPnP..
    The behavior I mentioned—renewing an existing event subscription using the SID—comes directly from the UPnP Device Architecture (UDA) specification.

    Here are the relevant parts of the specification:

    UPnP Device Architecture 1.0 / 1.1 — Eventing (Section: GENA Eventing)

    1. Initial SUBSCRIBE
    The controller sends:
    CALLBACK
    NT: upnp:event
    TIMEOUT

    Example:

    

Hypertext Transfer Protocol
SUBSCRIBE /upnp/event/renderer_dvc/AVTransport HTTP/1.1\r\n
Request Method: SUBSCRIBE
Request URI: /upnp/event/renderer_dvc/AVTransport
Request Version: HTTP/1.1
HOST: 10.1.1.142:60006\r\n
USER-AGENT: Windows/10.0 UPnP/1.1 ohNet/1.0 TuneBrowser/1.0\r\n
CALLBACK: <http://10.1.1.166:29500/SR_AVTransport.notify>\r\n
NT: upnp:event\r\n
TIMEOUT: Second-360\r\n
Content-Length: 0\r\n
[Content length: 0]
\r\n

    Then, DMR return the following:

    

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
Connection: Keep-Alive\r\n
Content-Length: 0\r\n
[Content length: 0]
SERVER: Linux/4.4.167+, UPnP/1.0, Portable SDK for UPnP devices/4.0.14\r\n
TIMEOUT: Second-300\r\n
SID: uuid:cff1b202-e395-1370-b3aa-80e94ad851a3\r\n
\r\n

    Please remember SID, TIMEOUT

    2. Subscription Renewal (Re-SUBSCRIBE)
    To extend the duration of an existing subscription before it expires, the controller must send a SUBSCRIBE request using the existing SID (uuid:<first subscription sid>):

    

Hypertext Transfer Protocol
SUBSCRIBE /upnp/event/renderer_dvc/AVTransport HTTP/1.1\r\n
Request Method: SUBSCRIBE
Request URI: /upnp/event/renderer_dvc/AVTransport
Request Version: HTTP/1.1
HOST: 10.1.1.142:60006\r\n
USER-AGENT: Windows/10.0 UPnP/1.1 ohNet/1.0 TuneBrowser/1.0\r\n
SID: uuid:cff1b202-e395-1370-b3aa-80e94ad851a3
TIMEOUT: Second-360\r\n
Content-Length: 0\r\n
[Content length: 0]
\r\n

    According to the specification:

    A renewal must not include CALLBACK or NT.
    If SID is missing, the device treats the request as a new subscription, issues a new SID, and keeps the old one active until its timeout.

    (UPnP DA 1.0: “If the SID header is not included, the publisher SHALL treat the request as a new subscription.”)

    Most DMRs overwrite or auto-clean expired SIDs, so multiple subscriptions are not harmful.
    However, certain strict implementations keep each SID active until timeout, so repeated “new SUBSCRIBE instead of renewal” can temporarily accumulate multiple active subscriptions.

    By implementing SID-based renewal, TuneBrowser will achieve the highest level of compatibility and long-term stability across all types of hardware DMRs.

     

    Thank you again for your continued development and improvements to TuneBrowser.

    2026-01-17 21:40 #17317
    Tiki
    キーマスター

    Oh, here ?

    4.1.3 Renewing a subscription with SUBSCRIBE with SID

    Thank you. I’d like to try to understand.

    2026-01-17 21:44 #17318
    storaid
    参加者

    Correct!

    UDA 2.0

    https://openconnectivity.org/upnp-specs/UPnP-arch-DeviceArchitecture-v2.0-20200417.pdf

    Page 89, 4.1.1 Subscription

    Page 91, 4.1.2 SUBSCRIBE with NT and CALLBACK

    Page 94, 4.1.3 Renewing a subscription with SUBSCRIBE with SID

    Thank you

    2026-01-28 11:40 #17347
    storaid
    参加者

    Hello, Tiki,

    I hope you are doing well. I would like to share an interesting technical observation regarding the interaction between TuneBrowser and the iFi Audio ZEN Stream.

    After using the ZEN Stream as a UPnP Renderer for a while, I have occasionally encountered a situation where its internal UPnP stack (such as libupnp/upnpdcli) crashes, which makes re-initialization impossible without a hard reboot of the device.

    Based on my analysis using Wireshark, I suspect this might be related to a potential memory leak, possibly caused by a large number of redundant SUBSCRIBE operations.

    I am considering SSHing into the ZEN Stream’s Linux to further monitor the process behavior, but I wanted to share these findings with you first.

    Thank you very much for your excellent work on TuneBrowser!

    2026-01-28 12:14 #17348
    storaid
    参加者

    Interesting!

    For WiiM, How It Works!

    https://community.home-assistant.io/t/wiim-linkplay-integration-beta-release/905150/15

    2026-01-28 20:03 #17355
    Tiki
    キーマスター

    Hello.

    Now TuneBrowser renews subscription instead of re-subscribing when they are nearing expiration in 1821.

    Please try it when you have time.

    2026-02-02 20:37 #17405
    storaid
    参加者

    Hello, Tiki

    Still I can not change default value of SUBSCRIBE timeout advance (sec).

    It always keep 30 sec.

    Could you help me confirm to that?

    Thanks

  • 投稿者
    投稿
31件の投稿を表示中 - 1 - 31件目 (全31件中)
  • このトピックに返信するにはログインが必要です。