Bugzilla – Bug 9611
IR Blaster goes into endless IR emission loop
Last modified: 2010-02-08 06:40:08 UTC
I am using a Squeezebox3 with the IR Blaster plugin and an IR Emitter connected to the earphone jack and the "IR Repeater" enabled. After several hours of use the Squeezebox3 regularly goes into some kind of endless IR emission loop. I.e. the IR emitter is constantly emitting a signal (which can be heard as a constant sound by plugging in headphones into the earphone jack). With this constant signal, the IR Blaster/Repeater can no longer be used. The signal can only be stopped by unplugging the power of the Squeezebox. Restarting the SqueezeCenter does not help. Interestingly, when turning the Squeezebox off with the remote the sound from on the earphone jack changes a bit (but still goes on). I suspect that this is triggered by the IR Repeater functionality. So far, I have experienced the issue when using the remote of my Loewe Connect TV in vicinity of the Squeezebox. It does not occur when the IR Repeater is switched off. The logfile (with IR Blaster turn to "debug") shows the typical entries of the IR Blaster plugin (e.g. Plugins::IRBlaster::Plugin::RAWICallbackIRRepeat (1365) *** IR-Repeater: 850 etc.), even while the Squeezebox is already in the "endless emission loop". Thus, it would appear that the plugin continues to receive IR signals and resending them, but the Squeezebox or the chip driving the earphone jack seems to get off-track at some point. Software used: SqueezeCenter 7.2 (on Ubuntu Linux), Firmware 112, IR Blaster plugin v5.4
Chris: Did you use IRBlaster before? I.e. did the issue start to show after you upgraded to IRBlaster 5.4? I've put the remote commands of your Loewe Connect TV onto my Harmony One remote and tryed to reproduce what you are reporting, but so far I could not force it to fail. Only if I point the IR emitter back at the IR receiver in a optical loop I can get it to repeat one command over and over again, but as soon as break that loop it stops. And from your description I understand you are removing the IR emitter and connect a headphone to it in order to listen to the 'sound'. So I guess that is not it. Do you have any other pointer that might help me reproducing this case? Thanks, Felix.
Felix, Unfortunately, I did not use the described setup with any earlier version of the IR Blaster plugin. As you rightly assume I do not think that it is an optical loop (once the squeezebox is in this "mode", you can remove the IR Blaster from the earphone jack and replace it with earphones and the "signal" is still there - you can even stop the squeezecenter and it is still there). What I since achieved is the following: I patched the IR Blaster plugin to only selectively blast ir commands received by counting the number of "pairs" per blast. This way, I can force IR Blaster to ignore ir commands from the Loewe Connect (and other remotes) and to only forward those of the remote control of my sat setup box (which uses a different ir protocol with a specific number of "pairs" per burst different from that of the Loewe and which is the remote that I actually would like to forward into a cabinet). It also does not blast those sporadic "truncated" ir bursts (only one or two pairs long) that - according to the log - are being received by the squeezebox from time to time (from a source unknown to me). With this patch, I have not experienced the problem. From this, one could tell that receiving the signals is not the issue, but retransmitting them seems to bring the squeezebox "off track". What I will do (if you think that this could be helpful), is removing the patch again and then sending you the entire log file of the IR Blaster plugin from a "fresh restart" until the moment I experience the issue again (without actually knowing which ir bursts caused it). Could it be an issue in the squeezebox firmware (i.e. when the squeezebox is being asked to blast some ir commands while it still blasting others)? Chris
Hi Chris Thanks for the feedback and sorry I did not answer earlier. I am glad you found a solution for yourself for the moment. I'll need to look into this again, but so far I cannot find a reason why the code in firmware would go into a infinite loop but that is most certainly what happens else it would stop when SC is stopped. It won't make it for 7.3 so I am moving it to the next release which is 8. I'll contact you again if I think I have something worth testing. Felix
(In reply to comment #3) > Hi Chris > > Thanks for the feedback and sorry I did not answer earlier. I am glad you found > a solution for yourself for the moment. I'll need to look into this again, but > so far I cannot find a reason why the code in firmware would go into a infinite > loop but that is most certainly what happens else it would stop when SC is > stopped. > > It won't make it for 7.3 so I am moving it to the next release which is 8. > > I'll contact you again if I think I have something worth testing. > > Felix > Strange enough and contrary to what I initally thought, the problem persists even with my "restricted" repeating solution. What might be interesting is the fact that once the device is in this erroneous mode, not even a my $geekmode = pack( 'C', 0); $client->sendFrame( 'geek', \$geekmode); which normally should turn the headphone jack back to its ordinary function, would work (there is an audible crack in the earphones, but music is not played through the earphone jack). Only pulling the power from the Squeezebox helps. Is the source code of the firmware available? I would be interested in digging somewhat deeper into this issue. Regards, Chris
(In reply to comment #4) > (In reply to comment #3) > > Hi Chris > > > > Thanks for the feedback and sorry I did not answer earlier. I am glad you found > > a solution for yourself for the moment. I'll need to look into this again, but > > so far I cannot find a reason why the code in firmware would go into a infinite > > loop but that is most certainly what happens else it would stop when SC is > > stopped. > > > > It won't make it for 7.3 so I am moving it to the next release which is 8. > > > > I'll contact you again if I think I have something worth testing. > > > > Felix > > > > Strange enough and contrary to what I initally thought, the problem persists > even with my "restricted" repeating solution. What might be interesting is the > fact that once the device is in this erroneous mode, not even a > > my $geekmode = pack( 'C', 0); > $client->sendFrame( 'geek', \$geekmode); > > which normally should turn the headphone jack back to its ordinary function, > would work (there is an audible crack in the earphones, but music is not played > through the earphone jack). Only pulling the power from the Squeezebox helps. > > Is the source code of the firmware available? I would be interested in digging > somewhat deeper into this issue. > > Regards, > Chris > I think to have discovered the cause for the issue. The "endless emission loop" is triggered whenever an ir code with a high time or low time of only 25 is blasted. While such short ir pulses should not occur under normal circumstances, disturbances (such as reflections, not properly pointed ir control, or the like) can cause the ir receiver to receive such short pulses. The ir repeater subroutine should make sure that bursts with such short pulses are ignored. A solution would be to check the length of the high time and low time of each pulse (e.g. for being not shorter than 50) and to disregard the burst if the condition is satisfied. I am currently working on a patch that should do the trick. Regards, Chris
Created attachment 4518 [details] Suggested patch for Bug 9611
Hi Chris, thanks for the patch. I have not yet had time to check it out in detail but I think it looks ok. Thanks again.
Hi Chris I know it's been a long while since I last updated IR-Blaster. But finally I found some time to fix some bugs and add your patch. Thanks again. Look for version v5.6 installable via the new repository mechanism in Squeezebox Server. Felix