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"><font size="-1">quote:</font><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"><font size="-1">quote:</font><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"><font size="-1">quote:</font><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"><font size="-1">quote:</font><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.
<BLOCKQUOTE class="ip-ubbcode-quote"><font size="-1">quote:</font><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"><font size="-1">quote:</font><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"><font size="-1">quote:</font><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"><font size="-1">quote:</font><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.
Comment