Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[AndrewFG]

Below is a capture from what MC sends in SetAVTransportURI. In it there is an xml attribute bitRate="176400" -- this is a bug in MC since the attribute name is supposed to be bitrate -- without the camel casing...

Code: [Select]

 <?xml version="1.0" encoding="UTF-8" ?><s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <s:Body>
  <u:SetAVTransportURI xmlns:u="urn:schemas-upnp-org:service:AVTransport:1">
  <InstanceID>0</InstanceID>
  <CurrentURI>http://192.168.0.103:52100/Music/F2078749.flac</CurrentURI>
  <CurrentURIMetaData>&lt;DIDL-Lite xmlns="urn:schemas-upnp-org:metadata-1-0/DIDL-Lite/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:upnp="urn:schemas-upnp-org:metadata-1-0/upnp/" xmlns:dlna="urn:schemas-dlna-org:device-1-0" xmlns:av="urn:schemas-sony-com:av" xmlns:pv="http://www.pv.com/pvns/"&gt;
  &lt;item id="F2078749" parentID="0" restricted="1"&gt;
  &lt;dc:title&gt;Get It On&lt;/dc:title&gt;
  &lt;upnp:class&gt;object.item.audioItem.musicTrack&lt;/upnp:class&gt;
  &lt;upnp:artist&gt;Grinderman&lt;/upnp:artist&gt;
  &lt;upnp:artist role="Performer"&gt;Grinderman&lt;/upnp:artist&gt;
  &lt;upnp:artist role="AlbumArtist"&gt;Grinderman&lt;/upnp:artist&gt;
  &lt;dc:creator&gt;Grinderman&lt;/dc:creator&gt;
  &lt;upnp:album&gt;Grinderman&lt;/upnp:album&gt;
  &lt;upnp:genre&gt;Popular&lt;/upnp:genre&gt;
  &lt;upnp:originalTrackNumber&gt;1&lt;/upnp:originalTrackNumber&gt;
  &lt;duration&gt;0:03:07.000&lt;/duration&gt;
  &lt;size&gt;23271070&lt;/size&gt;
  &lt;dc:date/&gt;
  &lt;pv:lastPlayedTime/&gt;
  &lt;pv:addedTime&gt;1325001459&lt;/pv:addedTime&gt;
  &lt;pv:modificationTime&gt;1234569393&lt;/pv:modificationTime&gt;
  &lt;upnp:albumArtURI dlna:profileID="JPEG_TN"&gt;http://192.168.0.103:52100/AArt/2078749.jpg&lt;/upnp:albumArtURI&gt;
  &lt;res protocolInfo="http-get:*:audio/flac:DLNA.ORG_PN=FLAC;DLNA.ORG_OP=01;DLNA.ORG_CI=0;DLNA.ORG_FLAGS=21700000000000000000000000000000" duration="0:03:07.000" size="23271070" nrAudioChannels="2" sampleFrequency="44100" bitsPerSample="16" bitRate="176400"&gt;http://192.168.0.103:52100/Music/F2078749.flac&lt;/res&gt;
  &lt;res protocolInfo="http-get:*:image/jpeg:DLNA.ORG_PN=JPEG_TN;DLNA.ORG_OP=00;DLNA.ORG_CI=1"&gt;http://192.168.0.103:52100/AArt/2078749.jpg&lt;/res&gt;
  &lt;/item&gt;
  &lt;/DIDL-Lite&gt;
  </CurrentURIMetaData>
  </u:SetAVTransportURI>
  </s:Body>
  </s:Envelope>

[MrC]

Offtopic from this bug, but relevant to JRiver and AndrewFG/Whitebear...

I see MC routinely dropping off a Squeezebox player from the Playing Now zone list.  It's a wired SB, so it's not like the wireless association goes south.

Either of you know about this issue, and can it be resolved?

[AndrewFG]

Offtopic from this bug, but relevant to JRiver and AndrewFG/Whitebear...

I see MC routinely dropping off a Squeezebox player from the Playing Now zone list.  It's a wired SB, so it's not like the wireless association goes south.

