It should be doing this already, as long as the line are actually displayed
longer than the ScrollPause setting.  CLI lines are simply sent to
$client->showBriefly same as any other short display, as if it were commanded by
the server itself. The default pause is 3.6 seconds, default message display is
only 1 second. Due to a fixed lag in animation setup time, even a scrollpause of
zero may not scroll a 1 second message.

I am running SlimServer 5.3.0 and it doesn't scroll for me... never has.  I am
using the default scrollpause (3.6) and scrollrate (1.5) settings and in this
case an specifying that the text be shown for 30 seconds.

I'll have to leave this for Dean.  I sent a cli display command and it scrolls
just as it should for me.

my test:
00%3A04%3A20%3A05%3A32%3Ae2 display hello
adjdjdlkjslkdjfjghslskdfjshglsdfla;sdlfahgjasdfjfjdhgsdjfjsdgshdgsd 30

this is with latest cvs and non-G display.
1.5 is a very slow scrollrate, btw.  default is 0.15.

I tested with the non-G display using Softsqueeze and the scrolling *does* work.
 But when I switch to the G display in Softsqueeze the text no longer scrolls. 
My squeezebox has a G display behaves the same.. no scrolling.

Also I meant to type 0.15 for the scroll rate, not 1.5. :)

aha. it seems ANY showBriefly will not scroll with a G display.

Created attachment 150 [details]
save and restore oldlines while doing showBriefly

this patch allows the lines to be set as the current lines during showbriefly. 
This allows scrollBottom to do its job, then teh old function is returned after
the showBriefly duration.

marking this as a bug, since it shoudl have been working already.

Created attachment 164 [details]
updated for one bug

the previous patch had a problem when volume control was pressed and held. 
This new patch will only swap line functions when the duration is specified as
longer than 1 second.  No duration given or duration=1 will use the old simpler
routine.

The latest patch works great!

*** Bug 617 has been marked as a duplicate of this bug. ***

if there are no objections, I plan to commit this tonight based on user
confirmation that this works ok.

I'm a little worried about this patch.  I'd rather not modify the lines parameter.  Shouldn't we be able to 
do this by having showBriefly call scrollBottom?

Never mind my last comment, I see that scrollBottom and scrollUpdate just call the $client->lines() 
function.  Couple of comments on the patch.  This line:

