It just flashes off.

Adrian:  What appears to be happening is that a display frame is being sent to the player at the end of 
the client side animation.  And since the lines routine for the screensaver is blank a blank frame is sent. 
It seems unnecessary to send an update frame to the player at the end of the animation.  Is there a 
simple fix for this?

Dean: yes end animation causes a new render to see if scrolling is needed, so 
this could cause this.  The intention is to supress sending the new update 
frame as it is unchanged [see latest patch.]

I think the screensaver could block updates by setting updateMode to avoid 
this.  I'll look at a patch.

Dean - Unfortunately this is not as easy as I first though as the update mode 
is cleared during endAnimation to ensure that scrolling will start.

Two options:
1) modify screensaver to return the appropriate value for lines all the time
2) add a flag for pushLeft/Right to avoid the follow on update and render 
which could start scrolling [needs additional server code]

Do you have a view of the preferred option?

Option 1 is the cleanest, but please consider finding a way for the termination of a animation to not 
force an unnecessary update to the player.  (the animations should end with the current information on 
the screen and the traffic to the player is redundant.)  Is it possible to start the timer for the scrolling 
without sending a new frame to the client?

patch from triode applied.   this will need to get moved to SN too.

Just to clarify what this does for the bug record:
The patch Dean applied in r3352, causes the cached lines result from the 
previous render to be used during the check for whether scrolling is 
necessary.  This avoids this bug by meaning that the screensaver lines are not 
called.

In current 6.1 the outstanding issue is that an additional display frame is 
sent to the player at the time scrolling is checked.  This will be suppressed 
in future code (it is in my new code which merges graphics and text code.)

Dean - I assume we mark this as fixed?

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!