Either of you know about this issue, and can it be resolved?

There are in fact two problems:

1) MC is very slow picking up new UPnP devices. It seems to have a polling cycle whereby it asks UPnP devices to respond, but it seems to only pick up one new device (library or player) per polling cycle. Thus, even though all UPnP devices respond to the first inquiry, it may take MC a rather long time before it has picked up all devices. This is a bug in MC that needs to be fixed by JRiver at some point.

2) Whitebear (library and players) advertise themselves on the LAN and regularly renew their advertisements. So if MC sees the renewal, it knows it need not go through step 1 to poll for devices. However, the current release build of Whitebear only sends its renewals on the LAN IP adress, and not on the local loop-back address (127.0.0.1). So if MC is running on the same PC where Whitebear is running, it will not see the renewals, and so is forced to go through step 1 to poll for devices. I have a new release of Whitebear currently in testing, in which renewals are sent both on the LAN IP address and on the local loop-back address.

[MrC]

Got it.  I fall into Case #2.  I'll await any update you're ready to share.

[bob]

Below is a capture from what MC sends in SetAVTransportURI. In it there is an xml attribute bitRate="176400" -- this is a bug in MC since the attribute name is supposed to be bitrate -- without the camel casing...

Taken care of, thanks.

[bob]

1) MC is very slow picking up new UPnP devices. It seems to have a polling cycle whereby it asks UPnP devices to respond, but it seems to only pick up one new device (library or player) per polling cycle. Thus, even though all UPnP devices respond to the first inquiry, it may take MC a rather long time before it has picked up all devices. This is a bug in MC that needs to be fixed by JRiver at some point.

I can't seem to duplicate this. We are running all sorts of DLNA stuff here, lot's of chatter. Things seem to come and go pretty much the instant they are turned on or off. Can you give a test scenario?

[MrC]

I have 3 SB players as zones, presented via Whitebear.  Every 5 minutes or so (i haven't time exact intervals), the zones list is refreshed, and one player may randomly but routinely drop off.  If there is logging you need, or access to the system, perhaps we can arrange that.  I don't know how to force duplication though.

[bob]

I have 3 SB players as zones, presented via Whitebear.  Every 5 minutes or so (i haven't time exact intervals), the zones list is refreshed, and one player may randomly but routinely drop off.  If there is logging you need, or access to the system, perhaps we can arrange that.  I don't know how to force duplication though.

I think that is more likely to be Andrew's number 2 scenario. Can you give the next beta a try though and see if it makes any difference??

[MrC]

I think it is too.  I'll monitor this on the next beta.

[MrC]

So it looks like the change in 17.0.72 is a little too aggressive.

I quite Whitebear about 40 minutes ago, and it took about 5 minutes for the Whitebear presented library to disappear.  Along with it, one SB zone was removed, but still 2 SB zones remain even now.

[bob]

So it looks like the change in 17.0.72 is a little too aggressive.

I quite Whitebear about 40 minutes ago, and it took about 5 minutes for the Whitebear presented library to disappear.  Along with it, one SB zone was removed, but still 2 SB zones remain even now.

Actually, there was a second change not related to the finding of the zones that probably describes what you are seeing.
How about it finding them, did that work any better??

[MrC]

MC found 1 of 3 within a couple of seconds after starting Whitebear.  But not the Whitebear library.

About 5-7 minutes later, it found the other two and the library.

[bob]

MC found 1 of 3 within a couple of seconds after starting Whitebear.  But not the Whitebear library.

About 5-7 minutes later, it found the other two and the library.

You are running both WhiteBear and MC on the same machine, right? I think there may be some interference on port 1900 as well as the lack of localhost support in WB.

[MrC]

Yes, it is running on the same machine.

What software do you believe would be "interfering" on 1900?  I don't believe I have Windows Media Server running.

[bob]

Yes, it is running on the same machine.

What software do you believe would be "interfering" on 1900?  I don't believe I have Windows Media Server running.

Both Whitebear and MC are using UDP 1900 for SSDP, sending and listening. The change that effects how quickly servers are picked up involved slowing down our SSDP broadcasts. I think there may be receiver collisions on that port. UDP is not guaranteed delivery like TCP. Also, it seems that there may be broken ethernet chipset/drivers involved as well.  Still trying to work through the different angles...

[AndrewFG]

I think there may be receiver collisions on that port. UDP is not guaranteed delivery like TCP.

Yeah. If you read the UPnP Architecture documents, it takes pains to stress that a) devices shall not send advertisements too fast, b) that they shall spread out multiple advertisements and discovery requests, c) that they shall repeat discovery requests, and d) that all delays shall be randomised within the overall time out window.

