RE: Slim connector problem (slightly long description!)

["Kevin Hawkins" <lists@xxxxxxxxxxxxxxxxx>]

Hi Paul,

The behaviour you are experiencing below is very much correctly
(even though it may not be what you expected). The Slim Display as included
within xAP Desktop is really just a remote track display for the current
playing / last played track - and it additionally has some transport
controls placed below for controlling the SliMP3. It was not designed as a
total front end display/control for the SliMP3 - (for that you would
proably
use SoftSqueeze synched with a player). However ... it could be... (and no
doubt will be)..
The xAP Desktop SliMP3 display is simply an example of a template
and it could be enhanced by any user to support better synchronised display
- mainly by a combination of more messages intercepted and displayed and
maybe use of the SliMP3 connectors 'whats on the SliMP3 display currently'
feature. The functionality is all contained within the settings file so you
can customise it to be as you wish - that is what xAP Desktop 'does' - it
is
a front end tool that the user can alter to present data just as they wish,
for example some users may want a  volume control or a power button - or in
my case I preferred a wider display with less horizontal scrolling.  I did
notice the 'off 1' track discrepancy and it needs some looking into - my
'wide SliMP3' version of that template which I think is in the files area
here displays 1 less on the X of X track numbering but that may not fix all
the combinational issues you are seeing below.
I am sure that a lot of people would be interested in a 'fully
feature' version of the SliMP3 display and that such a Desktop template
will
appear as contributions from the users. Heck I may even pop one together
myself.
The best way to look upon xAP Desktop is as a 'display toolkit' that
can be fully customisable to meet most needs. The included display
templates
are just examples to get people started although I hope they get ehanced to
become full featured each in their own right. Every aspect is controllable
and changeable within the settings file for each separate display. I hope
we
develop a thriving little community exchange of the these Desktop templates
- rather like skinning.

Some more comments inline....

> -----Original Message-----
> From: Paul Gordon [mailto:paul@xxxxxxx]
> Sent: 11 June 2004 10:52
> To: xap_automation@xxxxxxx
> Subject: RE: [xap_automation] Slim connector problem
> (slightly long description!)
>
> More Info...
>
> I've been able to install the service version OK, and it
> seems to be working... (Homeseer detected a new device OK)
>
> I've also got a slim display showing on xAP-desktop which "sort
of"
> works, - but somehow the desktop display has managed to
> get a bit out of step with the real slim display....
>
> Some observations:
>
> Using the slim remote, I queued up a track (that actually
> I shouldn't have), which couldn't play since it is a WAV
> file, and I have a slim not a squeeze.  However the new
> slimserver software showed it for selection and I forgot
> it was a WAV so selected it without realising my mistake.
> Obviously the slim didn't *actually* play anything...

I don't think this 'Wav' file has caused an issue..

>
> So (again with the remote), I selected a different (MP3
> this time) file, & pressed "Play" on the remote, thus
> removing the previous track, and replacing it with the new
> one. The slim device correctly shows "Now Playing (1 of
> 1)", however the desktop display shows "Now playing (2 of
> 1)" and shows the correct track details on the 2nd line.

I think this may be a template error or some interaction between 0 based
counters and 1 based counters bewteen the SliMP3 connector and Desktop, or
I
think it is possible that some counts from the SliMP3 CLI are 1 based and
some 0 based - let me play a bit here, I know my version displays slightly
differently ( 1 less ) so I'll see what it does in these circumstances. The
display templates have the ability to do simple math on xAP paramater
values
to correct this if it needs it.

>
> Using the remote to pause & unpause the player doesn't
> cause the correct transport status to show up on the
> desktop display; - it never changes to "Paused (x of x)"
> but remains steadfastly on "Now playing...."

It hasn't been set up to do this but it probably can quite easily.

>
> The same is true if I use the slim remote to turn the
> player off, - the desktop display remains on "Now
playing..."

Ditto

>
> Using the slim remote, I go back to the browse selection
> and select another track, - I press "Play" on the remote
> to replace the playing track with the new one... - The
> desktop display correctly updates the track details in the
> 2nd line, but still doesn't update the (x of x) part  - it
> sill says "(2 of 1)"

Same issue

>
> Using the slim remote, I add another track to the playlist
> by using the "REC" button to append another track, the
> slim now correctly displays
> "(2 of 2)" on the VFD, but still the desktop part does not
> update. - Still says "(2 of 1)"

