INTERACT FORUM
Networks and Remotes => Media Network => Topic started by: AndrewFG on January 18, 2012, 04:45:33 pm
-
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...
<?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><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/">
<item id="F2078749" parentID="0" restricted="1">
<dc:title>Get It On</dc:title>
<upnp:class>object.item.audioItem.musicTrack</upnp:class>
<upnp:artist>Grinderman</upnp:artist>
<upnp:artist role="Performer">Grinderman</upnp:artist>
<upnp:artist role="AlbumArtist">Grinderman</upnp:artist>
<dc:creator>Grinderman</dc:creator>
<upnp:album>Grinderman</upnp:album>
<upnp:genre>Popular</upnp:genre>
<upnp:originalTrackNumber>1</upnp:originalTrackNumber>
<duration>0:03:07.000</duration>
<size>23271070</size>
<dc:date/>
<pv:lastPlayedTime/>
<pv:addedTime>1325001459</pv:addedTime>
<pv:modificationTime>1234569393</pv:modificationTime>
<upnp:albumArtURI dlna:profileID="JPEG_TN">http://192.168.0.103:52100/AArt/2078749.jpg</upnp:albumArtURI>
<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">http://192.168.0.103:52100/Music/F2078749.flac</res>
<res protocolInfo="http-get:*:image/jpeg:DLNA.ORG_PN=JPEG_TN;DLNA.ORG_OP=00;DLNA.ORG_CI=1">http://192.168.0.103:52100/AArt/2078749.jpg</res>
</item>
</DIDL-Lite>
</CurrentURIMetaData>
</u:SetAVTransportURI>
</s:Body>
</s:Envelope>
-
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?
-
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.
-
Got it. I fall into Case #2. I'll await any update you're ready to share.
-
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.
-
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?
-
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 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??
-
I think it is too. I'll monitor this on the next beta.
-
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.
-
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??
-
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.
-
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.
-
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.
-
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...
-
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...
-
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.
-
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.
-
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...
-
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?
-
I'm pulling the same release version (2331)... Is this the correct version?
Yes 2331 is the right one...
-
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.
-
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.
-
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.
-
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.
-
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?
-
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.
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.
-
Thanks for the info, these are both fixed in the next build >=17.0.76
-
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.
-
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.
-
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...
-
Darn... I see the SB zones disappearing. One of my wired SBs was just removed from the DLNA zone list.
-
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..
-
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.
-
Good to hear you can reproduce; let me know if there's anything else you need on my end.
-
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...
-
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.
-
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.
-
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.
-
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.
-
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?
-
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.
-
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 ;D, when I shut down WB, MC retains some number of WB items indefinitely.
-
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...
-
Is there anything I can do on this end to assist?
-
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.
-
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...
-
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.
-
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.
-
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??
-
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??
Sorry my mistake on the initiation of the M-SEARCH. I can see renderers like the Sony TV preforming M-SEARCH's but that's because they are players also and are looking for servers. I see since Whitebear only uses the proprietary SlimServer it doesn't have to do searches.
However, as far as I can tell, it's not replying to my M-SEARCH's. With my PC running and MC not running connected to the PC with Whitebear (status OK). Startup Intel Device Spy on my computer, in Wireshark I see all sorts of devices responding to the M-SEARCH from Device Spy but not Whitebear.
Eventually Whitebear does showup in Device Spy when the Notify timer in Whitebear fires on it's 430 second interval.
-
Ok. At least we are now on the same song sheet. I will look into this issue and report back...
Edit:
I discovered that under apparently random circumstances, Whitebear was sometimes listening for M-SEARCH'es on, and replying to 127.0.0.1, instead of listening on and replying to the actual NIC IP. That explains why I could always see the reponses on LocalHost, but why WireShark and other PCs were not seeing anything. This will be fixed in the next build.
By the way, perhaps it is worth mentioning that the order of Whitebear's responses can differ from the order in which MC sends its M-SEARCH requests; this is because the M-SEARCH MX header defines a MaX time window within which the replier shall respond; Whitebear chooses a random number within the MX window, and so if two requests have an MX that overlaps, it is possible that the later request gets a response before the earlier one...
I can also confirm that Whitebear was indeed not sending its ByeBye messages. This will also be fixed in the next build.
-
Ok. At least we are now on the same song sheet. I will look into this issue and report back...
Edit:
I discovered that under apparently random circumstances, Whitebear was sometimes listening for M-SEARCH'es on, and replying to 127.0.0.1, instead of listening on and replying to the actual NIC IP. That explains why I could always see the reponses on LocalHost, but why WireShark and other PCs were not seeing anything. This will be fixed in the next build.
By the way, perhaps it is worth mentioning that the order of Whitebear's responses can differ from the order in which MC sends its M-SEARCH requests; this is because the M-SEARCH MX header defines a MaX time window within which the replier shall respond; Whitebear chooses a random number within the MX window, and so if two requests have an MX that overlaps, it is possible that the later request gets a response before the earlier one...
I can also confirm that Whitebear was indeed not sending its ByeBye messages. This will also be fixed in the next build.
Great.. it will be interesting to try. Note that the last build of MC also includes SetNextAVTransportURI support in the controller. The logic is to set it as soon as GetMediaInfo indicates NextURI is empty. That works really well using our own renderer. It kinda of works with the Bravia TV however the TV waits until the first track is finished before requesting the next which still results in a small gap. (which is kind of weird as it does a head request on the next file as soon as it gets the NextURI). I've got no other devices that support SetNextAVTransportURI to test at this time...
-
Ok I am just doing some heavy rewriting og Whitebear's UDP socket stuff to fix the SSDP notification and search issues mentioned earlier. And so I will download your latest build and do some testing with SetNextAvTransportURI at the same time. (Which build of MC do I need to look ou for?) I will keep you posted on the results...
-
It's in builds >= 17.0.91
-
I created a new build of Whitebear and have sent a link by PM to MrC and bob where you guys can download it from.
In this build I have completely rewitten the UPnP Discovery and Notification code, so that it properly sends all the necessary alive and byebye notifications, and properly responds to M-SEARCH requests. It does now come and go perfectly in (e.g.) the Intel DeviceSpy tool.
Notwithstanding this, it seems that MC does still have issues in discovering Whitebear; it seems that in any given M-SEARCH round, MC will only add one Whitebear entity (be it the library or a player). I don't know why this is the case, from Whitebear's side everything seems to be in order, so I think it is an MC issue. Edit: MC sends one M-SEARCH each for MediaRenderers and MediaServers, and if Whitebear is supporting (say) two players, it sends three responses (one for the server and one for each player); however it seems that MC always only "gets" the first response -- be it for the server or a renderer whichever comes first. In e.g. Intel's UPnP DeviceSpy the Squeeze library and all Squeeze players (be they hardware or software ones) are discovered instantaneously, whereas MC discovers the first device in about 15 seconds, the second about 60 seconds later, and the rest about 30 seconds after that...
Also in this build I have extensively reworked the SetNextAVTransportURI functionality, and the corresponding return data from GetMediaInfo() and GetPositionInfo(). I have tested it with MC v17.0.91 and it does seem to work. However it seems that when MC calls SetNextAVTransportURI it closes the TCP connection upon receipt of HTTP 200 OK from Whitebear without actually reading the response SOAP content; this behaviour is different than what MC does with SetAVTransportURI so I think that there may still be some bugs on MCs side. Also it seems that the MC UI tends to freeze up when you call SetAVTransportURI and SetNextAVTransportURI in close succession. Edit: it seems also that when the track passed in SetAVTransportURI reaches the end, the track passed in SetNextAVTransportURI starts to play as you would expect, and in MC's now playing status panel the track length gets updated correctly, however the track title continues to show the title of the original SetAVTransportURI track...
Furthermore in this build I added a plugin for Squeezebox Server so that Whitebear can parse the metadata passed in CurrentURIMetadata and NextURIMetadata, and add it to Squeezebox Server's cache so that a Play To command from MC to a Squeezeplayer will result in artwork and track metadata being displayed on the player UI and also on the Logitech web based UI. This plugin in only works for SBS/LMS v7.0 upwards.
Last but not least, in this build I tweaked the Whitebear's preferred handling of various music formats for the Play To functionality, so that you get the best possible user experience regardless of whether MC is set to Always Convert L16 No Header, or Never Convert, etc. -- On balance, I think you get the best user experience with Always Convert, because in general PCM streams are always seekable by Whitebear respectively Squeezeplayers (the only downside is that it requires a bit more CPU on the side of MC and also a bit more on the side of Whitebear).
Edit: I did also discover another bug in MC: the MC SetAVTransportURI and SetNextAVTransportURI functions create a two entry playlist for the respective Squeeze player; but now if you use the player's own UI (or the Logitech web UI) to clear that playlist, it causes MC to immediately crash !! (I always get a certain secret delight from crashing an application via an HTTP transaction...)
-
...
Edit: I did also discover another bug in MC: the MC SetAVTransportURI and SetNextAVTransportURI functions create a two entry playlist for the respective Squeeze player; but now if you use the player's own UI (or the Logitech web UI) to clear that playlist, it causes MC to immediately crash !! (I always get a certain secret delight from crashing an application via an HTTP transaction...)
Checking into the others but I absolutely can't reproduce your crash, tried it on Windows 7 and XP, with MC and Whitebear on the same PC's and with them on separate PC's. If I whack the playlist in the Logitech server status window in a browser, it just goes onto the next song. I'm using MP3's without conversion so it's a simple playlist of static files. What are you using for testing?
-
Checking into the others but I absolutely can't reproduce your crash, tried it on Windows 7 and XP, with MC and Whitebear on the same PC's and with them on separate PC's. If I whack the playlist in the Logitech server status window in a browser, it just goes onto the next song. I'm using MP3's without conversion so it's a simple playlist of static files. What are you using for testing?
I was using flacs with Always Convert on. So perhaps the MC crash occurred in you transcoder when the Squeezeplayer resp. Whitebear terminated downloading the stream? However I have to say that I have tried to repeat, and was not able to do so, so perhaps it was a timing issue...
-
Also in this build I have extensively reworked the SetNextAVTransportURI functionality, and the corresponding return data from GetMediaInfo() and GetPositionInfo(). I have tested it with MC v17.0.91 and it does seem to work. However it seems that when MC calls SetNextAVTransportURI it closes the TCP connection upon receipt of HTTP 200 OK from Whitebear without actually reading the response SOAP content; this behaviour is different than what MC does with SetAVTransportURI so I think that there may still be some bugs on MCs side. Also it seems that the MC UI tends to freeze up when you call SetAVTransportURI and SetNextAVTransportURI in close succession. Edit: it seems also that when the track passed in SetAVTransportURI reaches the end, the track passed in SetNextAVTransportURI starts to play as you would expect, and in MC's now playing status panel the track length gets updated correctly, however the track title continues to show the title of the original SetAVTransportURI track...
We figured out what is happening here. When we call SetNextAVTransportURI Whitebear starts a GET on that file before replying to the SetNextAVTransportURI call and since we are zone locked for the SetNextAVTransportURI we can't reply to the file GET. The whole thing eventually times out (10 seconds) and reverts to the old method of track advancement (however Whitebear actually appears to use the SetNextAVTransportURI) so the second song in my playlist gets played twice. We are looking at changes to reduce the locking however you could make it work by completing the SetNextAVTransportURI response before doing the file GET.
-
I was using flacs with Always Convert on. So perhaps the MC crash occurred in you transcoder when the Squeezeplayer resp. Whitebear terminated downloading the stream? However I have to say that I have tried to repeat, and was not able to do so, so perhaps it was a timing issue...
Were you converting the flacs to mp3 or L16?
Are all of the pieces on one PC?
-
Furthermore in this build I added a plugin for Squeezebox Server so that Whitebear can parse the metadata passed in CurrentURIMetadata and NextURIMetadata, and add it to Squeezebox Server's cache so that a Play To command from MC to a Squeezeplayer will result in artwork and track metadata being displayed on the player UI and also on the Logitech web based UI. This plugin in only works for SBS/LMS v7.0 upwards.
This looks great!
-
We figured out what is happening here. When we call SetNextAVTransportURI Whitebear starts a GET on that file before replying to the SetNextAVTransportURI call and since we are zone locked for the SetNextAVTransportURI we can't reply to the file GET.
Yes Whitebear does indeed do a GET within its Set[Next]AVTransportURI call handler. It does this in order to 1) read the mime type header of the track being presented, and 2) (wherever appropriate) to read the riff header of aif and wav files. Whitebear needs this information in order to determine if it is able to play the track being offerred; if it can, the call returns success, and if not, it returns SOAP error "714 Illegal Mime Type". Once Whitebear has got this data it closes the socket. (Note: this behaviour is necessary, since not all Control Points will be offerring xxURIMetaData arguments along within their Set[Next]AVTransportURI calls).
The whole thing eventually times out (10 seconds) and reverts to the old method of track advancement (however Whitebear actually appears to use the SetNextAVTransportURI) so the second song in my playlist gets played twice.
I see. And yes, Whitebear does indeed use SetNextAVTransportURI... :-)
We are looking at changes to reduce the locking however you could make it work by completing the SetNextAVTransportURI response before doing the file GET.
As you can see from the above, I do need the mime type and the riff headers before I can determine what to return from Set[Next]AVTransportURI
-
Were you converting the flacs to mp3 or L16?
Are all of the pieces on one PC?
Always converting to L16 no header.
And yes, all the tracks were on the PC that MC was running on.
-
As you can see from the above, I do need the mime type and the riff headers before I can determine what to return from Set[Next]AVTransportURI
All of the information you need is in the NextURIMetadata so there isn't really a need to do the GET.
-
Always converting to L16 no header.
And yes, all the tracks were on the PC that MC was running on.
Ok, I'll check that. I did guess it was probably L16 conversion but I was still using 2 PC's for the "crash" test...
-
All of the information you need is in the NextURIMetadata so there isn't really a need to do the GET.
In the case of MC your statement is indeed true. However according to the specifications whilst the xxxURI is a "MUST" argument, the xxxURIMetaData is only a "MAY" argument, and furthermore its meta data may contain several <res> elements, and these elements have several "MAY" attributes. So I prefer to parse the xxxURIMetaData and the HTTP Content-Type and Content-Length headers and the riff header to be sure I am getting everything, and to be sure that I am getting the actual offered mime type rather than guessing which of the several possible <res> elements actually applies.
PS: however, notwithstanding the above, I will try a build later today which omits the GET if it feels it has enough information from other sources...
-
In the case of MC your statement is indeed true. However according to the specifications whilst the xxxURI is a "MUST" argument, the xxxURIMetaData is only a "MAY" argument, and furthermore its meta data may contain several <res> elements, and these elements have several "MAY" attributes. So I prefer to parse the xxxURIMetaData and the HTTP Content-Type and Content-Length headers and the riff header to be sure I am getting everything, and to be sure that I am getting the actual offered mime type rather than guessing which of the several possible <res> elements actually applies.
PS: however, notwithstanding the above, I will try a build later today which omits the GET if it feels it has enough information from other sources...
I see your point. In our case you get much more info in the xxURIMetaData but I have seen otherwise in other cases.
We also worked on this from the our side yesterday and it works with your method now however our change affects a lot of code so it might be a while a while before it makes it to release.
-
I see your point. In our case you get much more info in the xxURIMetaData but I have seen otherwise in other cases.
We also worked on this from the our side yesterday and it works with your method now however our change affects a lot of code so it might be a while a while before it makes it to release.
I appreciate your efforts. And I will look out for the new build.
In the meantime, I also made a new build of Whitebear that (so long as it already got sufficient information from the MetaData) does not any more do the GET within Set[Next]AVTransportURI.
I have posted a PM to bob where you can download it.
I did not do much heavy testing, but on first assessment it seems to work fine...
Edit: Notwithstanding the above statement, it is evident that MC still has issues with UPnP device discovery. In the Intel Device Spy, the Squeeze Library and Squeeze players all remain showing rock solid, whereas in MC they come and go like ping pong balls.
Edit: If you start MC first followed by Whitebear, then the server and devices all appear rather fast (that is because MC is seeing all of Whitebear's NOTIFY messages correctly). But my experience is that if you start Whitebear first followed by MC, then only one device or server will appear after about 15 seconds, and the remaining devices or server will only appear after a few minutes (that is because, although Whitebear is sending multiple responses to MC's M-SEARCH enquiry, unfortunately MC only seems to "hear" one such response for each of its M-SEARCH rounds).
Edit: And another niggle: if you use the Squeeze player's own UI to change to another track within the Squeeze play list, then MC does update its status to indicate the track length and position of the newly playing track, but sadly it does not update to reflect the title of the newly playing track. Now as you are polling GetPositionInfo for the position info you could also be looking to see if CurrentTrackURI has changed and thus update the track title display too; (and even, if the URI is not one of your own, you could parse CurrentTrackMetaData, thus allowing you to show Now Playing status of tracks being played from third party sources...)
-
I appreciate your efforts. And I will look out for the new build.
In the meantime, I also made a new build of Whitebear that (so long as it already got sufficient information from the MetaData) does not any more do the GET within Set[Next]AVTransportURI.
I have posted a PM to bob where you can download it.
I did not do much heavy testing, but on first assessment it seems to work fine...
Your test version does work for me and the changes on our side that I mentioned have made it into the beta build now.
Edit: Notwithstanding the above statement, it is evident that MC still has issues with UPnP device discovery. In the Intel Device Spy, the Squeeze Library and Squeeze players all remain showing rock solid, whereas in MC they come and go like ping pong balls.
Edit: If you start MC first followed by Whitebear, then the server and devices all appear rather fast (that is because MC is seeing all of Whitebear's NOTIFY messages correctly). But my experience is that if you start Whitebear first followed by MC, then only one device or server will appear after about 15 seconds, and the remaining devices or server will only appear after a few minutes (that is because, although Whitebear is sending multiple responses to MC's M-SEARCH enquiry, unfortunately MC only seems to "hear" one such response for each of its M-SEARCH rounds).
We update the display of servers and renderers every 10 seconds.
I'm setting up a separate network to try and duplicate what you are seeing. Since our dev network has a lot of DLNA chatter on it, it's hard to isolate this type of trouble. Also, it seems that we always see MC's advertisments, stuff is coming and going constantly. It's hard to see how we could miss the responses to M-SEARCH's specifically from Whitebear.
Since I have only one squeeze device the only way I can really test this is to see if the server and renderer don't both appear right away.
Edit: And another niggle: if you use the Squeeze player's own UI to change to another track within the Squeeze play list, then MC does update its status to indicate the track length and position of the newly playing track, but sadly it does not update to reflect the title of the newly playing track. Now as you are polling GetPositionInfo for the position info you could also be looking to see if CurrentTrackURI has changed and thus update the track title display too; (and even, if the URI is not one of your own, you could parse CurrentTrackMetaData, thus allowing you to show Now Playing status of tracks being played from third party sources...)
That change is in the works.
-
Your test version does work for me and the changes on our side that I mentioned have made it into the beta build now.
Great news! Many thanks.
I'm setting up a separate network to try and duplicate what you are seeing. Since our dev network has a lot of DLNA chatter on it, it's hard to isolate this type of trouble. Also, it seems that we always see MC's advertisments, stuff is coming and going constantly. It's hard to see how we could miss the responses to M-SEARCH's specifically from Whitebear.
It beats me too. Whitebear reuses a single unbound UDP datagram socket sendto() function for sending all M-SEARCH responses; so probably all responses from Whitebear's server and players have the same source IP and Port; could it be that, when you have seen one device datagram coming from a particular source IP and Port, that you may be discounting that combination for other devices?
If it helps, I can perhaps send you some Shark captures. Please let me know if you would like this.
Since I have only one squeeze device the only way I can really test this is to see if the server and renderer don't both appear right away.
There is quite a nice software based player "Squeezeplay" that you can download here http://downloads.slimdevices.com/nightly/?ver=7.7
That change is in the works.
Coool. Thanks.
-
It beats me too. Whitebear reuses a single unbound UDP datagram socket sendto() function for sending all M-SEARCH responses; so probably all responses from Whitebear's server and players have the same source IP and Port; could it be that, when you have seen one device datagram coming from a particular source IP and Port, that you may be discounting that combination for other devices?
We just found it. Too bad I didn't see your message first since it was the ip/port combo.
-
We just found it. Too bad I didn't see your message first since it was the ip/port combo.
Great news. I am delighted that you found it.
I think with these improvements on your side, and mine we shall have a great combination for interworking between MC and Logitech players.
I plan to wait for your release incorporating those changes, then do some quick tests on my side, and will formally release the v2.3 of Whitebear a few days thereafter. In the meantime MrC is kindly doing some user testing as well.
PS I just tried your beta build 99 with the M-SEARCH fix. => Brilliant !!!
PPS And apropos SetNextAVTransportURI and gapless playback: it even works with SBS crossfade (negative gap playback) => Coool !!
-
Hi Andrew, I just PM'd you with an issue from the last Whitebear build.
-
Hi Andrew, I just PM'd you with an issue from the last Whitebear build.
Thanks bob. Got it. And hopefully fixed it too...
-
By the way bob, I noticed that you recently added the feature "Ignore transport events".
Just checking, but I do hope that Whitbear is not a guilty party as far as such events are concerned?
If it is, please let me know, and I will try to fix that too.
-
By the way bob, I noticed that you recently added the feature "Ignore transport events".
Just checking, but I do hope that Whitbear is not a guilty party as far as such events are concerned?
If it is, please let me know, and I will try to fix that too.
No, it was for trying to deal with some hardware renderers.
-
I am pleased to announce that Whitebear v2.3 has been released on http://www.whitebear.ch/mediaserver.htm
-
Is there anyway of confirming that Whitebear is seeing my LMS database?
I am using WHS2011 with LMS and Whitebear running, both seem fine. I have switched off the DNLS server in LMS setting and Whitbear reports that it can see the LMS server, however when I try and look at the server from Windows Media PLayer on another PC on my network, although I can see a folder called music when I click it its says "No files have been found on this remote server" which makes me think that Whitebear is not seeing the LMS data?
-
... when I try and look at the server from Windows Media PLayer on another PC on my network, although I can see a folder called music when I click it its says "No files have been found on this remote server" which makes me think that Whitebear is not seeing the LMS data?
This is probably not the right place for you to have posted this query, but neverthless I will attempt to answer it for you anyway...
Let me just check: You are using Windows Media Player 12. And it shows a folder called "some_music_library_name (by Whitebear)". Which has a sub-folder called "Music". And that sub folder shows "No files have been found". Is that correct?
If so, then please right click on "some_music_library_name (by Whitebear)" and press "Refresh". You will need to wait about 45 seconds, but after pressing "Refresh" the first of your music tracks should start to appear in Windows Media Player. If you have a big library, then the full update may take a long time (with 10k tracks on my PC it takes about 15..20 minutes) however you will see the first tracks after about about 45 seconds. Note also that if LMS is doing a rescan when you press "Refresh" the update will fail: you have to wait until LMS has finished its rescan.
If "Refresh" does not work, then my next suspicion is that you have a firewall problem. In that case please turn on logging in the Whitebear tray monitor (check all of the logging options) before starting Windows Media Player and doing "Refresh", and then send me the log file.