SqueezeIR Support Thread

[indifference_engine]

Hi all, I must apologise for v1.12

It was meant to be more tolerant of dodgy xml but it appears not to work on the Controller even though it works fine on Desktop Squeezeplay (which is an easier test environment). I shall re-release v1.11 (as v1.13 so that repo updates will work) until I figure out a solution. I'm really busy atm so it may be a while before a "proper" new version appears.

Update: v1.11r2 is now available which will undo the problems that were encountered with v1.12

[indifference_engine]

Any reason why a configuration file could stay indefinitely with "Result: 2 (In Progress)" status?

I have found a fix that will gracefully fail if dodgy xml is encountered (and won't crash like my previous attempt in v1.12 did!). However it doesn't identify the problem, merely recognises that there is one and aborts instead of getting stuck. What I really need is a DTD file that you can validate your SqueezeIR.xml against prior to loading it into the applet but that is beyond me!

I managed to maneuver SqueezeIR 1.11 into a state that wouldn't allow me to access any of its two menus.

That was caused by the Use IRoIP setting being honoured even though the cache had been cleared. I have fixed this although not in the way you suggested as there was another place in the code where the same bug would cause different symptoms. Thanks for the suggestion though and more thanks for highlighting the issue. IRoIP is relatively new so there were bound to be a few bugs.

Both of these fixes will be in the next release...

[indifference_engine]

Can I attach SqueezeIR actions to a SqueezePlay menu item? E.g., can I send the IR commands to power on the stereo and switch it to AUX when I use the controller to turn on the receiver?

A number of people have asked about this in the past but it was never the way SqueezeIR was intended to work. Although it could be done there could be problems. Imagine the scenario;
You press play on the controller
The controller sends the signal to SBS
SBS sends the signal to the player and the player starts
The player sends a signal back to SBS saying 'I am playing'
SBS sends the signal back to the Controller
The controller updates the player status
SqueezeIR detects the change in player status and sends an IR code

Admittedly I'm not 100% that the above is correct but even so;
1) If during the Controller-SBS-player conversation you move so that the controller isn't pointing at the amp then the IR signal is lost.
2) You miss the first few seconds of your music while your amp warms up.

But that takes about two more clicks and some additional wheel action ,-)!

Not necessarily. I have used SqueezeIR to remap the Home button. When I hold it down instead of turning off the controller (the default behaviour) it turns my amp on and sets it to the correct input. Turning on my amp is now only a button-press away and it doesn't matter which screen I am in. IMHO this is the best way to do it.

[indifference_engine]

Hello indifference engine,

I build a very large xml file. This caused my Controller hangs in a reboot circle.
After deleting the SqueezeIR folder via SSH the controller runs proper again.

But now I cant open your standard SqueezeIR.xml or my customized with more than 4 action items.

New install, delete of SqueezeIR folder, Controller factory reset, restore of old Firmware has not helped.

Is there any cache folder or file to delete manual?

I think your giant xml file is just too big for the poor little controller to handle. The file loaded ok when I tested it using Desktop Squeezeplay but it took two minutes to load and maxed out my Core2Duo laptop - I think the Controller has no chance with anything this big!

The issue with the 4 items problem was a bug in v1.12 of SqueezeIR, I have re-released v1.11 (as v1.11r2) until I get that fixed.

The SqueezeIR cache can be deleted from /etc/squeezeplay/userpath/settings/SqueezeIR.lua using SSH/SCP. Just delete the file - it will be re-created when SqueezeIR is next used.

Can I ask why you want to control 20 TV's??

[indifference_engine]