+       if ($duration > 1) {

Should be tested against the start scroll delay, not a fixed value of 1, right?
Also, I think that at least one place, killAnimation, needs to kill the timer for showDone, right?

the duration > 1 test is for the showBriefly timing, not for scrolling.  if the
duration is default (ie 1) then we dont need a timer, since that ends up making
the showbriefly more than 1 second.  its more efficient to use the old method. 
for anything over 1s, we set a timer to come back alter and swap the lines
functions back to normal.  The action of scrollbottom is simply its usual
function of moving any line after some preset time.

the point about killing showDone is a very good question.  I'll check on that,
as I'm not sure either way. I guess if we do happen to call killAnimation to
interrupt the display for something else, showDone should be killed as well.

Created attachment 179 [details]
kill showDone in killAnimation

updated to kill showDone so new animation/lines can override if they need to.

ok, cool.  

sorry to be a pain about the 1 second rule, but there's nothing magic about that number.  Let's say that 
the user sets the scroll pause to 1/2 second. Then they do a showbriefly for 1 second.  In theory, they 
should see a half second of scrolling, no?  It's a minor thing, but if the user sets the pause to, say 5 
seconds and then showbriefly is called with a 4 second time, then the old optimized code should kick 
in, right?

Apart from that, go for it!  Thanks!

can't kill showDone timer after all or you get locked in the showBriefly. 
Probably have to kill the timer and call showDone immediately.

I may be able to eliminate the need for a special 1s timer by only setting the
timer when one doesnt already exist.  This way, we dont have overlapping
'stored' linefunc's to worry about.  What I would like to do as well is have it
extend the timer if a new showbriefly is called before the timer fires.  This
way the timer keeps the proper linefunc, but always updates to the latest
duration used.  subsequent and overlapping ShowBriefly calls will then simply
override one another and return back to the original display.

This would need a new timer function, similar to adjustAllTimers

Created attachment 180 [details]
update showDone timer each time sshowBriefly is called.

This method gets rid of the need for a >1s test.  We can't kill showDone as a
timer via killAnimation becuase scrollBottom calls killAnimation.  We end up
stuck in the brief message.  This version updates the timer for ShowDone based
on teh most recent $duration given.  There is currently no case to kill the
showBriefly becuase generally those messages override all else.  If someone can
point out a case where we want to override it, I might be better able to find a
place to kill the timer.

Can't you just use killTimer and then set a new one?

sure, but I just discovered it doesn't work anyway.  Not having the 1s test now
breaks when block mode is used. sadly, the more this goes on, the more it looks
like showBriefly has to completely replicate all the animation on its own.  very
disappointing. The timer is a great way to handle long durations, but not so
good for very short ones.  I'll have to keep looking it over.

no, can't use kill because we need to keep the original oldines in order to
return to the right place.  the example is the volume control where we are
rapidly repeating the showbriefly for the volume bar.  killing the timer means
we trap the volume bar as oldlines intead of whatever mode we're in.  

Idea: Let's make showBriefly push the player (without animation) into a mode that only displays the 
specified text.  then set a timer to pop it out of the mode.  Also, any IR input would pop it out of the 
mode.  the only trick is to get it to not lose the IR event once popped out.  Want to take a crack at this?

i gave it a shot but I dont think that will work either as teh modes are
sometimes being switched during a showbriefly.  For instance, when doing a
search.  as the search starts, showBriefly is called, then we pushmode to
browseid3. with the new idea, we've pushed into showbrielfy, the pushed into
browseid3.  I can avoid the pop if we've moved on, but then popping will go back
through showbriefly.

Created attachment 183 [details]
showbriefly as a mode

here is the patch I've tried.  on power up, the welcome display shows after
first button press as well, becuase of the problem mentioned in the last post. 
You can also see it come into play when searching or any other case where
showBriefly is called just before a mode change. One solution would be to move
them all after the mode change, but then we'd need to rewrite the the older
style showBriefly.

Created attachment 184 [details]
much better now

now I'm sure I'm ill.  this version checks for the method and pops out of
showbriefly if we've poped into that mode.  not quite able ot get all the
buttons to pass back, however

Created attachment 186 [details]
this is it.

ok, i realised the last patch had a bad diff for Default.map.  This one fixes
that and handles the passback.	This should cover most functions but more can
be added if I've missed any.  Some work directly without needing a passback.

One issue that I see coming up by making showBriefly its own mode is related to
modes that use the INPUT.* packages for display. Many of these modes have
patterns similar to:

	if ($method eq 'pop') {
		Slim::Buttons::Common::popMode($client);
	}

in their setMode() method. If any of these modes use showBriefly() with the new
patch, they will do an extra popMode() on return. This is also an issue for
Slim::Buttons::Block.

well, that bit was added specifically because of block mode, since every case
pushes into block after showbriefly, we need to also pop out of showbriefly
after unblock or the showbriefly message comes up again. (the reason I added
this was because the "free your music" message would show up after you press a
button at power-up.  Thus, we actually want the double pop.  When a mode pushes
straight into an INPUT.* mode, we pop back out of INPUT.* into, say 'settings'
mode, we need to pop again out of settings into 'home'. the modes that push into
INPUT dont have any activity in their mode any more, so a showbriefly should
never get in the way of that. The patch does seem to now work well with the
startup message, volume control and the search modes (which use INPUT.* and
block). If you do find anywhere that it doesn't work, then I can probably find a
way around it. That is how we've ended up here.  startup, search, and volume
control leave little room for messing about with blocking and short messages. 
However, something does need to change because the current code will sometimes
lose a message entirely, wont do long durations properly and wont scroll. It
also wont do messages shorter than 1s, except by virtue of being cut short by
the standard $client->update cycle every 1s.

if we want to play safe, we can still have an if ($duration < 1) clause which
reverts to the old routine.  This results in a volume display that still
flickers, but leaves the short messages working as they do now and allows CLI
long message to linger and scroll properly when they are required. The server
itself only ever does a message over 1s for the alarm clock.

ok, so maybe my idea to put showbriefly in its own mode was a bad one...

I'm not sure I see the problem yet, at least not in any concrete way that
affects how I use the player.  I've had this patch on my system for a few days
now.  One subtle effect shows in the volume control where it does seem to have
an slightly uneven pace.  I've considered this a fair trade for the former case
which caused some flicker back to the old lines every so often when you held
down the volume control.  

I'm speaking from the perspective of a plugin writer who has used both
showBriefly and block from my own menu mode, sometimes *before* pushing into a
INPUT.* mode. For example, the Slim Devices Picks plugin goes into block mode
while loading a remote playlist. Once the loading is done, it pushes into
INPUT.List. Without maintaining some state, I'm unable to detect the difference
between popping out of block mode and popping out of INPUT.List. The latter
should result in a double pop, the former shouldn't. For the same reason, I will
definitely have to modify some plugins to deal with showBriefly() becoming a
mode. Or am I missing something?

Excellent point.  showBriefly and the block() mode are similar in that they both want to put up a kind of 
dialog box on the screen while something happens.  both are broken in subtle ways.  I like the idea of 
using modes, but there clearly needs to be some code that does something smart for each when 
pushing and popping other modes....

this seems to be stuck as an architectural issue, so I have no direction for
continuing on this.

Will look at this.

*** Bug 1245 has been marked as a duplicate of this bug. ***

Assuming people agree this is fixed by the new display code, I would suggest 
this is closed...  [or did I miss something in this?  I'm interpreting the 
root problem as lack of scrolling for graphical showBriefly]

sorry, yes, i did check this and it seemed to work for me.  Marking as fixed. 
it can be re-opened if an issue is discovered.

This bug was marked resolved in Slimserver 6.1, which is several versions ago.  If you're still seeing this bug, please re-open it.  Thanks!