SystemUpdateID event

[CraigD]

Does MinimServer send out SystemUpdateID notifications? When my application performs a "Browse" I can see that the UpdateID changes. MediaTomb (another UPnP server) sends out a notification when the UpdateID changes - this contains both SystemUpdateID and ContainerUpdateIDs. MinimServer's UpdateID does change - but I don't seem to get any notification that this has occurred. The only way around this seems to be to poll MinimServer by calling GetSystemUpdateID periodically - but I'd rather not do this.

To register for notifications, I'm sending a SUBSCRIBE request to http://minim:port/1bd3d9ee-6743-4412-9e71-07fa5c3b3199/upnp.org-ContentDirectory-1/event This request seems to be accepted - as I receive a valid response. However, I never seem to receive any notifications.

[simoncn]

(04-05-2016 22:28)CraigD Wrote:  Does MinimServer send out SystemUpdateID notifications? When my application performs a "Browse" I can see that the UpdateID changes. MediaTomb (another UPnP server) sends out a notification when the UpdateID changes - this contains both SystemUpdateID and ContainerUpdateIDs. MinimServer's UpdateID does change - but I don't seem to get any notification that this has occurred. The only way around this seems to be to poll MinimServer by calling GetSystemUpdateID periodically - but I'd rather not do this.

To register for notifications, I'm sending a SUBSCRIBE request to http://minim:port/1bd3d9ee-6743-4412-9e71-07fa5c3b3199/upnp.org-ContentDirectory-1/event This request seems to be accepted - as I receive a valid response. However, I never seem to receive any notifications.

MinimServer sends out a property change notification every time SystemUpdateID changes (as required by the UPnP ContentDirectory specification). It does not do this for ContainerUpdateIDs (optional in the UPnP ContentDirectory specification).

What is the exact SUBSCRIBE request you are sending when you register for notifications?

[CraigD]

There was a bug in my code - where I was not handling 'transfer-encoding: chunked', this is now fixed. The SUBSCRIBE message I send is

Code:

SUBSCRIBE /1bd3d9ee-6743-4412-9e71-07fa5c3b3199/upnp.org-ContentDirectory-1/event HTTP/1.1
CALLBACK: <http://192.168.0.8:42541/>
NT: upnp:event
TIMEOUT: Second-1800
Connection: close
Accept-Encoding: gzip, deflate
Accept-Language: en-GB,*
User-Agent: Mozilla/5.0
Host: 192.168.0.8:9791

MinimServer reponds with

Code:

HTTP/1.1 200 OK
SERVER: Posix/200809.0 UPnP/1.1 ohNet/1.0
SID: uuid:1bd3d9ee-6743-4412-9e71-07fa5c3b3199-4
TIMEOUT: Second-1800
Connection: close

I then immediately receive a notification:

Code:

NOTIFY / HTTP/1.1
Host: 192.168.0.8:9791
Content-Type: text/xml; charset="utf-8"
Nt: upnp:event
Nts: upnp:propchange
SID: uuid:1bd3d9ee-6743-4412-9e71-07fa5c3b3199-4
Transfer-Encoding: chunked
Seq: 0
Connection: close

<?xml version="1.0"?><e:propertyset xmlns:e="urn:schemas-upnp-org:event-1-0"><e:property><TransferIDs></TransferIDs></e:property><e:property><SystemUpdateID>52</SystemUpdateID></e:property><e:property><ContainerUpdateIDs></ContainerUpdateIDs></e:property></e:propertyset>

However, If I now create a new playlist then call 'rescan' in 'startc' - no notification is sent. Are notifications only sent on the initial subscribe?

There seems to be an issue with my code - where I'm not seeing the 'bybye' and 'alive' messages. (Maybe because I'm running on the same host). Is it expected that after a rescan minim will send a 'byebye', a client should disconnect (unsubscribe), minim restarts and sends an 'ssdp:alive', then the client re-subscribes - and gets the new UpdateID this way?

[simoncn]

(05-05-2016 21:33)CraigD Wrote:  However, If I now create a new playlist then call 'rescan' in 'startc' - no notification is sent. Are notifications only sent on the initial subscribe?

No, they are sent whenever the SystemUpdateID property changes and the subscription is still active.

Quote:There seems to be an issue with my code - where I'm not seeing the 'bybye' and 'alive' messages. (Maybe because I'm running on the same host). Is it expected that after a rescan minim will send a 'byebye', a client should disconnect (unsubscribe), minim restarts and sends an 'ssdp:alive', then the client re-subscribes - and gets the new UpdateID this way?

Your understanding is correct. The 'rescan' command causes the MediaServer device to be destroyed and recreated. When the device is destroyed, MinimServer sends a byebye notification and the subscription is terminated. The control point must establish a new subscription after the MediaServer device has been recreated and has sent an alive notification. When it does this, it will receive a notification containing the current value of SystemUpdateID.

This sequence of events should happen whether or not the control point is running on the same host as the server. However, if the control point and server are running on the same host, you will not be able to use Wireshark to see messages exchanged between the server and the control point. Instead, you can see these messages by setting the MinimServer property ohnet.debug to All-Timer and setting the MinimServer logging level to Debug. The messages can be seen by looking in the minimserver.log file (not the log window).

[CraigD]

The reason I never saw the byebye messages was due to a Qt bug (QTBUG-33419), which I have now worked around.

I now see the byebye/alive/notification sequence - and the listing is updated.

Is it possible to have minimserver update without it sending byebye/alive messages? When I use the HTML page and choose 'rescan' it still does the byebye, causing disconnect, alive, reconnect, etc. But this causes the UI to reset itself to the root of the minimserver listing.

For example, if I create a new playlist file how do I get minimserver to notice this and update itself. Is restarting minim, or using the 'rescan' button the only way? If so, then this is really the same to a control point - it sees minim as stopping and then starting again.

p.s. Wireshark can see the network traffic on the local machine - you just select 'lo' or all interfaces. This is how I knew the SSDP issue was in my code - as I could see minim correctly sending the messages.

[simoncn]

At present, it isn't possible for MinimServer to do a library rescan without also restarting the MediaServer device.

It is possible for a UPnP control point to preserve the last browsing state and restore it automatically after the device restart. You should do this by creating a "breadcrumb trail" of browsing selections and following this trail after the restart. You should not assume that container IDs will be the same following the restart.

Are you developing a UPnP control point? If so, can you share any information about this?

[CraigD]

My control point is still under heavy development - but if you are interested the code is at https://github.com/CDrummond/madrigal The CP is built using the Qt5 libraries - and should compile for Linux (which I use for development), Windows, and Mac (but I'm not regularly building for Windows or Mac, so can't guarantee it will always build)

I'll look into the idea of preserving the path - but this is not going to be 100% reliable, as tags could be changed, and the upnp IDs are not guaranteed to be unique. Not sure its worth the hassle - as I doubt the DB changes often.