PS in my experience MC is the only client that is so slow to discover Whitebear; all other CPs find the 'bear within seconds

Edit: following text added...

I have been doing some deeper digging: When MC 17 starts up, it unicasts three M-SEARCH requests, each separated by a 3 seconds delay, asking for UPnP root devices. Whitebear sees all three of these requests, and in all cases responds with four unicast responses spread within the MX response window. (It is four responses because in my case Whitebear if offerring one library plus three Squeeze players). So in total Whitebear sends 12 unicast responses within a total of 9 seconds. However, MC does not show any devices in its UI until much later. (See next paragraph).

In the test run that I did, Whitebear sent a series of SSDP Alive messages about seven minutes after MC had started. (There is no link between M-SEARCH request handling and Alive notifications, so this delay is simply a chance statistic). And only then, after it receives the Alive notifications, does MC actually show the Whitebear devices in its UI.

So it seems that MC is failing to discover Whitebear actively via its own (MC's) M-SEARCH discovery process. But it is discovering Whitebear passively via Whitebear's Alive notification process. The good news is that UPnP has two parallel and independent discovery mechanisms; and in the case of MC / Whitebear one of them is working; but the other one seems not to be...

[AndrewFG]

I'll await any update you're ready to share.

I sent a PM each to bob and Mr C with a link where they can get the update pre- release from.

[MrC]

Got it, and am testing.  I've sent you a response.

Zones appear immediately in MC upon starting Whitebear.  Cover art now works in streaming FLAC from MC to local SBS.  Nice.

[AndrewFG]

Got it, and am testing.  I've sent you a response.

Zones appear immediately in MC upon starting Whitebear.  Cover art now works in streaming FLAC from MC to local SBS.  Nice.

Its good to have confirmation that the Play To has improved. However I found a bug in that pre-release version concerning Play From Whitebear. However, in the meantime I posted a newer pre- release version under the same link I sent you before to solve this...

[MrC]

I'm pulling the same release version (2331), and the files binary compare.  I downloaded using two different methods, so it's not a caching issue.  Is this the correct version?

[AndrewFG]

I'm pulling the same release version (2331)... Is this the correct version?

Yes 2331 is the right one...

[bob]

Testing 2331, I'm not having success seeking. I'm pushing an mp3 to WhiteBear and it plays on the SB radio but if I try to seek it won't start playing again and I just get the looping 5 second counter to the time I seeked to in MC. If I look at what's going on with wireshark, I see GetTransportInfo calls in which WhiteBear is returning "PLAYING" but it's not.

Unfortunately it's not a single variable test since LMS updated at the same time I put in the new WhiteBear version.

[AndrewFG]

Testing 2331, I'm not having success seeking. I'm pushing an mp3 to WhiteBear and it plays on the SB radio but if I try to seek it won't start playing again and I just get the looping 5 second counter to the time I seeked to in MC. If I look at what's going on with wireshark, I see GetTransportInfo calls in which WhiteBear is returning "PLAYING" but it's not.

I am seeing this seek problem too with flacs. I don't yet know what the problem is, (but I am pretty sure it is an aspect of LMS rather than of Whitebear)...

Edit: by the way, the jumpy progress bar is a bit of an MC speciality artifact: The CP is supposed to call the renderer's GetPositionInfo regularly to determine the progress bar position. However, a CP should not call it too often because of the traffic load. It looks like MC therefore updates its progress bar based on "dead reckoning", and every now and then it calls GetPositionInfo to recalibrate the dead reckoning position. This is why the progress bar sometimes jumps a second or so backwards or forwards.

[bob]

I am seeing this seek problem too with flacs. I don't yet know what the problem is, (but I am pretty sure it is an aspect of LMS rather than of Whitebear)...

Edit: by the way, the jumpy progress bar is a bit of an MC speciality artifact: The CP is supposed to call the renderer's GetPositionInfo regularly to determine the progress bar position. However, a CP should not call it too often because of the traffic load. It looks like MC therefore updates its progress bar based on "dead reckoning", and every now and then it calls GetPositionInfo to recalibrate the dead reckoning position. This is why the progress bar sometimes jumps a second or so backwards or forwards.

Yes, that's what we do, ask every 5 seconds and reset the position based on the answer incrementing the position ourselves between GetPositionInfo calls.

[AndrewFG]

Hi bob,

Sorry but I discovered another bug in MC...

When a renderer does an HTTP GET on MC for a valid music track, and when the GET includes a RANGE header with a valid syntax ("Range: bytes=123456-") but where the requested start point "123456" is greater than the actual size of the track, then MC wrongly returns an HTTP  206 Partial Content code, although it obviously cannot return any data. It should instead return an HTTP Error 416 Requested Range not satisfiable code.

I found this while debugging the pause/play and seek problems between MC, Whitebear and SBS. It does not explain the actual pause/play and seek problems -- which are definitely on my side. However it does explain why the Squeeze player sits thinking it is playing a track without any actual music coming out and GetPositionInfo not moving: the player has received such a 206 code, and it just remains sitting on the socket waiting for some data that never comes from MC. If MC would correctly return a 4xx code in such a case, then at least the player can detect that something failed, and update its status accordingly...

Edit: I also discovered out that MC is ultimately to blame for the renderer sending RANGE requests having a byte offset larger than the file size. The CP sends a seek request with a time offset, and Whitebear multiplies the time by the bit rate to convert that to a byte Range offset. And the bit rate that Whitebear uses for this conversion is the one that MC supplies in SetAVTransportURI in the "bitrate" (resp. "bitRate") argument of the <res> element in the current track meta data. In case of an mp3 file, MC is giving a bitRate of 176400 which is consistent with a full lossless pcm stream 44100hz / 16bit / 2 channel; but in fact the actual bit rate that MC should give for this mp3 is far lower than that...

Of course I can work around the latter problem by using the time offset, the duration and the content length, rather than the time offset and the bit rate. But anyway you should fix both these issues in MC.

[bob]

Hi bob,

Sorry but I discovered another bug in MC...

When a renderer does an HTTP GET on MC for a valid music track, and when the GET includes a RANGE header with a valid syntax ("Range: bytes=123456-") but where the requested start point "123456" is greater than the actual size of the track, then MC wrongly returns an HTTP  206 Partial Content code, although it obviously cannot return any data. It should instead return an HTTP Error 416 Requested Range not satisfiable code.

I found this while debugging the pause/play and seek problems between MC, Whitebear and SBS. It does not explain the actual pause/play and seek problems -- which are definitely on my side. However it does explain why the Squeeze player sits thinking it is playing a track without any actual music coming out and GetPositionInfo not moving: the player has received such a 206 code, and it just remains sitting on the socket waiting for some data that never comes from MC. If MC would correctly return a 4xx code in such a case, then at least the player can detect that something failed, and update its status accordingly...

Are we pushing an mp3 here? I want to make sure it's MC's not trying to transcode. When we do that to mp3 (which is the default in the generic dlna template for non-mp3 files) we generate the mp3 on the fly but tell the renderer it's a a regular file, not being transcoded, so I was thinking perhaps the file isn't done transcoding yet and that's why we produce a 206. I'll definitely check the static case though... It's easy enough to test with curl.

Edit: I also discovered out that MC is ultimately to blame for the renderer sending RANGE requests having a byte offset larger than the file size. The CP sends a seek request with a time offset, and Whitebear multiplies the time by the bit rate to convert that to a byte Range offset. And the bit rate that Whitebear uses for this conversion is the one that MC supplies in SetAVTransportURI in the "bitrate" (resp. "bitRate") argument of the <res> element in the current track meta data. In case of an mp3 file, MC is giving a bitRate of 176400 which is consistent with a full lossless pcm stream 44100hz / 16bit / 2 channel; but in fact the actual bit rate that MC should give for this mp3 is far lower than that...

Ugh, maybe that's why it worked when the bitRate was not properly cased. I might just ditch the bitrate. I'm not convinced anything uses it. Do you use it?

[AndrewFG]

Are we pushing an mp3 here?

Yes. You are pushing an already existing native mp3. Nothing is being transcoded. (I actually did not check the other case where another format is being transcoded to mp3).

I might just ditch the bitrate. I'm not convinced anything uses it. Do you use it?

Actually yes I do use it. Whitebear / SBS needs this to convert a time offset to a byte offset when doing seeks. The other way to do this is to use size and duration (see below). As you can see, the three parameters size, bitrate, duration, form three sides of a triangle, and having any two of them will always allow one to calculate the third.

Code: [Select]

byte_offset := time_offset * bitrate, or
byte_offset := size * time_offset / duration

In my experience different CPs give different mixes of the three parameters size, bitrate, duration, and probably different clients look for different mixes too. So I think that you ought give all three in order to cover all bases.

[bob]

Thanks for the info, these are both fixed in the next build >=17.0.76

[AndrewFG]

I posted some PMs to people involved in this thread, with a link where you can get the next pre-release version of Whitebear that should fix the various issues raised.

[bob]

I posted some PMs to people involved in this thread, with a link where you can get the next pre-release version of Whitebear that should fix the various issues raised.

Hi Andrew, it seems to work fine for me (seeking, etc).

I've been playing a bit with the SetNextAVTransportURI function and am getting some success with WhiteBear however, I'd like to use AVTransport:GetMediaInfo to determine if the NextURI is empty however it seems broken in WhiteBear. Right now, it increments NrTracks properly from tracks 0 to tracks 1 to tracks 2 when going from stopped to SetAVTransportURI to SetNextAVTransportURI however when the track set by SetAVTransportURI stops playing it doesn't reflect the change (it stays at what it was before the track stopped playing). Also when the second track is finished, AVTransport:GetMediaInfo still stays at NrTracks = 2 and the original track URI's are still in CurrentURI and NextURI.

Also, a side issue, the CurrentURIMetadata and NextURIMetadata are both blank.

I think if you can clear up the AVTransport:GetMediaInfo issues we can get SetNextAVTransportURI working with WhiteBear.

[AndrewFG]

I've been playing a bit with the SetNextAVTransportURI function and am getting some success with WhiteBear however, I'd like to use AVTransport:GetMediaInfo to determine if the NextURI is empty however it seems broken in WhiteBear. Right now, it increments NrTracks properly from tracks 0 to tracks 1 to tracks 2 when going from stopped to SetAVTransportURI to SetNextAVTransportURI however when the track set by SetAVTransportURI stops playing it doesn't reflect the change (it stays at what it was before the track stopped playing). Also when the second track is finished, AVTransport:GetMediaInfo still stays at NrTracks = 2 and the original track URI's are still in CurrentURI and NextURI.

Also, a side issue, the CurrentURIMetadata and NextURIMetadata are both blank.

I think if you can clear up the AVTransport:GetMediaInfo issues we can get SetNextAVTransportURI working with WhiteBear.

Coool...

In the pre-release that you have, I already did some work on AVTransport:GetPositionInfo(), so for example AVTransportURI and AVTransportURIMetaData are properly updated. Also I tweaked the eventing so that LastChange:CurrentTrackURI and LastChange:CurrentTrackMetaData are updated. But you are quite right in observing that I did not touch AVTransport:GetMediaInfo yet :-(  so I will get onto this right away, and post you a new build when it is ready. But it may be in about one week's time though...

Edit: your mention of NrTracks (and by analogy CurrentTrackNo) started me thinking about what the correct algorithms should really be here. As I read the specifications there should never be more than two entries in the playlist -- namely "current" and "next". And pointedly the specification makes no mention of "prior". So I think the behaviour should be as follows:

1) SetAVTransportURI: it shall clear any existing entries in the playlist; it shall add the respective URI as entry #1 in the new playlist; and if the player was already playing, it shall start to play this track.

2) SetNextAVTransportURI: if there is already an entry #1 in the playlist it shall add the respective URI as entry #2 in the playlist; if there was already an entry #2 (or higher) in the playlist then all such extra entries shall be deleted; if there is NOT an entry #1 in the playlist it shall behave the same as SetAVTransportURI above...