I have found a fix that will gracefully fail if dodgy xml is encountered (and won't crash like my previous attempt in v1.12 did!). However it doesn't identify the problem, merely recognises that there is one and aborts instead of getting stuck. What I really need is a DTD file that you can validate your SqueezeIR.xml against prior to loading it into the applet but that is beyond me!


That was caused by the Use IRoIP setting being honoured even though the cache had been cleared. I have fixed this although not in the way you suggested as there was another place in the code where the same bug would cause different symptoms. Thanks for the suggestion though and more thanks for highlighting the issue. IRoIP is relatively new so there were bound to be a few bugs.

Both of these fixes will be in the next release...

These fixes are both in v1.13 which is now available from the repo.

[indifference_engine]

All,

I have broken the habit of a lifetime and have read a book! This has given me something astounding that I believe is called 'knowledge' although I understand that a little of it is rather dangerous. Nevertheless...

I have managed to create an xml schema that should help you all in creating your configuration files. The schema is available from the files section of my website (http://www.woodbine.me.uk/squeezebox.../SqueezeIR.xsd). Also on the same page is a new template file that includes just the headers required for SqueezeIR and nothing else.

To make SqueezeIR compliant with the schema I will have to make a few changes:
1) keyCodes will no longer be supported, all keys will need to be referenced in keyNames. So, for example if you had

<key ID="50">

you will now need

<keyNames>
  <keyName ID="myKey">50</keyName>
</keyNames>
<key ID="myKey">

2) The <menu> element of a profile will be removed as I discovered that it is duplicating functionality supplied by the <menuEvent> element. So if you have

<menu>My Menu</menu>

you will need to replace it with

<menuEvent>
<target>my Menu</target>
</menuEvent>

I plan to make the new version live in early april but the current version of SqueezeIR will work with the changes described so it makes sense for you to implement them sooner rather than later.

I have also fixed a couple of minor bugs that I discovered whilst trawling the code.

[virx71]

Hello everybody,
I just came across SqueezeIR and I'm curious to try it.
Unfortunately the latest version download link is not working properly
and btinternet.com/~douglashill456 pages are no more available.

I wonder if Douglas or anybody else having v1.13 or later release could please attach it here on the forum
or email it to me @ virx71 at quipo.it

Many thanks and have a good day!
Virgus

[igkr]

Hello everybody, for me it also don't working.
Please update the link for downloading.

Many thanks.
Igor

Hello everybody,
I just came across SqueezeIR and I'm curious to try it.
Unfortunately the latest version download link is not working properly
and btinternet.com/~douglashill456 pages are no more available.

I wonder if Douglas or anybody else having v1.13 or later release could please attach it here on the forum
or email it to me @ virx71 at quipo.it

Many thanks and have a good day!
Virgus

[indifference_engine]

Hello everybody, for me it also don't working.
Please update the link for downloading.

Many thanks.
Igor

Hi All,

Unfortunately BT have removed their free web hosting service and google obfuscates the url so much that the repo won't use it. Until I find another web hosting service you will have to download and install manually. All the files and instructions can be found on the SqueezeIR website (http://www.woodbine.me.uk/squeezebox/squeezeir)

Sorry for the inconvenience, I shall look into getting the the repo posted elsewhere.

[virx71]

Douglas,
THANK YOU!

You did a wonderful job and took out what was really missing from the Squeeze Controller!
I deserve you at least a beer or two!
I didn't see a donate link on your web site though, you should think about it!

About the newest versions:
I noticed that the SqueezeIR_1.13.zip is not listed in the available downloads.
What about putting new releases in a GoogleDrive or similar cloud services and share the link?

Luckily I found I downloaded a few months ago and kept it in my Squeezebox archive
and I've been able to make my xml file grow up to 45KB!

About SqueezeIR improvements I would like to write down my observations that might be taken into account for future releases:

• First of all a question:
  I'm using a profile for each SB receiver an one main menu:
  should I create different main menus for each receiver or can I assign a <profile></profile> tag to a menu item itself?

