Announcement

**Michael McSharry** · January 19, 2004, 03:33 PM

I believe I now see the Overflow. It occurs when a refresh time of over 32 seconds is used. This will be easily fixed.

<BLOCKQUOTE class="ip-ubbcode-quote">quote:<HR>

Installed 1.4.1 and the multiple Slimp3 clients is working once I got the naming convention down. I had a client (the SliMP3 player itself) that had a name of "Family Room", but apparently I couldn't figure out or the plugin could not deliver the name with a space in it. After chaning the name to something with no space, it worked.

<HR></BLOCKQUOTE>

xAP/SliMP3 connector limitation as I understand it. Since the name is part of the Target Address, and the target address does not allow spaces, then names with spaces will not transport. When I originally implemented it I wildcarded the name so it did not matter. Now with multiple clients the name needs to be fully defined.

<BLOCKQUOTE class="ip-ubbcode-quote">quote:<HR>

I can see messages in the xAP viewer just fine. However, I am not seeing any response to the album/artist queries from the Slim Server to mcsMusic. The mcsMusic web page does not show "Now Playing" info form the Slim Server.

Also, and this may be a side-effect of query above, I noticed that when I choose the player from the mcsMusic web page icon, the actual highlight waits for the general refresh. I've shortened my refresh interval. I was expecting it to refresh when the icon was selected. Is that possible?

<HR></BLOCKQUOTE>

If you run the console version of SliMP3 Connnector then you will see the connector's inbound stream, but not the outbound. If the connector recognizes the command as being directed to it, yet no updates ever occur, then I would blame it on the connector and we will just need to wait for the new one. If you have never had any updates showing on Now Playing then I do not think you will be able to find the source of this problem. Have you had any success with the current track info showing up on Now Playing while using SliMP3?

It is possible to implement javascript to refresh the client screen based upon the selection made. It would be similiar to the feedback provided on the run/stop/pause buttons. I thought about doing that, but then the problem exists with all the other frames as well. The player icon will show playerX while the other frames will show playerY info. I'll think about this one some more.

<BLOCKQUOTE class="ip-ubbcode-quote">quote:<HR>
The first time I select a Slimp3 player to control, if the Slimp3 player I select is not "playing", I must first select a playlist before any transport controls work (play, stop, etc.). According to the Slim Server web interface, the Slim Server provides for a playlist to be loaded and transport controls to work as long as a playlist is already loaded. Ie. the player can be stopped with a playlist loaded. I would then expect to be able to connect to the player via mcsMusic web page, and just hit "Play" to start the player since the playlist is already loaded, but this doesn't seem to work.

<HR></BLOCKQUOTE>

This is something that I hope will be fixed with the new connector. I tried to query the playlist from SlimServer, but it never responded. When mentioned to the SliMP3 Connector author, the discussion vectored to the theory of playlist item vs entire playlist being returned. Since it was in the "theory" state I just assumed that it was not yet implemented.

Because of this I took the approach of using the info in the database to artifically create a playlist that the plugin could track. Currently the only way I know about a playlist is when the playlist is selected via Now Playing. I know eventually the connector will support this and this limitation will vanish.

<BLOCKQUOTE class="ip-ubbcode-quote">quote:<HR>

I understand this may be a limitation of the xAP system. I don't understand why I don't see response packets in the xAP viewer from the Slim Server machine, but it could be the same reason? I don't see any response whether I'm only dealing with one Slimp3 player define or not. It may be a config issue with the xAP framework on the remote Slim Server box. I'm not sure if I have to or how to set up xAP for bi-directional communications (from HS server to Slim Server and vice versa).

<HR></BLOCKQUOTE>

I'm a novice at this too. That is why we are doing it this way for SliMP3. We have to try to make it as complex as possible.

I do not see anything in the viewer for Notification messages from SliMP3 connector. I do see the messages, however, in the plugin so I know most are comming.

**huggy591** · January 22, 2004, 09:08 PM

Thanks again for your posts and work on this, Michael. As you may know from my other post, I lost my HS server's main hard drive night before last, so I am down at the moment. May be a couple weeks before I get things set up again. I haven't backed up in a week and most of the changes I made were surrounding the mcsMusic plugin, so I'm hoping to recover the data from the hard drive and save some work. The Slimp3 and its server are still running fine, though!