3) If the player is playing entry #1 and reaches the end of the track: if there is an entry #2 in the playlist, the player shall start playing this track; entry #1 shall be deleted from the front of the playlist; and consequently the now playing track becomes entry #1

If the behaviour is as mentioned above, then GetMediaInfo.NrTracks can only ever return the values 0, 1 or 2. And GetMediaInfo.CurrentTrackNo can only ever return the value 1.

=> Is this how you see it too?

Edit 2: but then again, it occurs to me that in the case of Squeeze players there may be other actors (UIs) who are in parallel pushing tracks to the playlist. So probably after all, it is better to consider the UPnP/DLNA "current" plus "next" playlist as a two track window that may slide over a larger playlist that had possibly been set by another actor. My head is starting to spin...

[MrC]

Darn... I see the SB zones disappearing.  One of my wired SBs was just removed from the DLNA zone list.

[bob]

Coool...

In the pre-release that you have, I already did some work on AVTransport:GetPositionInfo(), so for example AVTransportURI and AVTransportURIMetaData are properly updated. Also I tweaked the eventing so that LastChange:CurrentTrackURI and LastChange:CurrentTrackMetaData are updated. But you are quite right in observing that I did not touch AVTransport:GetMediaInfo yet :-(  so I will get onto this right away, and post you a new build when it is ready. But it may be in about one week's time though...

Edit: your mention of NrTracks (and by analogy CurrentTrackNo) started me thinking about what the correct algorithms should really be here. As I read the specifications there should never be more than two entries in the playlist -- namely "current" and "next". And pointedly the specification makes no mention of "prior". So I think the behaviour should be as follows:

1) SetAVTransportURI: it shall clear any existing entries in the playlist; it shall add the respective URI as entry #1 in the new playlist; and if the player was already playing, it shall start to play this track.

