[Message Prev][Message
Next][Thread Prev][Thread Next][Message
Index][Thread Index]
RE: Slim connector problem (slightly long description!)
- Subject: RE: Slim connector problem (slightly long
description!)
- From: "Paul Gordon" <paul@xxxxxxxxxxxxxxxxxxxxx>
- Date: Fri, 11 Jun 2004 14:16:37 +0100
Thanks for the comprehensive reply Kevin!
I Think there are a couple of questions for me to answer in there, so
I'll attempt to do so...
The conduit didn't just create a new Homeseer device without asking me,
- It just surprised me that it detected a new xAP device and popped up
the wizard accordingly... - I selected to let it create the HS device,
since I didn't know what it was or what it was for, so I reckoned it
must be better to have it than not to have it... :-o
For info, when the slim connector service was first started, the HS
device created was:
jukebox slimp3 kcsoft.slimp3.jukebox:slimp3 xAP-Audio.Audio.Event
Audio.Mixer volume
Device type = slimp3, and the Homeseer Status string is set to 50 (not
sure what that means...)
Subsequently, - and I said earlier that it occurred when I used the slim
remote to play a track, (but now I'm not 100% certain that the timing of
those events are related) the conduit detected another xAP device as
follows:
pauls-qbic mi4.desktop.pauls-qbic xAP-Audio.Transport Audio.Transport
command
Device type = Desktop, and the Homeseer status is "stop"
- this 2nd one is the unexpected one I was referring to below, - it did
happen to pop up the Homeseer new hardware wizard just as I happened to
use the slim remote, but I suspect that is coincidental... - as not long
before that I had installed the slimp3 viewer template in xAP-Desktop,
but there was a delay of a minute or two between setting up xAP-desktop
and the Homeseer hardware wizard popping up...
Also, now that I know that the behaviour I see is expected, at least I
know it's not me being a dolt!
Thanks.
Paul G.
> -----Original Message-----
> From: Kevin Hawkins [mailto:lists@xxxxxxx]
> Sent: 11 June 2004 12:58
> To: xap_automation@xxxxxxx
> Subject: RE: [xap_automation] Slim connector problem (slightly long
> description!)
>
> 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
> >
> >
> >
> >
> >
>
>
>
> ------------------------ Yahoo! Groups Sponsor
>
>
> Yahoo! Groups Links
>
>
>
>
xAP_Automation Main Index |
xAP_Automation Thread Index |
xAP_Automation Home |
Archives Home
|