Same issue
>
> I let the first track finish and the slim moves on to the
> next track (in reality 2 of 2). The desktop display
> correctly updates to the new track details on line 2, and
> this time the 1st line *does* update, :-)  but
> not correctly... :-(    It has updated to say "(3 of 2)"

Same issue
>
> I let the 2nd track finish, the slim stops playing, and
> the VFD correctly displays "Stopped (1 of 2)", but the
> desktop display does not update at all, and still says
> "Now Playing (3 of 2)"

Not set up to do this

Also, because the slim has reached
> the end of the playlist, it returns to the top entry, so
> the 2nd line on the VFD shows the track name of track no.
> 1 (as it should, since it also says "1 of 2"), however,
> the track display on line
> 2 of the desktop viewer does not follow that behaviour and
> continues to show the track details for track 2 (the last
> track played).

Ahh that's an interesting one - the Desktop display shows the trackname as
reported by the CLI interface via xAP having been converted into a suitable
schema - so it appears this would have to be badly reported on the CLI -
was
this actually a playing track or was the player in stop/pause (in which
case
I could see whay this might happen) - will try it here

>
> Finally, - using the buttons on the xAP-desktop slim
> display to pause/unpause/stop the player does work
> correctly (at the transport level), - the slimp3 correctly
> plays/pauses/stops as appropriate, and the VFD shows the
> correct status. But yet again, the desktop display never
> shows any transport status other than "Now playing" - even
> when it has just issued a pause or a stop command, which
> has been actioned by slimserver....

Not set up to do this..

And in this case line
> 1 has updated the (x of x) count to something closer to
> (but still not correct) the real situation.... - it has
> changed to say "(2 of 2)" - so at least the number of
> tracks in the playlist has updated to the correct number,
> however, the slimp3 is actually playing track "(1 of 2)"
> Line 2 on the desktop display is at this point showing the
> track name of track 1 (which is correct). I then pressed
> the "next track" button on the xAP-desktop slimp3 display,
> and the slim obeyed, - I was about to say the desktop
> display did not update in any to reflect that, but
> actually I've just noticed that it has - but it seemed to
> take quite a while to do it... - now it has reverted to
> "(3 of 2)" but at least line 2 is showing the correct track
name...
>
> Now I appreciate that I probably confused it by trying to
> load an invalid track (WAV) into he playlist the first
> time round,

I don't think this actually changed things at all

> but having done so, the desktop display seems
> determined not to "sync" properly with the real
> situation.... It's also disconcerting that the transport
> status (playing, paused or stopped) or the slim's power
> status (of /
> off) does not seem to be reported by desktop, - is this
> how it should be?

Yep - currently but it can be enhanced to support these extra features -
and
this can all be done at the user level - nothing to do with say the
'Slimp3'
is specifically coded into Desktop - it's just a template running from the
associated setting file

>
> One other slightly odd thing...  When I started up the
> slim connector service the Homeseer plugin correctly
> detected the new device and launched the new hardware
> wizard, much as I expected...

I have all my track names, artists, albums etc synched and displayed as
devices in HS

>
> However, the first time I used the slim remote to pause
> the player, Homeseer again launched the new hardware
> wizard and created another device (which I wasn't
> expecting) - what's that all about?

Are you saying it actually created a new device without asking ?? What does
the device reflect - is it an IR key ? Normally the wizard will only
trigger
if a new source device address is seen. In this case the source address
should have remained the same between the IR and the other schemas so I
wouldn't have expected this, interesting - the fact it created a device too
without asking is very weird ??

>
> - Is there ay debugging that I can turn on to help diagnose this?
>
> - *should* the desktop display correctly report the
> transport status?
>

I think it would be much more intuitive if it did and is an expectation
level people mighty have - one for a user contribution perhaps,  I may even
have a look at this myself... but as is it is behaving as expected.

> As much as I want to, I don't think I can currently use
> the desktop slim display with these inaccuracies.... :-(

The only 'glitch' seems to be the one off in the track numbers - the other
bits are as expected but open to being changed if you want to ..

Kevin


>
> Cheers.
>
> Paul G.
>
>
>
>
>
> > -----Original Message-----
> > From: Paul Gordon
> > Sent: 11 June 2004 09:10
> > To: xap_automation@xxxxxxx
> > Subject: [xap_automation] Slim connector problem
> >
> > I just failed at the very first hurdle trying to install the GUI
> version
> > of
> > the slim connector... :-(
> >
> > As soon as I run slimserverconnector.exe to install it,
> I get the
> > following
> > error:
> >
> >
> -----------------------------------------------------------
> -------------
> --
> > -------------------------------
> > SlimserverConnector.exe - Common Language Runtime
> Debugging Services
> >
> > Application has generated an exception that could not be handled
> >
> > Process id = 0xf24 (3876), Thread id = 0x4b0 (1200)
> >
> > Click OK to terminate the application
> > Click CANCEL to debug the application
> >
> -----------------------------------------------------------
> -------------
> --
> > ------------------------------
> >
> >
> > Any ideas?
> >
> > Thanks
> >
> > Paul G.
> >
> >
> >
> >
> > ------------------------ Yahoo! Groups Sponsor
> >
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
> >
>
>
>
>
> ------------------------ Yahoo! Groups Sponsor
> --------------------~--> Yahoo! Domains - Claim yours for
> only $14.70
> http://us.click.yahoo.com/Z1wmxD/DREIAA/yQLSAA/dpFolB/TM
> -----------------------------------------------------------
> ---------~->
>
>
> Yahoo! Groups Links
>
>
>
>
>