2) SetNextAVTransportURI: if there is already an entry #1 in the playlist it shall add the respective URI as entry #2 in the playlist; if there was already an entry #2 (or higher) in the playlist then all such extra entries shall be deleted; if there is NOT an entry #1 in the playlist it shall behave the same as SetAVTransportURI above...

3) If the player is playing entry #1 and reaches the end of the track: if there is an entry #2 in the playlist, the player shall start playing this track; entry #1 shall be deleted from the front of the playlist; and consequently the now playing track becomes entry #1

If the behaviour is as mentioned above, then GetMediaInfo.NrTracks can only ever return the values 0, 1 or 2. And GetMediaInfo.CurrentTrackNo can only ever return the value 1.

=> Is this how you see it too?

I think that's pretty much the way we implement it as a renderer. I was only going to use SetNextAVTransportURI if there was one track in nrTracks or an empty NextURI field (GetMediaInfo).
Since we are already polling to update the position anyway and since implementing SetNextAVTransportURI bypasses the end of track/stop/play logic entirely, we will have to do GetMediaInfo to update the display.

Edit 2: but then again, it occurs to me that in the case of Squeeze players there may be other actors (UIs) who are in parallel pushing tracks to the playlist. So probably after all, it is better to consider the UPnP/DLNA "current" plus "next" playlist as a two track window that may slide over a larger playlist that had possibly been set by another actor. My head is starting to spin...

