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