I have never seen any Now Playing info (current track) showing up in the plugin web page for the Slimp3 or the Slim Server. Both the Slimp3 and the server do show the right current track/now playing info.

Looks like most of the issues we found are all in xAP, many you already knew about. So we wait for the next version of xAP.

- Gordon

"God is gracious, God is fair. To some He gave brains, to others, hair." - anonymous

"Don't look under the hat."
- Gordon, 2004

**Michael McSharry** · January 23, 2004, 06:00 PM

Recent fixes have been posted. This same configuration has been submitted to the updater to refresh the baseline.

Gordon, here is the latest communication on the SliMP3 connector...

<pre class="ip-ubbcode-code-pre">

I feel comfortable with the operation of the current SliMP3 connector.
I did confirm that I am able to control multiple SliMP3 with the current connector.
I am ready to move on to a version that will support Now.Playing and for which the playlist contents can be retrieved.
Is there a target date for when such capabilities will be available?

--

<grin> Target date? Yes, last year !

That *was* the plan, but I've been fiddling around a fair bit with
things and haven't quite finished things. I'm making a generic GUI
runtime that'll load one and all of my plugins so it's not just a case
of boshing together a single application. I keep adding in new
features and generalising others as I find them common between several
applications. But that's what xAPFramework is for.

Something I haven't got to yet but I was meaning to before releasing
this, was to trim down the amount of error checking I perform
internally. I check the validity of things everywhere in xAPFramework
and I probably overdo that a bit I suspect. I'm going to tune it down
and see if that makes a difference.

xAPFramework is very strict on well-formed messages. Indeed, I had to
resort to an alternative mechanism of sending malformed messages so
that I could test a new feature I've just added to Hub and Viewer.
I'll be updating those in a few days once I'm happy things still work
correctly.

I may also revisit the way things are queried as Edward suggested an
alternative form that has a single message/response cycle rather than
multiple passes back and forth querying individual items. I'll support
both though.

S

</pre>

**Michael McSharry** · January 29, 2004, 01:12 PM

V1.6.0 contains support for a 4-tier MP3 library and includes the V1.5.0 updates for remote operations plus some other little things I noticed while performing evaluation.

**Stuart Booth** · January 30, 2004, 06:08 AM

Hello guys,

Kevin Hawkins pointed me here. I hadn't realised there was so much going on in the background using the xAP SliMP3 Connector!

A new version has been around privately for several months, but I keep adding things to it. On the whole I'd say it is significantly different from the current release as it adds support for the event notifications coming from the Slim as xAP messages, and has much improved support for multiple players (now that I own more than one).

In fact, I've had it running myself for so long that I can't even remember all the differences.

The messages it supports are all as described in the schema documentation online, but there have been some suggested improvements - the main one being consolidation of multiple request/response queries into a single pass I think. I haven't implemented any of this yet in any way.

I'll have a gander through this thread and see what there is I need to address for you, but it won't happen until later this w/e I'm afraid - limited spare time at the moment!

Stuart

Stuart Booth
Somewhere in Buckinghamshire, England, UK

**CouchPotatoe** · January 30, 2004, 07:50 AM

I'm going to try and get to this stage of it all working too - I unfortunately have been using the later version of the SliMP3 xAP connector too and it works a little differently - particularly in regard to the addressing of multiple players. So I'll back down to a previous version and see what I can find.

I'll leave Stuart to jump in on the specific issues above but some thoughts on the more general xAP points..

You should be seeing responses from the SliMP3 connector Gordon. One of the things about any IP network protocol like xAP is that only one application on a PC can listen on a given port at once. In a case when you have multiple applications all wanting to listen to the same data (port) then some form of relay or 'hub' is required. Therefore a xAP hub MUST be launched as the very first xAP application. On the xAPFramework site there is a GUI version of a xAP hub for download if you want. However Stuart's recent applications are intelligent to the extent that if you launch say 'Viewer' without having a hub present then Viewer will act as a hub too. It will display this 'status' in the title bar for it's window so you can see if it has taken the hub role. This is the easiest way to ensure you have a hub running probably, make sure you launch Viewer before the SliMP3 connector and before HomeSeer.

I am almost certain this is why you are not seeing responses from the xAP SliMP3 connector - a typical symptom of no hub is that all but one xAP application become 'deaf' as only one application is able to listenon the correct xAP port (3639).

