Bugzilla – Bug 6244
Funny actions with IR Blaster plugin
Last modified: 2008-03-11 16:53:25 UTC
I am not sure where to post this so I will put it here and also for the IR Blaster plugin author. Background: Transporter On Transporter IR blaster sends out IR for Power on, Power off, Volume up, Volume down. 4 different codes Transporter volume set fixed at 100 as it plays mostly encoded music (DTS). Three remote devices are used, the standard Slim remote, A Philips Pronto which is fully functional with 2 way IP to SqueezeCenter over IP, and the Jive remote with regard to power on/off; All three remotes operate as designed. The Transporter sends out the proper IR code when it is powered on or powered off, independent of which remote is used. However if doing a volume up or volume down, the Transporter sends out the Proper IR codes for the Audio processor to control the volume when it is the normal slim remote driving it, or the Philps Pronto which sends CLI commands for mixer volume up or down +5 units to SqueezeCenter. The problem is with the Jive platform. It always causes the Transporter to send out the Volume Up IR command independent of whether the volume up or down button was pressed. I assume it is commanding Squeezecenter but probably not using the CLI interface so it can be the plugin.
From the comments in the IRBlaster Plugin: # Up / Down volume commands (remote) have a sign (i.e. -2.5) # Absolute volumes (Web interface) do not have a sign # Transporter knob volume is also absolute and not useable at the moment Jive is sending absolute values as well, so you are probably going to see the same behaviour with web UI and the transpoter Knob. You can enable logging by setting plugins.irblaster to DEBUG and see this in effect. one possible fix might be to alter line 1141 of IRBlaster\Plugin.pm from: if( $newVol > 50) { to if( $newVol > $client->volume) {
Created attachment 2452 [details] give this a try I think this will work. I only have the debug to go by as I'm using emulation right now, but this does detect the volume direction for absolute values. It also adds a shortcut to bypass any further handling if the absolute value is the same as the current value (this happens on each volume update so it avoids sending a down ir after each up)
KDF, I am not sure what I need to do with the attachment, but I will try to work it out. I will let you know if I get totally lost. I have never touched a plugin but now is a good time to start I guess.
Looking at the attachment it looks like input into a patching program I do not have. I assume the begining part is to position the patcher to line 1132 of the module since those lines do match up I assume the patch actions are based upon what is in col 1 + means add the line - means remove the lne blank means leave the line alone If that is correct I guess I can just do it. thanks I will give it a whirl and let you know tomorrow.
Barry, Many plugins will now be released as .par file packages. IRBlaster, however, is still in the form of raw perl modules. thus, it is loaded on the fly even in windows. They files are plain text, unix-style line endings (use wordpad rather than notepad). Your assumptions about the patch are correct. You should be able to find the code block around line 1132, remove all - lines, adding all + lines. Leave the rest alone and restart slimserver. In settings->advanced->logging, set plugin.irblaster to DEBUG to get the log to show what's going on when you try the volume controls. Hopefully it works as expected.
KDF, Unfortunately the code does not work. Since I have the Transporter set to lock volume at 100 to force encoded music to play properly (The audio processor the Transporter feeds handles the voulume and that is why I use IRblaster in the first place) it appears that client->volume() always returns 100 causing the test to fail. The elseif also fails since the new volume <> 100 (current volume of the client) causing $UP to stay at 0, causing the volume to go down. I see no way around this if the transporter always returns 100 for a locked volume; or is there a way to tell the transporter to track volume changes returning a "pseudo setting" while driving the digital outputs at volume=100. I believe the proper solution is to have the Transporter all by it self lock the digital output at 100 if it detects an encoded music track
To further complicate matters, The IR blaster has a setting which only comes in to play if you are sending out IR volume commands as I am. That setting locks the volume of the Client at a value (20,40,60,80,100) in anticipation of using the variable analog outputs and feeding them to an audio processor. Since I am using the digital outputs only on the Transporter, The combination I need is: 1) Set the digital outputs to a fixed value (I assume if under the player (Transporter) audio settings you select fixed volume, that volume will be set to 100) 2) Allow the analog volume of the Transporter to be variable in addition to fixed. 3) Have the client properly report the varying analog volume as the volume of the Transporter in which the case of newvol > client->vol will allow the detection of up vs down on the volume setting. I guess this is more an IR balster plugin issue than a Slim devices issue, However it would all probably be solved if the web interface reported the direction of the volume change (the sign?) I will post this in the plugin forum for erland to pick up I will also study the plugin.pm code and maybe I can figure out what to do, Obviously your help and assistance was/is/will be appreciated.
Felix is the IRBlaster author and is cc'd on this report. Forum is still a good idea as there may be some different ideas that come out of it.
Sorry about that Felix, I was thinking browse plugins
Well I did some more testing and mods today. The issue is that the variable $client->volume() comes back at a fixed value and I can not figure out how to get it to return a true value. This occurrs as long as I have selected in IR Blaster a volume up down IR output. If that is not the case, the true volume (0-100) is returned. In settings.pm of IR blaster I forced the following: prefs for client fixed volume = '' params selfixedvolume to '' params selFixedVolumeDisabled=1 I still get back a fixed value. What is strange I have seen that fixed value at 20 60 and 100 depending on how I set the values in settings.pm If there was a way to allow the volume to vary and have it reported back that way the change to detect the up/down condition would work. I can not yet see how to do that in IR Blaster, perhaps Fred could advise. It is not a big problem for me, since it works pefectly from CLI but it is incorrect from the Web interface which I do not use in my work. It is not right that the Pronto PRO implementation (using CLI) will work properly but the Jive implementation will have the problem.
Fixed in IR Blaster plugin v5.2
Moving Jive Software (desktop app) bugs to the new SqueezePlay product