I'm not sure how much of this "other actor" stuff we can deal with. DLNA doesn't seem very well though out to handle multiple controllers..

[bob]

Darn... I see the SB zones disappearing.  One of my wired SBs was just removed from the DLNA zone list.

I just noticed that too. I thought my second machine on which WB was running was sleeping but it seems not to be the case.

[MrC]

Good to hear you can reproduce; let me know if there's anything else you need on my end.

[bob]

Good to hear you can reproduce; let me know if there's anything else you need on my end.

It disappears from Device Spy too so I think it's something with WB...

[AndrewFG]

It disappears from Device Spy too so I think it's something with WB...

Can you please give some more context here? After how much time does it go away? Does it come back again? After how long? Do all players go away? At the same time? Or just one? Does the library by Whitebear go away too? etc.

[bob]

MrC probably has more info than I do on it however this is my setup:
MC on a PC, Whitebear and the Squeeze server on another PC. A squeezebox radio (the only squeeze device I have) is connected to the same LAN.
The Squeezebox Radio (by Whitebear) disappears from my MC PC. Checking on the Whitebear PC, everything is still running fine there.
I waited 10 minutes or so and it didn't come back. I THINK but am not sure, that the Server (by Whitebear) was missing as well. I then checked in Device Spy and at least the renderer was still missing. I rescanned a couple of times in Device Spy and the Whitebear renderer still didn't come back. Went to the Whitebear PC, status of Whitebear was good. Stopped and Restarted Whitebear and the Squeezebox Radio (by Whitebear) showed back up on my MC PC.

