uninitialized value Slim/Buttons/Playlist.pm line 190

[Richard Purdie]

Use of uninitialized value in numeric eq (==) at Slim/Buttons/Playlist.pm
line 190.

I'm still getting this as of current CVS as per my original report. I've
done some more digging.

When the server goes into screensaver mode, it calls pushMode which pushes a
new hash reference onto $client->modeParameterStack. If nothing is passed,
it defaults to an empty hash reference.

This means when in screensave mode, browseplaylistindex is not defined which
leads to the above error message. When the player is woken up, it popModes
off the screensaver mode, browseplaylist is back and everything is happy
again.

Should pushMode default to a copy of the existing hash, overwriting any
values it's passed?

RP

[Robert Moser II]

Richard Purdie blurted out:
> This means when in screensave mode, browseplaylistindex is not defined which
> leads to the above error message. When the player is woken up, it popModes
> off the screensaver mode, browseplaylist is back and everything is happy
> again.
>
> Should pushMode default to a copy of the existing hash, overwriting any
> values it's passed?

I would say that the Screensaver mode should initialize any values it
needs in setMode. Copying the current modestackparameter hash by
default would only be useful if the two modes used the same parameters,
which I don't think is the case most of the time.

[Richard Purdie]

> > Should pushMode default to a copy of the existing hash, overwriting any
> > values it's passed?
>
> I would say that the Screensaver mode should initialize any values it
> needs in setMode. Copying the current modestackparameter hash by
> default would only be useful if the two modes used the same parameters,
> which I don't think is the case most of the time.

I knew there had to be something somewhere which set variables like that - I
just couldn't find it . Perl isn't my best lanugage...

Adding :

if (defined(${$client->modeParameterStack(-2)}{'browseplaylistindex'})) {

Slim::Buttons::Playlist::browseplaylistindex($clie nt,${$client->modeParamete
rStack(-2)}{'browseplaylistindex'})
}

to the function SetMode in Slim/Buttons/ScreenSaver.pm gets rid of the
error. Whether this is the right way to fix it or not remains to be seen.

RP

[Robert Moser II]

Richard Purdie blurted out:
> I knew there had to be something somewhere which set variables like that - I
> just couldn't find it . Perl isn't my best lanugage...
>
> Adding :
>
> if (defined(${$client->modeParameterStack(-2)}{'browseplaylistindex'})) {
>
> Slim::Buttons::Playlist::browseplaylistindex($clie nt,${$client->modeParamete
> rStack(-2)}{'browseplaylistindex'})
> }
>
> to the function SetMode in Slim/Buttons/ScreenSaver.pm gets rid of the
> error. Whether this is the right way to fix it or not remains to be seen.
>
> RP


In the version I checked in, I initialize it to the currently playing
song like this:
Slim::Buttons::Common:aram($client
,'browseplaylistindex'
,Slim::Player::Source::currentSongIndex($client));

[Richard Purdie]

> In the version I checked in, I initialize it to the currently playing
> song like this:
> Slim::Buttons::Common:aram($client
> ,'browseplaylistindex'
> ,Slim::Player::Source::currentSongIndex($client));

What happens if you're browsing the playlist and the screensaver comes on?

If you were browsing item 16 and item 7 was playing, browseplaylistindex
would be 16 and currentSongIndex() would return 7. Both would be 7 when the
screensaver was shown.

I don't think it makes much different to be honest as long as it's set to
something but I don't know the server well enough to know...

RP

[Richard Purdie]

> In the version I checked in, I initialize it to the currently playing
> song like this:
> Slim::Buttons::Common:aram($client
> ,'browseplaylistindex'
> ,Slim::Player::Source::currentSongIndex($client));

As browseplaylistindex isn't really needed in screensaver mode I wonder if
it would be easier to reword the if statement so it didn't use the variable
when the screensaver was active? This would solve all the problems...

The attached patch rp3.diff does this.

(and we may as well take out the bit of code added to ScreenSaver.pm as I
suspect it may cause trouble in the future)

RP

[Phil Barrett]

Attached is my first patch, which adds display of song lyrics.

