Sorry, meant to add Radio = r8121

Tested with 7.5.0 r8176.  This seems to only be a problem with the boom ir remote.  Other ir remotes such as the one that comes with classic are not a problem, however the speed that the volume reacts when holding down the volume button is very slow.

Not really a P1 but is annoying just the same.

Unfortunately the boom remote is what we're about to be selling with the accessory kit.  :(

These should all be the 'new' boom remotes, though, with full code repeat, not the special repeat code.

I wonder if this would be a good bug for Vahid?

Chris to verify that the ones in the accessory packs are the correct ones.  Felix will fix otherwise.

Just for the record: I do have one of the newer Boom remotes which send the correct continuous IR command when a button is held.

I did some investigation already in case the old Boom remote (using one shot) will be in the SB Radio accessory pack.

As far as I can see the issue is in the micro controller code handling IR. Attaching a scope to mcu pin 15 (interrupt line to main cpu) shows that interrupts stop after about 2 to 5 repeat commands.

I have verified that the remotes shipping in the accessory kit are the repeat-full-code variety not the send-special-repeat-code variety.

IMO there is no reason to fix this bug.

This issue is back, same as before, Volume sliding not working with Boom remote.
SB3 and Touch remotes function properly with Volume.

Radio r8445

Reported by: Seminole
http://forums.slimdevices.com/showthread.php?t=75735

There is a very good reason to fix this bug I will have both remotes and they look the same.I own a boom too.

Same remote capabilities as any other squeezebox is the way to go, all remotes completely interchangeable. all else is wrong.

(FYI the "jvc remote" code does not work with radio, so the popular use of universal remotes is a bit limited too.)

This bug is occuring with the remote I received with the battery pack for the Radio on march 10, 2010. So it is a problem with the Radio remote.

Marc

Maurice, I will come by to talk to you about this issue.

The remote I received in the Radio accessory pack also behaves the same. Both my Boom and Radio remotes require repeated presses to change the volume on the Radio (but not on the Boom).

Another user reports that he cannot seek (fast forward/rewind) within a song with his remote, but only skip to the next/revious playlist item.

http://forums.slimdevices.com/showthread.php?t=76090

I think this is the same problem, the Radio being unable to distinguish how long a remote button is pressed.

The mechanism that triggers every second to reset under one condition the state machine of the ir_sensor seems to be a little bit too zealous.
The code repeat works fine as soon as the mechanism is disabled but i still don't understand why the condition is true when the mechanism gets triggered... under study.

I just talked to Maurice about this issue.  Just to reiterate/clarify his last comment:

There is a mechanism in the microcontroller code that resets the IR state machine (plus does some other functions, like monitor battery charging) every second.

By disabling the part of the mechanism that deals with the IR state machine, he has been able to make the repeat-code work correctly.

However, it is not clear to Maurice why that code was put in there (obviously not to intentionally break the repeat-code functionality), and he is concerned that there are other issues which might be affected, or might be affecting this code.

In particular, he remembers Caleb mentioning that while changing the compile options, there was an optimization level where there was some strange behavior but Caleb never learned why.  Maurice is worried that compiler-related problems might be involved in ways he doesn't yet grasp.

So then, it seems like Maurice has a 'fix' but would like someone to review the situation and see if they can understand better what is going on with this section of code before we implement the fix.

Alan or Felix, would one of you like to take this on?

Function 'void ir_sensor_tick(void)' in 'ir_sensor.c' seems to be called every second and if it is called twice without 'ir_sensor_ticks' being reset by the ir state machine it kills the ir repeating.

When I looked at the interrupts from the mcu to cpu I saw that sometimes I got maybe two interrupts and sometimes up to five before it would stop. This suggests a race condition / timing issue between the interval the repeat codes are coming in from the remote vs. the 1 second 'ir_sensor_tick(void)' call.

However I cannot see how the 1 second check could be called twice without 'ir_sensor_ticks' being reset to 0 in between as ir repeat codes should come in much more frequently.

Could it be that the rtc interrupt function calling 'ir_sensor_tick()' can be delayed and then fires twice within a much shorter time than one second?

Maybe it can get delayed when other functions the rtc interrupt function is supposed to call take longer than expected sometimes?

I am wondering if the compiler optimizes too much some code and doesn't know that 'void ir_sensor_tick(void)' is called by the 1 second interrupt through a pointer.

Maurice, what do your mean by "doesn't know"? While I cannot rule out a compiler error, it has to be quite unlikely.

The problem is that ir_init() can get called multiple times and this will register its 1s callback (ir_sensor_tick()) multiple times. Thus it will fire twice (there are not enough RTC callback slots for it to get registered more than twice) on each 1s tick and thereby reset the repeat_allowed flag.

 == Auto-comment from SVN commit #6687 to the player repo by ayoung ==
 == https://svn.slimdevices.com/player?view=revision&revision=6687 ==

Bug 15199: Radio IR Remote problems are back with Volume
Prevent multiple registrations of the same callback function in rtc_register_callback()

Update housr

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

bug 15199: Radio IR Remote problems are back with Volume 
Update MCU firmware

This is not "resolved fixed" .

I now have the the remote at home and can test it.

I can also confirm that the Radio remote and Boom remote are identical.
The numbers on the stickers is exactly the same.
So at the consumer end there is not two different remotes.

And they function the same,none of them can control the volume on my Radio, other than in small increments as descibed i this bug.

My SB3 remote works fine with the Radio.

What is more worrying is that none of them can control the volume on my boom ?
I get the same symptoms ? I can chnge volume in increments of one.

Should I open a separate bug for the boom volume issue ?

Mikael - Thank you for the update. This bug is targeted for 7.5.0 and the fix will be available in 7.5.0 SB Radio firmware.

And yes, if you really see similar issues with the same remote and SB Boom, please open a separate bug.

Thanks
Felix

Is the related firmware to be released in the 7.5.0 nightly (i.e., tonight)?  I am currently running 7.4.3.

I peeled of the cover completely on my remotes:

On my old Boom remote circuit board I have "BOOM PA31 2008-06-18"
On my new Radio remote circuit board I have "BOOM PA2 2008-03-24" 

I reported the similar bug on the Boom

https://bugs-archive.lyrion.org/show_bug.cgi?id=15918

can someone confirm ?

Alan, I tested this with the 7.4.1 Radio firmware (7915) and it also has the problem, where the 'repeat' code is not recognized.  I.e. it does not appear to be a regression, at least between then and now.

With regards to this issue with Boom, could I trouble you to file a separate bug?  They way the devices handle this issue is totally different.  Thanks!

Thanks for testing 7.4.1


It looks like the Boom issue is already filed as bug 15918. If that is not it then I do not know what it is.

Why did v7.5.0 push firmware v. 8660 for the Controller, but not for the Radio?  I am anxious to see the remote work correctly!

Radio firmware needs extra (manual) QA before being released because there is no easy way to recover from bad firmware on that product. New builds are pushed automatically for Touch and Controller which both have SD-card slots so, in an emergency, these can be used to recover the device in the case of bad firmware being loaded.

This bug has been marked fixed in a released version of Squeezebox Server or the accompanying firmware or mysqueezebox.com release.

If you are still seeing this issue, please let us know!