[MrC]

I see that typically one of the Whitebear SBs goes missing in MC.  I usually don't have Playing from ... expanded so have not noticed in the past if the Whitebear library went missing.

But it just happened as your post suggested I should expand that portion of the MC Playing Now tree.

I had debug enabled in Whitebear while it happened.  Is the log useful to you?  I copied it while the Whitebear library was missing.

I haven't noticed any pattern of time before either a zone or library goes missing.  It always returns after some indeterminate amount of time.  I think I've only seen one "something" go away, never more.  I'm awaiting the library to return, and will copy the log again then, just in case.

[MrC]

After an hour, the WB library never returned, so I let MC update and restarted MC.

5 minutes after restart, only one SB was found and no WB library.

7 minutes after restart, all 4 WB provided items are present.

>1hr, 2 SBs, 1 Library are present.

So here's a case now where more than one WB item can be missing.

~2hrs, 2 SBs only, library missing.

A few minutes later, the library reappears.

[AndrewFG]

So basically it seems the disappearances are quite random...

This is surprising because when Whitebear advertises itself, and renews its advertisements, it sends the notificatio for the library and all players as a chained series of UDP messages altogether. What you are saying is that randomly some or other of these adverts are going astray. I suspect there may be UDP collisions, (or alternatively the IP stack is not flushing the adverts into individual packets).

You probably know that SBS itself uses a lot of UDP so perhaps it is itself guilty of causing the collisions. Do you have a lot of SBS playing traffic going on? Does it improve if you stop?

[bob]

I ran some wireshark traces this morning. I'm not seeing any DLNA M-SEARCH's from my machine with the WhiteBear server.
I AM seeing plenty of these from that PC:
M-SEARCH * HTTP/1.1
Host:239.255.255.250:1900
ST:urn:schemas-upnp-org:device:InternetGatewayDevice:1
Man:"ssdp:discover"
MX:3

M-SEARCH * HTTP/1.1
Host:239.255.255.250:1900
ST:urn:schemas-upnp-org:device:InternetGatewayDevice:1
Man:"ssdp:discover"
MX:3

However, the WhiteBear PC is not an internet gateway! This could be a red herring but I do have an internet gateway device on a different IP that does the same M-Search's

The previous version of WhiteBear used to show up instantly in device spy, this version takes many minutes.

