Print

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

[bob]

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.

[AndrewFG]

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.

[bob]

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...

[AndrewFG]

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...

[bob]

It's in builds >= 17.0.91

[AndrewFG]

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...)

[bob]

...

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?

[AndrewFG]

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...

[bob]

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.

[bob]

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?

[bob]

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!

[AndrewFG]

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

[AndrewFG]

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.

[bob]

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.

[bob]

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...

[AndrewFG]

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...

[bob]

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.

[AndrewFG]

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...)

[bob]

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.

[AndrewFG]

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.

[bob]

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.

[AndrewFG]

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 !!

[bob]

Hi Andrew, I just PM'd you with an issue from the last Whitebear build.

[AndrewFG]

Hi Andrew, I just PM'd you with an issue from the last Whitebear build.

Thanks bob. Got it. And hopefully fixed it too...

[AndrewFG]

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.

[bob]

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.

[AndrewFG]

I am pleased to announce that Whitebear v2.3 has been released on http://www.whitebear.ch/mediaserver.htm

[wytco0]

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?

[AndrewFG]

... 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.