Re: xAP Plug-in for SlimServer beta 3 release

["rb_ziggy" <richard.boreham@xxxxxxxxxxxx>]

Edward...

> I removed the brightness override from beta3 because the current
SlimServer
> API was not honouring the parameter to override the brightness.
Behaviour
> observed is to show the message at the requested brightness then
(after less
> than a second) revert to a preset brightness. As a workaround, you
can set
> the message display preset brightness by pressing the brightness
button on
> the remote while a message is being displayed; messages should then
all be
> displayed at that brightness.

I hadn't realised this could be done.  I'll have a go and see how it
works.


>
> Other odd behaviour reported is a message displaying for the first 30
> seconds of the requested period and then the display being blank for
the
> remainder of the period. I've not managed to reproduce that here.
>

I think I may have observed this too but not certain as when the
server closes it also gives just a blank display.  Pressing the
brightness button then gets the 'cant connect to server message'. The
server then needs to be restarted.

> I too have had the occasional crash during message display but have
not been
> able to replicate it so don't know what the cause is. If you find a
> repeatable scenario, I'd be very happy to hear about it.
>
>

I'll try to see what messages are being sent around the system at the
weekend and report back.

>   _____
>
> From: xap_automation@xxxxxxx
[mailto:xap_automation@xxxxxxx]
> On Behalf Of rb_ziggy
> Sent: 05 December 2006 00:23
> To: xap_automation@xxxxxxx
> Subject: [xap_automation] Re: xAP Plug-in for SlimServer beta 3
release
>
>
>
> Edward
>
> Thanks for the latest plugin. I've been using it for 10 days or so.
>
> I think the latest version, according to your log and my experience,
> no longer forces the brightness up to full on a display message. The
> previous one was rather good in that if the squeezebox was powered
> off, a display message came on at full and then reverted to low at the
> end of the display period. I'm not sure why you removed this but
> would you consider putting it back in as a configurable item (e.g.
> 'don't change', show at full, ...)?
>
> Also, I do seem to be getting some problems on display messages.
> After several displays (3??) the slim server just seems to stop
> itself. I'm not quite sure of the message circumstances yet and it
> could be something to do with my set up but thought I'd report it.
> I'll try a few tests at the weekend and see if I can come up with
> anything more definitive.
>
> Richard
>
> --- In xap_automation@ <mailto:xap_automation%40yahoogroups.com>
> yahoogroups.com, "Edward Pearson"
> <edward.mailgroup@> wrote:
> >
> > Huge thanks to all the feedback from the beta 2 testers.
> >
> > Beta 3 is now available at:
> > http://www.edjo.
>
<http://www.edjo.pwp.blueyonder.co.uk/edward/xAP/Slim/slim_downloads.htm>
> pwp.blueyonder.co.uk/edward/xAP/Slim/slim_downloads.htm
> >
> > Change Log:
> >
> > beta3
> > 14/11/06
> >
> > Changed open_port in Comm.pm to use INADDR_LOOPBACK,
> INADDR_BROADCAST and
> > INADDR_ANY
> > rather than localhost, 255.255.255.255 and 0.0.0.0
> >
> > Added configuration entry for xAP broadcast address. Defaults to
> > INADDR_BROADCAST.
> >
> > Removed restriction in Slim_Item.pm and SlimServer_Item.pm that
messages
> > need to be targetted.
> > BSC messages remain requiring a target as per spec.
> >
> > Now tries 'no hub' mode before trying to connect to hub
(Plugin.pm and
> > Comm.pm),
> > so should work without a hub.
> >
> > Determined that CRC.pm should not be included in the distribution
> (required
> > functions in Comm.pm).
> >
> > Fixed issues en-queuing and de-queuing display messages.
> >
> > Removed attempt to force brightness on display messages;
> > SlimServer v6.5 reverts to pre-set message brightness on next
display
> > refresh.
> >
> > Tidied up web settings. Used in-line HTML to work around default
> skin CSS
> > line spacing issues.
> > Only tested with default skin.
> >
> > Persist player subID values in player preferences.
> > Once an ID is allocated to a player it will keep that ID across
> restarts.
> > Previously done
> > on a first come (connect) first served basis at startup.
> >
> > Fixed null pointer issue in song/transport data when no current
playlist
> > exists for player.
> >
>