Yes.. the SliMP3 connector does require the SlimServer to be running first - in order to asertain what players are connected. Plus I think the version used here requires a xAP hub running before too ie it doesn't act as a hub itself automatically (Stuart ??)[KHedit - just checked the 1.2.7.1 build and it does automatically act as a hub if needed so the SliMP3 connector can be the first xAP loaded]. There therefore may be an issue with the startup sequence and timing for services - and indeed the SlimServer can be quite unresponsive at launch so may not service the xAP connectors CLI requests in a timely manner anyway. Best to ensure the SlimServer is responsive ie music is playable before launching the xAP SliMP3 connector and also ensure hub or Viewer is running before that - lastly run HS.

RE multiple SliMP3's and servers - the multi player handling using this connector does work I believe but was not a design feature . This support is significantly improved, and different, in the next release which implements the hardware endpoint sub addressing. I see no reason why multiple Slim servers can't be used either although a separate instance of the SliMP3 xAP connector should be run for each SlimServer. I am not sure why people would want to be using multiple SlimServers though . Perhaps for resilience performance or different available libraries ?? Kevin

[This message was edited by CouchPotatoe on Fri, 30 January 2004 at 11:53 AM.]

**CouchPotatoe** · January 30, 2004, 12:04 PM

I am now of the belief this is not a hub issue but a probable multiple player addressing issue with the older xAP SliMP3 connector - Have either of you got multiple players working correctly with the v1.2.7.1 xAP connector ?? ie got mutiple SliMP3 players installed and updating the Now Playing screen ??

Michael - not sure if you actually have any SliMP3's there or if this was done from specs ?? The new xAP connector implements addressing differently but actually already works because of the way you enter the SliMP3 ID's in a text box. I think it would be good to focus around this new version for anyone who has multiple SliMP3's - the v1.2.7.1 works for one player though quite well.

The very nice feature that you will have is that the interface becomes 'event driven' rather than the polling approach that you have to utilse now so it's much neater. I have spoken to Stuart and whilst he is temporarly busy I will try and sort this so I will contact you both offlist.

Kevin

**Michael McSharry** · January 30, 2004, 04:14 PM

I have demonstrated functionality with three instances of Winamp which are each connected to SlimServer. Two were on the same PC as SlimServer using the 127 and the 192 networks and the third was on a remote PC. Yes, the Now Playing screen was updated and selection among the three resulted in display and control of the correct one.

Stuart had previously indicated that he never tested the multiple SliMP3, but when I tried it worked first time.

**CouchPotatoe** · January 30, 2004, 05:57 PM

