Tom: did local player control (for Radio) have any effect that may cause this on jive?

 == Auto-comment from SVN commit #7675 to the jive repo by tom ==
 == https://svn.slimdevices.com/jive?view=revision&revision=7675 ==

Fixed Bug: 14162
- increase accel curve to be more like 7.3 behavior
- math.floor should apply to abs value rather, so neg vol and pos vol acceleration works the same.
- on the down, always go by one
- a quick tap will only go by one

with 7.4.0 r7728 still the same. maybe it is not as bad and apears after some time of use.

This might be an issue on laggy networks/ low powered SC's.  A theory is that the new makeup volume (which ignores the rate limiting) might be clogging the request stream.

Sorry but you are wrong.

- I have a powerfull SC CP (4GB RAM, DualCore AMD Athlon)
- Never had problems with Network.
- Never had problems with volume

This was introduced last week. If volume up/down doesn't work on the Now Playing screen and in the main menu screen it works this is really a software not network issue.

The problem is never present after the update of firmware, it starts after using it some time. Maybe also the controller was asleep.

Christian

Right, Schindler, as you said, very unlikely to be a network issue. Unfortunately we haven't been able to reproduce it trying the various suggestions and other techniques in time for the 7.4.0 release... 

On the bright side, the 7.4.1 release will come out very shortly after 7.4.0, but we still have to be able to reproduce the or get log data showing the problem in progress.

In a bit I'll post to this bug some details of setting up more verbose logging that might be able to reveal the problem.

I think by turning on net.comet and squeezeplay.player log categories to debug level we might get a clue.

Thanks Tom

So I should turn net.comet and squeezeplay.player log on? Or do you do that?

Christian

(In reply to comment #7)
> Thanks Tom
> 
> So I should turn net.comet and squeezeplay.player log on? Or do you do that?
> 
> Christian
Sorry, I was unavailable for a while...

You can add additional logging relevant to your problem with the following. Note: you'll want to make sure to remove/rename this file when you are done since your device will be slightly slower while it is in place:

Create /etc/squeezeplay/settings/logconf.lua with vi or by scp

Put the following in it:

return { appender={ stdout="none", syslog="debug" }, category={ ["applet.NowPlaying"]="DEBUG" , ["squeezebox.player"]="DEBUG" } }

then restart. After restart the /var/log/messages will contain player and nowplaying debug. Once you replicate the issue, scp the /var/log/messages file locally, or via ssh do a cat /var/log/messages

Assigning to QA to reproduce.  There is also detail on a forum thread:
http://forums.slimdevices.com/showthread.php?p=462167#post462167

It appears that at least two users are experiencing this problem, but I have been unable to repro it trying several different times/techniques.

I may have seen similar.  In my case, it occurs when wireless strength is marginal, and there are are lost frames.  Moving the unit closer to the AP (even by a foot or two), increasing the signal strength, makes the issue go away.  It is very repeatable here if this is the same issue the OP and others have reported..

I'm now seeing this with the scanner (fwd/rew) as well.  If I engage the scanner and then hold the fwd or rew button, the position moves much too slowly if Now Playing is under the scanner.  If the playlist is under the scanner, it works correctly.

I see the same thing with cover art or the default cover.

When scanning over now playing, top has jive at above 90%.  Above playlist, its 30%.  These numbers do vary a lot.

Jive is 35meg virtual.

A reboot makes this go away!  After reboot, jive vm is 28meg.  Jive runs 40% or so, again with lots of variation.

Something is clearly amiss.  One crazy question - does the lua implementation have a garbage collector?  If so, could it be getting into trouble?

Anything else to check?

lua does use garbage collection, but it's still possible for a bug to be in place where stale references are being held. 

How long does it take for the problem to resurface?

(In reply to comment #8)

> Create /etc/squeezeplay/settings/logconf.lua with vi or by scp
> 
> Put the following in it:
> 
> return { appender={ stdout="none", syslog="debug" }, category={
> ["applet.NowPlaying"]="DEBUG" , ["squeezebox.player"]="DEBUG" } }
> 
> then restart. After restart the /var/log/messages will contain player and
> nowplaying debug. Once you replicate the issue, scp the /var/log/messages file
> locally, or via ssh do a cat /var/log/messages

I tried this and when i look at the logging settings applet.nowplaying and squeezebox.player are still set to info.

Are you sure this shouldn't go on /etc/squeezeplay/userpath/settings ?

Also - there is a logconf.lua in /etc/squeezebox/userpath.

What does work is to replace /etc/squeezebox/userpath/logconf.lua with your version.

(In reply to comment #13)
> (In reply to comment #8)
> 
> > Create /etc/squeezeplay/settings/logconf.lua with vi or by scp
> > 
> > Put the following in it:
> > 
> > return { appender={ stdout="none", syslog="debug" }, category={
> > ["applet.NowPlaying"]="DEBUG" , ["squeezebox.player"]="DEBUG" } }
> > 
> > then restart. After restart the /var/log/messages will contain player and
> > nowplaying debug. Once you replicate the issue, scp the /var/log/messages file
> > locally, or via ssh do a cat /var/log/messages
> 
> I tried this and when i look at the logging settings applet.nowplaying and
> squeezebox.player are still set to info.
> 
> Are you sure this shouldn't go on /etc/squeezeplay/userpath/settings ?

Yes, you are right: /etc/squeezeplay/userpath/settings

If you already see the logging option, this suggests that you have an SD card in with a log dir (which also triggers that menu to appear). In that case, you can also just use the UI to switch those to debug...

QA is unable to reproduce this with 7.4.0 r7790

I have been able to reproduce this by leaving my controller playing for several hours. I should be able to track and fix the problem now.  I expect a fix by 7.4.1.

 == Auto-comment from SVN commit #7821 to the jive repo by tom ==
 == https://svn.slimdevices.com/jive?view=revision&revision=7821 ==

Fixed Bug: 14162
Description:
New progress group widgets were being added on every track change but not cleared, in a bogus swap out situation.  Now that we hold onto the np window rather than replacing it, this leak eventually caused heavy cpu load.

Note: This also fixed the issue that remote streams shouldn't show the progress dialog graphic, but did.

Fix is to correctly swap the two progress bars.

Also, moved the _updatePosition timers being used on each of the progress groups and the progress slider groupto a window timer, to avoid double calls to updatePosition()

 == Auto-comment from SVN commit #7822 to the jive repo by tom ==
 == https://svn.slimdevices.com/jive?view=revision&revision=7822 ==

Fixed Bug: 14162
Description:
some fields weren't begin initialized on reset

Ignore comment #20, was for another bug...

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

Everyone having this issue, please retest with SBS 7.4.1 r28825 // SP r7847.

I have been using this version for a few hours now, and can not replicate the issue.  Report back in this bug if you see improvement or still experience the issue.