I can't reproduce this.  Kevin: any more ideas? 

The same thing happes with the spectrum analyser screensaver on version 13.

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

Since the visualizer comes back after kicking the display, my suspicion is that
this is a server-side problem, not a firmware issue. The question is what could
cause the server to turn off the visualizer mid-play?

Paul Runyan wrote:
It happens when I'm playing audio files from my local SlimServer (which are 
Apple Lossless), in fact it is happening right now.  I believe I've also had 
the problem when connecting to internet radio through my local SlimServer, but 
I am not absolutely certain.

Once it goes blank, it stays blank (with the exception of the periodic 
scrolling "no playing" text) until I manually kick the display by using the 
remote to bring up the menu, "No Playing" or anything else.  This seems to 
reset it.

If there is any sort of action I can take to collect useful diagnostics when 
this happens please let me know.

Triode:  Any idea why we might be sending a turn-off-visualizer message to the player?
Paul: Can you confirm that you are running 6.1 beta 2 and it's still happening?

Created attachment 623 [details]
Patch to send visu even if duplicat screen update is suppressed

Interesting, Triode.  What's the theory behind this fix?  

[If only I could operate bugzilla properly - this would be part of the 
previous attachement!  Just had to type it in again.]

Having just reviewed the code, there is a case where a mode could turn off the 
visualiser by setting the 'visu' param to [0], doing a update and then turning 
it back on again.  The display code will suppress a new update including 
visualiser frames if the render result is the same as the previous one.  So 
conceptually there is a case where the visualiser is stuck in the 'off' state.

Patch above should resolve this.  However I am not convinced it is the cause 
of this problem.  Do we have any clear ways of reproducing this?

Dean - Other thing I notice is that the lines for the screensaver function 
doesn't return anything [presumably this means it returns true from the if 
statement? My perl is not upto this!].  I am not sure what parseLines makes of 
this, but would suggest returning an empty parts hash?

Right, the mode has no content to display, except the periodic track transition stuff.  I wonder if there's 
a display update being triggered where the visualizer isn't being set properly.  Is that what your patch 
addresses?

Having looked at this again I don't think the problem I addressed with the 
patch is likely to occur.  I've also verified that parseLines works fine with 
no return from the lines function - it sets all components to ''.

The patch was intended to cover the case where something like the volume 
control turns off the visualiser, calls update then turns on the visualiser 
and calls update again again.  If the thing it displays the second time is the 
same as the first both the display and visualiser frames would be suppressed.  
However the next time update or a push/bump is called, the correct visualiser 
mode would be involked - so not really a problem.  Also I can't see any cases 
where the two screens would be the same.

In the case raised, this is not happening and indeed _pushon _pushoff seem to 
be still working.  The server code should be checking the visualiser mode for 
each screen update and sending a visu frame *if* the paramref in 
Squeezebox2::visualizer() has changed.  [this is an attempt to suppress 
repeated visu frames.]

If line line:
 return if (defined($paramsref) && ($paramsref == $client->lastVisMode())); 

in visualizer() is commented out does it still occur?  If so could it be that 
the player is loosing state?  [I assume that there are no cases where 
paramsref would be the same, but the mode would be different as all parameters 
are in static arrays?]

I'm using SlimServer 6.1b1.  I can update to beta 2. 

When I get the chance I'll comment out the line Triode suggested and let you 
know if the problem persists.  
  

Thanks, we really need a reproducible case here.

I think it is the firmware...

I've managed to reproduce this twice now.  In both cases I set a playlist 
going on repeat and selected the spectrum analyser screensaver.  When it 
failed music is still playing, the periodic scrolling text is still seen, but 
otherwise the display is blank.

The first time it took 3 hours to get to this state.  I then added some 
debugging to log the visu frames sent to the player.  This time it took over 
48 hours to get into the problem state.  During this time, no visu frames were 
sent to the player.  Clearly the server is sending display updates for the 
pushes, but with the suppression of duplicate visu frames means none are sent.

Hence I think the firmware manages to loose state for some reason.  Clearly we 
could remove the visu frame suppression, but this would only help kick the 
firmware in the cases where text is displayed periodically.

Is there any debugging I can do for you on the player while it is in this 
state?  

[I'm running r3660 with the latest v14 firmware from this]

The last visu frame sent to the player in my case had the following params 
(Data::Dumper of params)
2005-07-11 00:30:24.7230 Sending Visu frame
$VAR1 = 0;
$VAR2 = 0;
$VAR3 = 65536;
$VAR4 = 0;
$VAR5 = 160;
$VAR6 = 0;
$VAR7 = 4;
$VAR8 = 1;
$VAR9 = 1;
$VAR10 = 1;
$VAR11 = 3;
$VAR12 = 160;
$VAR13 = 160;
$VAR14 = 1;
$VAR15 = 4;
$VAR16 = 1;
$VAR17 = 1;
$VAR18 = 1;
$VAR19 = 3;

It failed sometime between last night and when I got home this evening 2005-07-
13

Vidur: any thoughts on this?

I've seen this a few times but unfortunately I don't really have anything to
add.  I usually leave this player on my desk playing all night, and have been
using the analog vu meter as the screensaver lately.  Every other morning or so
I'll come in and the screen will be blank...

What could I do to help here?

Well...the only thing that shuts off visualizers in the firmware state machine
(other than a 'visu' frame from the server) is going into setup. This could
happen if the connection to the server is temporarily lost. Since we now try to
do a seamless reconnect, the audio would keep on playing. I would assume that
the server sends a 'visu' frame on a reconnect, but maybe I'm wrong? Does this
theory work with what anyone else is seeing?

We may be getting somewhere - I don't think you will get a visu frame on 
reconnect as it will call update with the current lines function which means 
that the visu frame will be suppressed.  

I'll try reproducing by killing the server connection.

Ok - with simple case of killing the network, no visu frames are currently 
sent on reconnect.  I haven't been able to reproduce just killing the 
slimproto session.

As this is clearly not compatible with the firmware I will commit a fix that 
forces a visu frame to be sent on reconnect.

Kevin (and others) could you try r3691.  If you find a way to kill just the 
slimproto session this may reproduce the bug and demonstrate this fixes it...  
It definately ensures the visu mode is updated on reconnect which did not 
happen before.

Marking this bug as fixed. Please reopen if you have a case that isn't addressed
by Triode's fixes.

Yes, I haven't been able to reproduce this problem since I updated shortly 
after the last message.  Thanks Triode and Vidur.

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!