About 3 minutes into my trace I saw WhiteBear send some Notifies, then it was picked up by device spy. The next set of Notifies from WhiteBear occured 430 seconds later, the next set, another 430 seconds. Looks like that's the timer for Notify.

After 10 minutes, I'm still not seeing any M-SEARCH's other that the Internet-Gateway ones.

[MrC]

So basically it seems the disappearances are quite random...

Yes, it is random.

You probably know that SBS itself uses a lot of UDP so perhaps it is itself guilty of causing the collisions. Do you have a lot of SBS playing traffic going on? Does it improve if you stop?

In general, the loss of WB items in MC seems unrelated to playback.  The screenshots were all take while there was no playback occurring - all units were in standby.  During these times, I've seen WB items come and go from MC within seconds.  The most annoying aspect of all this, is that it causes the MC tree to bounce up and down frequently while zones are added/removed, and it re-indexes the zone list (which are index-, and not name-based, a not-so-useful choice).

But the SBs wouldn't have an affect on the WB library gone MIA, right?  WB/MC/SBS are all on the same machine here.

To add another fly, and because bob needs some piece of this to work on  ,  when I shut down WB, MC retains some number of WB items indefinitely.

[AndrewFG]

The M-SEARCH 's that bob sees are not at all relevant, it means that somebody is looking for an Internet gateway; this is quite irrelevant to MC or Whitebear...

Mr C ' s traces indicate that the test build of Whitebear that you are working with could indeed be sick. It sounds like it might not be sending its initial Alive notifications, and perhaps also not its Bye-Bye notifications. However I think there could still be something else amiss in your setup because when Whitebear does send notifications it sends them for all devices (i.e. the library and all attached players) so if others are only seeing a subset of the devices that Whitebear announces, it means something else may be interfering with the packets...

[MrC]

Is there anything I can do on this end to assist?

[bob]

After observing some of the behavior here (Whitebear not going away when it's obviously not running), here is what we think is going on.

The M-SEARCH in Whitebear isn't happening.
We add the Whitebear devices though when we see the ssdp:alive NOTIFY (which Whitebear sends once every 430 seconds).
When Whitebear goes away, we don't see any ssdp:bye-bye.
We don't remove the devices because since they didn't reply to a M-SEARCH in the first place we can't use M-SEARCH to see if it's still there and since there is no bye-bye we've got no way to know if it's truly gone.

[AndrewFG]

No it is unfortunately not that simple. Whitebear IS definitely responding to MC's M-SEARCH requests. (You can check this by turning on Whitebear's ssdp logging...) However for some reason MC is not seeing those responses. Or at least not all of them. On the other hand, I believe you are correct that Whitebear is not sending his ByeByes when he goes offline. I shall do some more digging in the next few days...  

[bob]

No it is unfortunately not that simple. Whitebear IS definitely responding to MC's M-SEARCH requests. (You can check this by turning on Whitebear's ssdp logging...) However for some reason MC is not seeing those responses. Or at least not all of them. On the other hand, I believe you are correct that Whitebear is not sending his ByeByes when he goes offline. I shall do some more digging in the next few days...  

I'm tracing in wireshark and am not seeing the Whitebear M-SEARCH's.
Does it send them other than on startup?
As for the replies, I'll have to check again but I'm pretty sure I didn't see them in the trace either.

[bob]

BTW, my tracing setup is not likely to be a problem.

I've got MC on one PC, Whitebear and the Slimserver on another, and I'm tracing with both the MC PC and a third PC. They are all connected by a 100 meg HUB (not switch) so I see all of the packets on the third machine.

[AndrewFG]

Why are you expecting Whitebear to be SENDING M-SEARCH requests? Whitebear does not issue commands to other UPnP devices so it does not send M-SEARCH requests looking for such...
Whitebear expects to recieve commands from other devices, so it does send NOTIFY messages to inform such others of its presence, and it also does RESPOND to M-SEARCH'es when such others search for it.
You seem to be implying that MC "discovers" other devices by waiting until the other device tries to discover MC. This is totally backwards. Or??