Were these created as 3 different SliMP3 players in Now Playing or as 3 WinAMP players ? If as WinAMP players then effectively the control is a pull driven model from the WinAmp clients on the SliMP3 server. The SliMP3 hardware clients are different in that they are driven via the SliMP3 connector in a push model which is where the difference may be coming from. (To an extent teh IR creates a pull model but the server implements this totally as a push. This requires the players are differentiated within the xAP messages using target addressing and varying source address responses which I am not able to establish works as it should for multiple players in the 1.2.7.1 release. Kevin

**CouchPotatoe** · January 30, 2004, 06:07 PM

Some more background on the SliMP3s. The SliMP3 hardware is not really an MP3 player , indeed the stream to the Slimp3 is a custom udp protocol that entwines a data path for the IR and display capabilities. For a Squeezebox the transport used is tcp and additionally an uncompressed audio format is supported. SliMP3's absolutely require the server and couldn't for example connect directly to a MP3 streaming source directly eg a Shoutcast stream, internet radio station or an MP3 served file - it has to be adjusted in format by the SliMP3 server to play on the SliMP3s. It is not transcoded in any way, so quaility is preserved as there is an mp3 hardware decoder chip in each SliMP3 but it is not a standard format mp3 streaming source either.

The SliMP3 server will additionally serve an MP3 stream directly and separately to say a WinAMP client. There is virtually no RAM in the players (only an audio buffer and screen memory) - the SliMP3 server manages all the IR/Display interaction effectively building displays on the fly and then enforcing appropriate custom data streams on the individual players for audio. Im thinking this is perhaps different to the way people visualise the SliMP3s work.

Kevin

**huggy591** · January 30, 2004, 06:46 PM

At present I'm rebuilding my Homeseer system. I hope to have mcsMusic and xAP reinstalled this weekend, ready for more testing. In my architecture, I am running Slim Server and xAP Slimp3 Connector as a service on one machine. On the other machine, I'm running HS with the plugin, and xAP as a service which references the remote machine's IP. Is that the correct setup - xAp talking to xAp on another system? Should the xAP configs point to each other?

My testing, including startup sequences, has never produced any info in the Now Playing frame of the plugin from the remote Slim Server. Controls work fine, but I get nothing back. I have the xAP service installed on both the remote Slim Server and the local HS machine acting as a client, so xAP always starts at bootup. Slim Server on the remote machine starts in the background as well, but I don't know which starts first.

I guess I don't understand why starting the xAP services before the Slim Server is a problem for the system - can't the xAP service poll the Slim Server for the player info at some interval after the initial poll? If I add a player (say, a Winamp client) to the Slim Server, I should not have to restart the Slim Server and the xAP connector to see it and allow it to be controlled. That should ripple through to the other side - a "new player" event notification to clients. If Slim Server doesn't support it, xAP can poll for changes in the player list every few seconds.

As a work-around, there must be a way to set the dependency for the xAP service to depend on SlimServer... I just don't know the registry setting(s). It should have installed that way, IMO.

As for mutliple players, I have tested the remote Slim Server with a Slimp3 player and a couple Winamp stream players. I can control all three. Except for a couple issues in the plugin like spaces in a name of the player, and the need to select a playlist each time the player is selected to control it, it was running quickly. Non-buffered players like the Slimp3 respond immediately to the plugin's web buttons - very nice. I'm sure Michael will address these issues if he hasn't already.

It was not clear to me why the Viewer saw only one direction's packets, but not the other. If you are in the TCP stream, you should see both unless you are somehow setting up duplexed communications on two sets of ports. The viewer app (v1.2.1.2) doesn't show anything in terms of being a hub or not.

I'm going to try to get it installed on my HS machine now.

- Gordon

"God is gracious, God is fair. To some He gave brains, to others, hair." - anonymous

"Don't look under the hat."
- Gordon, 2004

**CouchPotatoe** · January 30, 2004, 07:26 PM

Hi Gordon,

Where the various xAP bits sit is not a problem - xAP does not any form of 'connection' between its various bits so any application can sit on any PC . This makes xAP very tolerant of bits coming and going and easy to configure. You can target messages specifically at one application but they are still heard by all - the targeting just warns others not to respond. xAP actually talks 'broadcast' rather like a boardroom conference analogy.

The lack of responses your are seeing I now feel is down to addressing issues within the connector. Have you actually created 3 SliMP3 players in Now Playing or just one and two WinAmp ones ? The connection will still work in a half duplex mode as xAP is connectionless. So the commands could go through but the responses be lost. This would happen if either end were targeting messages but using the wrong addresses or filtering responses based on the originator and again using the wrong address. What exactly have you entered in the text box for the ident for each of the SliMP3 players that show in Now Playing ? If you were not getting responses showing in Viewer this is because the targeting is wrong somewhere. It could also have been a hub issue but I now think not.

Starting the SliMP3 xAP connector before the Slim Server is a problem in that release of the software. This is for two reasons. Firstly the SliMP3 connector builds tcp connections to the SliMP3 server and does not handle breaks in that connection elegantly - we know that really it should and the new release is intended to fix that. Secondly the connector only builds its playet list at launch. Again I think as a feature request the ability to have dynamic player additions and removals is a good one, but it may be a little way down the list of priorities. Certainly technically I see no obstacles. Initially there was a problem with the SliMSerevr where players had numbers 1 2 3 4 etc so as they shuffled this could have caused a problem - however a move to MAC based player recognition and tracking has removed this obstacle.

The dependancies within the services start sequence I think work correctly as is. The problem is that say on my system it is a good 10 minutes from startup before the SliMServer services the tcp socket binding and CLI requests from xAP . This is because of intensive library build time and cpu utilisation. As we have not got a system to automatically re-establish broken tcp sockets to SlimServer in the current version this could become an issue, a simple relaunch of the SliMP3 connector would get it all running smoothly. This again should go away on release. As you are not experiencing this problem I take it your SliMServer launches to a useable state very quickly after a restart. Most times of course the SlimServer is permanently running and restarts are very infrequent so this never crops up.

I need to setup and play with WinAmp clients on SlimServer - I will try that shortly - some of what I am saying and what you are saying seems to not match up well so I'll do some homework.

Lastly re your comment on the full duplex conversation within a TCP connection - yes this would be true but we do not use TCP we use UDP as it is broadcast. Plus the sent information all goes to a broadcast address & port 3639 on your subnet eg 192.168.1.255:3639 but the received information has to be relayed to multiple listening apps on different ports on one machine eg perhaps into 192.168.1.40:3652 or something - if that inward relaying was not working (a hub responsibility)or if a mismatched target address is used then the xAP application doesnt hear the message and hence wont repond. So you would only see half of the conversation.

Kevin

**CouchPotatoe** · January 30, 2004, 07:49 PM

Michael - Gordon - could you just let me know exactly what you have entered in the Network Identification for the 3 SliMP3 players in the config screen. Are you both using the service version 1.2.7.1 ?

I have added a Winamp player and it behaves differently to how I had imagined this would work, appearing, as you say as a nameable SliMP3 player which is great. My normal setup only has SliMP3's and a Squeezebox attached.

Gordon - I assume now playing does not display anything for SliMP server players for you still ??

Kevin

**CouchPotatoe** · January 30, 2004, 09:12 PM

Right... I'm sorry this has been a bit confusing but without Stuart around I have been unsure as to what actually is in the 1.2.7.1 release version that is on his website. What I have found is that the release there supports the newer form of addressing for target= which is
KCSoft.SliMP3.<servername>:<playername> and this control is working over mutiple players including WinAMP clients. The WinAMP clients respond slowly due to the buffering at the client whereas the SliMP3 clients are near instantaneous. What I have not been able to get is any responses to these messages from the xAP connector which should come back in the form
Source=KCSoft.SliMP3.<servername>:<playername>. What this means is that the NowPlaying screen is not able to poll the players every two seconds or so for their state and therefore can't update the screen with the track info.
Now that ties in with what Gordon is seeing but not with Michael . So something is different between the setups - Michael is there any possibility you perhaps have a later version of the SliMP3 connector running there (version is shown on launch). Or perhaps it is to do with some other component of xFx that you have installed that the SliMP3 connector is using. Stuart could this be possible ?? I am assuming that the connector is responding to your poll messages with track, state, artist and album information - have you a copy of one of those request and response messages you could post here or email to me ?? I am interested to see the header of the response particularly with relation to the UID and source address field.

What is also puzzling is that using a recent beta that completely supports this new addressing I am now getting responses sent back from the xAP connector as I would expect - but these still don't show in the NowPlaying screen -so something is still wrong. Now Playing does display correctly for CDJ although I still have no album cover display so that to track down and fix - maybe the two are related. The correct cover art displays in the CDJ window.

Kevin - off to bed 4AM

**huggy591** · January 30, 2004, 09:22 PM

I'm still re-installing from a hard drive loss a couple weeks ago. Most of what you said makes sense - especially the UDP protocol use. I'm in netowkring, I undertsand that level. As I get things set up again I'll answer some of your questions. I'm wondering if internally you ever use the loopback IP (127.0.0.1), which, as you know, has trouble in later versions of Windows because of the crippled IP stack.

At present, I have the same setup on the Slim Server machine - xAP Slimp3 connector service running. That machine points to the Homeseer machine by IP address in its XML config file.

I'm setting up my rebuilt Homeseer machine now, which will run the xAP connector service pointing to the IP address of the Slim Server machine via it's XML config file. The plugin will have 2-4 players configured as Slimp3 - the first one will be the Slimp3 Player on my network, the other 3 will be Winamp players on various machines. Slim Server adds Winamp players as they connect, keeping them in the config as long as the Slim Server runs or until you remove it from the Slim Server.

The two players I use are "Family" and "Pigpen" (no quotes). These are the exact names of the Slim Server's Clients. Family is the Slimp3 player, Pigpen is Winamp on my workstation (my normal/regular machine I use daily). My workstation is XP pro, the two servers are Win2k Server.

If you can tell me what I should see in terms of open ports and connections to/from each machine, I can do a little snooping, too. I also have network sniffers, etc I just haven't bothered to use for this issue.

- Gordon

Did they really change the Star Trek motto under Jean-Luc Picard's command to, "To Baldly Go Where No Man's Hair's Gone Before!" ???

"Don't look under the hat."
- Gordon, 2004

Announcement

mcsMusic Feature Requests and Problem Reports

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment