PDA

View Full Version : 3/12 build quirk Win 2k



Steve Frawley
2005-03-12, 14:32
Sorry I meant Windows 2000 and SliMP3 unit (I have a couple running and
haven't checked the Mac yet)

Steve Frawley <Steve (AT) Frawleys (DOT) com>
From the G5

------ Forwarded Message
> From: Steve Frawley <Steve (AT) Frawleys (DOT) com>
> Reply-To: Slim Devices Developers <developers (AT) lists (DOT) slimdevices.com>
> Date: Sat, 12 Mar 2005 14:26:21 -0700
> To: SliMP3 Dev NEW <developers (AT) lists (DOT) slimdevices.com>
> Subject: [Developers] 3/12 build quirk
>
> The 3/12 build occasionally shows the currently playing song on the display,
> but mostly shows the first song it played.
> (Mac OS X 10.3.8 and SliMP3 units)
>
> Steve Frawley <Steve (AT) Frawleys (DOT) com>
> From the G5
>
>
>

kdf
2005-03-12, 14:42
Quoting Steve Frawley <Steve (AT) Frawleys (DOT) com>:

> Sorry I meant Windows 2000 and SliMP3 unit (I have a couple running and
> haven't checked the Mac yet)
>
Thanks Steve,

This has been a known problem that should be fixed for todays build, but it
seems that the fix doesn't include slimp3 animation. If your display not
scrolling, does it change songs properly?

-kdf

Triode
2005-03-12, 15:05
Kdf,

Assuming it is now upto the scrolling command to detect a change in line 2 [which is what I implemented for SBG/SB2 etc] I think it
is quite easy to do the same for Slimp3.

I think (total speculation!) that the function doing the work is Slim::Display::VFD::Animation::animateScrollSingle 2 ??

If so we want to add something round:
$lines = $client->parseLines(Slim::Display::Display::curLines($clien t));

to check for change in line2?

I can propose something if someone with a SlimMP3 can test it?? Does this cover SB1 with no graphics too?

Adrian
----- Original Message -----
From: "kdf" <slim-mail (AT) deane-freeman (DOT) com>
To: "Slim Devices Developers" <developers (AT) lists (DOT) slimdevices.com>
Sent: Saturday, March 12, 2005 9:42 PM
Subject: Re: [Developers] 3/12 build quirk Win 2k


> Quoting Steve Frawley <Steve (AT) Frawleys (DOT) com>:
>
>> Sorry I meant Windows 2000 and SliMP3 unit (I have a couple running and
>> haven't checked the Mac yet)
>>
> Thanks Steve,
>
> This has been a known problem that should be fixed for todays build, but it
> seems that the fix doesn't include slimp3 animation. If your display not
> scrolling, does it change songs properly?
>
> -kdf
>

kdf
2005-03-12, 15:12
Quoting Triode <triode1 (AT) btinternet (DOT) com>:

> Kdf,
>
> Assuming it is now upto the scrolling command to detect a change in line 2
> [which is what I implemented for SBG/SB2 etc] I think it
> is quite easy to do the same for Slimp3.
>
> I think (total speculation!) that the function doing the work is
> Slim::Display::VFD::Animation::animateScrollSingle 2 ??
>
> If so we want to add something round:
> $lines = $client->parseLines(Slim::Display::Display::curLines($clien t));
>
> to check for change in line2?
>
> I can propose something if someone with a SlimMP3 can test it?? Does this
> cover SB1 with no graphics too?

it should. I have access to both, so you can send me a patch ad I'll give it a
go.

Steve, are you able to patch and test as well to confirm a fix?

However, I've also been looking for a more generic place. All this custom code
per player really needs to be kept to a minimum, I think. Granted, if this
works, and soething generic will be a headache, then I'm all for it :)

-kdf

kdf
2005-03-12, 15:28
Quoting Triode <triode1 (AT) btinternet (DOT) com>:

> Kdf,
>
> Assuming it is now upto the scrolling command to detect a change in line 2
> [which is what I implemented for SBG/SB2 etc] I think it
> is quite easy to do the same for Slimp3.
>
> I think (total speculation!) that the function doing the work is
> Slim::Display::VFD::Animation::animateScrollSingle 2 ??
>
> If so we want to add something round:
> $lines = $client->parseLines(Slim::Display::Display::curLines($clien t));
>
> to check for change in line2?
>

It seems there is a function call to Player::Playlist::refreshPlaylist) called
at each song transition to ensure that the dipslay is showing the corrent "now
playing' item. I think this would seem to then make a reasonable place to kill
animation.

I'd like to hear a confirmation from Vidur, since this is a lot of his recent
rework.

-kdf

Triode
2005-03-12, 15:33
OK - I'll leave it for the moment.

----- Original Message -----
From: "kdf" <slim-mail (AT) deane-freeman (DOT) com>
To: "Slim Devices Developers" <developers (AT) lists (DOT) slimdevices.com>
Sent: Saturday, March 12, 2005 10:28 PM
Subject: Re: [Developers] 3/12 build quirk Win 2k


> Quoting Triode <triode1 (AT) btinternet (DOT) com>:
>
>> Kdf,
>>
>> Assuming it is now upto the scrolling command to detect a change in line 2
>> [which is what I implemented for SBG/SB2 etc] I think it
>> is quite easy to do the same for Slimp3.
>>
>> I think (total speculation!) that the function doing the work is
>> Slim::Display::VFD::Animation::animateScrollSingle 2 ??
>>
>> If so we want to add something round:
>> $lines = $client->parseLines(Slim::Display::Display::curLines($clien t));
>>
>> to check for change in line2?
>>
>
> It seems there is a function call to Player::Playlist::refreshPlaylist) called
> at each song transition to ensure that the dipslay is showing the corrent "now
> playing' item. I think this would seem to then make a reasonable place to kill
> animation.
>
> I'd like to hear a confirmation from Vidur, since this is a lot of his recent
> rework.
>
> -kdf
>

kdf
2005-03-12, 15:42
Quoting Triode <triode1 (AT) btinternet (DOT) com>:

> OK - I'll leave it for the moment.
>
>

cool. I think there is a good spot at Buttons::Playlist::jump(). It gets
called every song change to make sure we're showing the right one. its this
function that puts the info on line2 that we're detecting, so makes sense to
kill animation there I think. Saves having to kill from each client's code.

If anyone wants to try this patch out, please let me know how it goes. I'll run
it for a while here on mine and see. I have 2 SBG, one slimp3 and a SB-nonG.

-kdf