Bugzilla – Bug 1154
Duration not being respected by Slimp3 in 'display' command
Last modified: 2009-09-08 09:18:07 UTC
Performing a command like: ...?p0=display&p1=1&p2=2&p3=5000 Currently works fine on a squeezebox and used to work fine on Slimp3s. The duration is set to 5 seconds and on a Slimp3 the message is almost immediately overwritten by datetime or whatever is on the screen. Again, this worked fine pre 6.0.x.
confirmed, still happening.
This will have to wait until 6.1 when we restructure the screen updating code.
Adrian: Is this addressed with your reworking of the display code?
I believe this is fixed in the current 6.1 trunk as it depends on showBriefly which should be working on a character display in 6.1. (Volume control display etc works properly now) Michael - does this work for you?
This is a definite improvement. It is close to being back to the way it was. I haven't had a chance to test all of it yet but it does seem to blank out after about 5 seconds even if I give a longer timeout parameter. Still, it is much better than it was before.
I've looked at the code again. The new version will display the text for as long as you specify. However this will be interrupted if another display update is attempted by the server. This could occur e.g. if a screensaver kicks in. The display function that is involked has the capability of blocking all updates for the period it is being displayed for. However at present this is not exposed via the web or cli interface. If this is useful it could be exposed as it should be trivial..
I think that the behavior of allowing a new display message to override the old makes total sense. It seems that screensavers should back off until the message timer is finished though.
Agreed - screensaver should not kick in if animations including displaying text via "showBriefly" are in progress. I'll add this to a code update I am working on. Lets leave this open until then.
fix committed by triode at change 3463 I can confirm fix, re-open if still a problem elsewhere after Jun 21 build of 6.1
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!