Currently it only supports ALC format lyrics from two sources:
- Embedded ALC data as created by Visual MP3
(http://www.iprogramdev.com/vmp3/download.htm)
- An .alc file with the same basename as the .mp3 (or .flac or
whatever) - download files from http://www.iprogramdev.com/alc/

Other lyric file formats can be added if requested.

There is one known bug - if a lyric is long enough to trigger
scrolling, it will keep coming back long after it's been replaced by
later lyrics. It's no doubt due to the special-case playlist animation
code, and I don't want to delve too deeply into Display::Animation -
can anyone suggest a fix?

Also I guess a preference to turn off lyrics would be a good idea.

Phil

PS Any other problems, blame my stinking cold!

[Kevin Deane-Freeman]

Quoting Phil Barrett <philb (AT) philb (DOT) co.uk>:

> Attached is my first patch, which adds display of song lyrics.
>
> Currently it only supports ALC format lyrics from two sources:
> - Embedded ALC data as created by Visual MP3
> (http://www.iprogramdev.com/vmp3/download.htm)
> - An .alc file with the same basename as the .mp3 (or .flac or
> whatever) - download files from http://www.iprogramdev.com/alc/
>
> Other lyric file formats can be added if requested.
>
> There is one known bug - if a lyric is long enough to trigger
> scrolling, it will keep coming back long after it's been replaced by
> later lyrics. It's no doubt due to the special-case playlist animation
> code, and I don't want to delve too deeply into Display::Animation -
> can anyone suggest a fix?

off the top of my head, the bug is due to the amimation as you suspect. I
believe, once the amimation is started, the process continues on its own until
the scroll is completed. This means for long lyrics, it will keep runing for a
long time. the proper place to interrupt is during the pause. Otherwise, you
have to stop the animation timer cycle. Try using
Slim:isplay::Animation::killAnimation($client);

-kdf

[Phil Barrett]

On 3 Dec 2003, at 18:27, Kevin Deane-Freeman wrote:
> Quoting Phil Barrett <philb (AT) philb (DOT) co.uk>:
>> There is one known bug - if a lyric is long enough to trigger
>> scrolling, it will keep coming back long after it's been replaced by
>> later lyrics. It's no doubt due to the special-case playlist animation
>> code, and I don't want to delve too deeply into Display::Animation -
>> can anyone suggest a fix?
>
> off the top of my head, the bug is due to the amimation as you
> suspect. I
> believe, once the amimation is started, the process continues on its
> own until
> the scroll is completed. This means for long lyrics, it will keep
> runing for a
> long time. the proper place to interrupt is during the pause.
> Otherwise, you
> have to stop the animation timer cycle. Try using
> Slim:isplay::Animation::killAnimation($client);

Slight problem is that I store no state - the current lyric is looked
up each time the timer is updated. I tried using killAnimation whenever
I sent a non-scrolling lyric, but that didn't work, so I didn't explore
any further. What's odd is that the first scrolling lyric keeps coming
back throughout the song, even though line2 is replaced numerous times.

Phil

[Kevin Deane-Freeman]

Quoting Phil Barrett <philb (AT) philb (DOT) co.uk>:

> On 3 Dec 2003, at 18:27, Kevin Deane-Freeman wrote:
> > Quoting Phil Barrett <philb (AT) philb (DOT) co.uk>:
> >> There is one known bug - if a lyric is long enough to trigger
> >> scrolling, it will keep coming back long after it's been replaced by
> >> later lyrics. It's no doubt due to the special-case playlist animation
> >> code, and I don't want to delve too deeply into Display::Animation -
> >> can anyone suggest a fix?
> >
> > off the top of my head, the bug is due to the amimation as you
> > suspect. I
> > believe, once the amimation is started, the process continues on its
> > own until
> > the scroll is completed. This means for long lyrics, it will keep
> > runing for a
> > long time. the proper place to interrupt is during the pause.
> > Otherwise, you
> > have to stop the animation timer cycle. Try using
> > Slim:isplay::Animation::killAnimation($client);
>
> Slight problem is that I store no state - the current lyric is looked
> up each time the timer is updated. I tried using killAnimation whenever
> I sent a non-scrolling lyric, but that didn't work, so I didn't explore
> any further. What's odd is that the first scrolling lyric keeps coming
> back throughout the song, even though line2 is replaced numerous times.
>
The line is stored when you start an animation, so replacing the line doesn't
replace the animating information. You might want to try killAnimation
everything you put up a new line. I haven't had a chance to install your patch,
so I am going by the impression of what you are doing. I may have some time
later to try it out if that still isn't the trick.

-kdf