• Secondly an explanation and an idea:
  I have several submenus in which I have several macros which involve different remotes actions at the same time
  and some playerActions which happen to be replicated several times: in keys, in menu events and in IPevents as well.
  
  I was wondering why not creating another object called "macro" defined in its own section where we could define each single macro
  only once and then call it whenever needed. A macro could be used as a complex action element
  To simplifying things all playerAction elements could be included in actions thus allowing playerActions to be ordered inside a single event flow.
  
  EG:
  

  	<events>
  		<event ID="HOLD">
  			<override>TRUE</override>
  			<actions>
  				<action order="1">
  					<remote>AltecLansing</remote>
  					<command>PWR1</command>
  				</action>
  				<action order="2">
  					<remote>AltecLansing</remote>
  					<command>REAR1</command>
  					<pause>1</pause>
  				</action>
  				<action order="3">
  					<remote>AltecLansing</remote>
  					<command>vol1+</command>
  					<count>10</count>
  				</action>
  				<action order="4">
  					<remote>Curtains</remote>
  					<command>aopen</command>
  				</action>
  			</actions>
  			<playerActions>
  					<playerAction order="1">play</playerAction>
  			</playerActions>                                        
  		</event>
  	</events>

  would become:
  

  	<macros>
  		<macro ID="WakeUp">
  			<actions>
  				<action order="1">
  					<remote>AltecLansing</remote>
  					<command>PWR1</command>
  				</action>
  				<action order="2">
  					<remote>AltecLansing</remote>
  					<command>REAR1</command>
  					<pause>1</pause>
  				</action>
  				<action order="3">
  					<remote>AltecLansing</remote>
  					<command>vol1+</command>
  					<count>10</count>
  				</action>
  				<action order="4">
  					<remote>Curtains</remote>
  					<command>aopen</command>
  				</action>
  			</actions>
  			<action order="5">
  					<playerAction order="1">play</playerAction>
  			</actions>
  		</macro>
  	</macros>

  And my event would then become:
  

  	<events>
  		<event ID="HOLD">
  			<override>TRUE</override>
  			<actions>
  				<action order="1">
  					<macro>WakeUp</macro>
  				</action>
  				<action order="2">
  					Whatever else action or macro or powerAction
  				</action>
  				...
  			</actions>
  		</event>
  	</events>

  My 45KB xml would reduce by maybe half and I could modify each macro only once instead of having to search every time for all the instances...

• Third idea:
  I noticed that the order parameter is used exclusively: if I put by error two order 2s only the last one is taken into account.
  This is a strict behaviour but it might be more simple to use the order parameter as a sorting one: all the elements ordered would appear by their order number and then sorted alphabetically (this would be both useful in menus and in IPevents - see last observation)
  In this way I could build my menus by adding new items or moving items' positions without having to check again and again each order parameter value.

• Fourth, on IR-o-IP:
  The "Update Configuration link" is not working, I tried several times to use it without success.
  Not sure if it's a bug or I'm missing something in the xml configuration to enable it.
  It would be really useful to update all my controllers remotely with just one click!
  
  A few ideas:
  In IPevents it would be great to have order parameters as well with the same flexible definition described above.
  
  I imagined also it would be great to organize tables differently:
  2 3 4 5 10 repeat times are needed only for volumes control and count times could be decided inside the IPevents
  definition by a count parameter as in actions elements. Thus if I need Vol+ 1 time or 5 times I could easily create two
  events with same command and different count values.
  
  Imagine now instead, to use columns to organize devices' commands:
  the first column would have listed unlimited IPevents which have order parameter set from 0 to 9
  the second column would have listed IPevents order parameter set from 10 to 19
  etc...
  
  Likely all the IR-o-IP links would fit on a single page without the need of scrolling.
  
  A last nice thing would be to have the SqueezeIR:OK:IROIP feedback inside a management DIV floating on the right of the screen
  together with "Update Configuration" and "Reload Cache" links to maximize the space in the page.

Well not bad after not even two days of usage of your wonderful tool,
probably more ideas will pop up in the next few days!

Kind regards,
Virginio

PS It would be great to add in the future X10 elements to actions, but I did non investigate yet on SqueezeBox X10 third party implementations....