This is due to there being no repeat codes from the boom front panel buttons.

We could simulate these evens in the server by generating .repeat on a timer, but this probably leaves it open to missing an up code and not cancelling the timer as it is hard state.  What do you think?

Thinking about this - I think it would be safer if the firmware created repeat codes for these rather than emulating this in the server and creating the possibility that we miss the up code and so continue creating repeats for ever..

Felix - would this be easy for fwd/rew?  I'm not sure it is necessary for other buttons?  I assume you keep sending .down codes without sending an intermediate .up as done for vol*_front.

My own feeling is that if repeat is not supported in firmware, then nothing needs to be done except document the difference so that users are aware it is a hardware restriction.  

I reckon emulating repeat in software will not be 100% successful and so may be storing up problems for the future.  

Andy thinks this is an SC bug, but I don't think he has looked at it like you did, Triode :).

Alan as always if you don't have time for this one, let me know and I'll get Dean to reassign it.  :)

Its an architectural decision - not a bug...

At present front panel buttons send an a down and an up code, but unlike the IR remotes they don't continuously send codes when they are pressed.  The exception to this is the boom volup_front voldown_front buttons.

Now we can emulate repeat in the server for either all buttons, or just in song scanner (though this is hard as song scanner won't see the original key press unless we do something special).  However this assumes we run a timer in SC which keeps repeating until we see the button up code and is therefore susceptable to missing this code and continuing to repeat.

Safest option for me is to extend the boom volume mechanism of having the firmware generate repeats - in which case the server needs no changes.

What about Transporter's front panel?  Does it work the same way?

Triode is absolutely right. I already forgot that I only implemented repeat functionality in firmware for the volume buttons. Let me know if I should extend that for fwd and rev buttons too.

I'm tempted to say that we should do it for all front panel buttons on boom and transporter - this will allow the server to generate *.repeat events for all of them as if they are IR buttons.

The only use case at preset is this, but the front panel and ir work differently at present...

Felix is this your bug now?

I've enabled repeating for fwd and rew so you can see if it works as expected. I have not looked into the SC side of this.

I did not enable repeating for all buttons at this time since it breaks 'stop' functionality when holding pause.

The change is in rev 4685 and will be in fw 23.

Felix:  Will you be looking into the SC side of this or should this get reassigned?  (I can confirm that with the current boom branch and fw23 it doesn't work).

Felix - yes the server code will need a tweek if you enable it for all buttons, but I think this is the right thing to do for the longer term.

For the moment I can make this work with fw23 in song scanner - is this the best option?

SC change 22430 adds support for .repeat events from the front panel and should enable this work work.

This is a more significant change than I proposed above as the old ir code would not generate .hold events when a stream of .down codes were sent (needed to switch into song scanner).  Please make sure other use of the front panel is tested...

Felix - with this code, you should be able to send repeat codes for other buttons such as stop as it should not mask the .hold event.  I suggest this is added at some point in the future.

Triode: I've tried to add it for all buttons, but in case of the pause / stop button it does not quite work yet. Pressing and holding pause does stop the music _but_ upon release of the pause button the music resumes.

could you send me a firmware image which does this?

is this worth fixing for 7.2 though?

I don't think it is worth fixing for 7.2 as the buttons that currently need repeating (fwd/rew and volume up/down) work as they should.

I can certainly send you a fw doing this, but I was wondering if you could just remap let's say fwd button simulating it is pause to see the effect. Let me know if that would work for you or if you prefer a fw doing the repeat for all buttons?

good idea - I'll try with the remapped buttons.

My main reason for fixing is to make the front panel work like IR buttons so that everyone's plugins work.  It sounds like we create one more event at present - I'll look at how easy it is to fix this.

Created attachment 3761 [details]
generate hold_release correctly for front panel

We are currently generating .single events at the end of a hold period rather than hold_release.  This should fix it.

I think this should go in 7.2 - any views?

OK by me.

patch committed as change 22480.  You should be able to make all buttons repeat now Felix.

change 22499 fixes the issue seen by Bryan on the forums - jumping caused by acceleration kicking in for the first event and using the time since a button was previously pressed...

Enabled repeat for all front panel buttons on Boom. (rev 4715)

Added repeat for all front panel buttons on TR. (rev 4716)

Will be in Boom fw 27 and TR fw 60.

Press and hold power, now playing, search, browse, or size on Transporter front panel and you'll see the repeat isn't quite right. 

Ross what's the symptoms of the problem?

Felix - I noticed once with TP that I got a .up with the same timecode as the preceeding .down  The server discards the second code if it has a repeat timestamp - could you check in the player that you don't generate ir codes with the same timestamp?

[I don't know why the server does this check - perhaps Dean can comment]

Also given the discussion on rate limiting the knob, do we want to slow down the repeat rate from the front panel - we are currently repeating ~3 times as fast as the IR remote does - one update every 30ms?  This is likely to create the same problems seen my Matt on his slow server...

(In reply to comment #24)
> Ross what's the symptoms of the problem?

Sorry, holding power turns the Transporter on and off very rapidly. Holding size toggles the font size very rapidly, etc. 

And boom is different for the cases where the same buttons exist, for fw 27?  (I don't have this yet!)

Yes, very sorry to not be clear. Steven tried this with Boom fw27 and it is not an issue. 

Triode: Every button event (up/down) sent to SC is using the same function which uses timer_get_ticks() as timestamp. I don't see how a down and up event could have ended up with the same time.

I see the same behavior on both Boom and Transporter. When pressing and holding let's say 'back' while connected and on and in the top menu I see a animated bump and after a short while another.

I don't see the rapidly turning on and off when pressing and holding power though. After a while I see the normal rebooting.

Is there anything I am missing here? I've tested with TR fw 61.

The rapid action described by Ross was using an older version of SqueezeCenter.

Sounds like the main issue is not a problem.

Felix - I only saw it once - specifically the debug line said it was dropping the .up code.  It stuck out as there is a typo on the debug message "ignoringo"
Lets keep an eye out for it if people see any problems.

Works in 7.2 - 22623. 

Sorry, still seeing this but it's not rapid any more. Pardon me!

So can you confirm again the difference between boom and transporter and which buttons you see a problem with.  Its not clear from this report where the problem is.

Front panel buttons that double-press during hold, for Boom:

Power, back, and play. 

Transporter:

Power, now playing, search, browse, size, back, volume, visual. 

ok - this is a server problem - will look at it

I think this is fixed in server change 22669.

Felix - I've removed a safety check on repeat which didn't classify a it as a repeat if the irtimestamp was > 0.5 sec.  However the firmware appeared to wait 0.5 sec for the first repeat - can you confirm this is the case.  I think it is safe without this check as the previous button press should normally be a up from another button, but just wanted to understand the timers in the firmware.

Triode: I can confirm that firmware waits for 500ms for the first repeat.

Ok - that explains the issue.  I think it is safe to leave without an extra check in the server so will close this and ask Ross to retest.

Verified to be fixed in 7.2 - 22900

This bug has been fixed in the latest release of SqueezeCenter!

Please download the new version from http://www.slimdevices.com/su_downloads.html if you haven't already.  

If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look.