This page last changed on Dec 07, 2013 by juha.

Not sure what has happened now.

Had a problem with my network the other day, and restarted everything.
Now my PS3 (which is controlled by OR, using TCP, to my A/V receiver using HDMI) now locks up after 5 buttons presses. Or rather the amp does.

If I send :

0x495343500000001000000009010000002131434456504c41590D

Which translates to "ISCP !1CDVPLAY" five times, it will lock.
If I use Vol+/- or mute in between presses, it is fine.

This implies that randomly, something is not sending CR/LF that it was before. I'm flummoxed. Nothing else has changed. If I power off/on the amp, it works again, for 5 more presses - so OR is still sending, but whatever it sends "now" isn't what it sent yesterday.

No other changes. Weird...(and no, no f/w upgrades on the amp)

More curiously, if I use Hercules and send the exact same string AFTER it's stopped responding to OR, the amp responds. It's like OR has started holding a session open and not releasing something....and the amp restarting kills the session.

Ideas?

Posted by ptruman at Dec 06, 2013 20:40

Only thing I can think of is I did a save/reload from the Preview designer (which I've always been using) and that's somehow changed the code when syncing? (local OR server side code hasn't changed)

If I sent a "left" code to my AV Amp (to control a connected via HDMI player) to go "left" using hex

0x4953435000000010000000090100000021314344564c4546540D

It will work for 4-5 pushes. If I use the exact same string in Hercules (albeit without the 0x) it will respond, even after OR has stopped responding. OR in "-run" mode shows no errors though.

Posted by ptruman at Dec 06, 2013 22:56

Ok, it's clearly something sessional that's changed somehow.
192.168.1.210 is my NAS/OR server
192.168.1.205 is my Onkyo amp.

See what happens via netstat below...

Five Volume presses :

tcp 0 0 192.168.1.210:60495 192.168.1.205:60128 TIME_WAIT
tcp 0 0 192.168.1.210:60488 192.168.1.205:60128 TIME_WAIT
tcp 0 0 192.168.1.210:60512 192.168.1.205:60128 TIME_WAIT
tcp 0 0 192.168.1.210:60492 192.168.1.205:60128 TIME_WAIT
tcp 0 0 192.168.1.210:60487 192.168.1.205:60128 TIME_WAIT

(these all appear to 'close' a connection ok - hence no issues with volume)

Seven Volume presses :

tcp 0 0 192.168.1.210:60495 192.168.1.205:60128 TIME_WAIT
tcp 0 0 192.168.1.210:60488 192.168.1.205:60128 TIME_WAIT
tcp 0 0 192.168.1.210:60553 192.168.1.205:60128 TIME_WAIT
tcp 0 0 192.168.1.210:60512 192.168.1.205:60128 TIME_WAIT
tcp 0 0 192.168.1.210:60492 192.168.1.205:60128 TIME_WAIT
tcp 0 0 192.168.1.210:60487 192.168.1.205:60128 TIME_WAIT
tcp 0 0 192.168.1.210:60568 192.168.1.205:60128 TIME_WAIT

Same again...but then we add one "left" press :

tcp 0 0 192.168.1.210:60495 192.168.1.205:60128 TIME_WAIT
tcp 0 0 192.168.1.210:60590 192.168.1.205:60128 ESTABLISHED
tcp 0 0 192.168.1.210:60488 192.168.1.205:60128 TIME_WAIT
tcp 0 0 192.168.1.210:60553 192.168.1.205:60128 TIME_WAIT
tcp 0 0 192.168.1.210:60512 192.168.1.205:60128 TIME_WAIT
tcp 0 0 192.168.1.210:60492 192.168.1.205:60128 TIME_WAIT
tcp 0 0 192.168.1.210:60487 192.168.1.205:60128 TIME_WAIT
tcp 0 0 192.168.1.210:60568 192.168.1.205:60128 TIME_WAIT

Oh look, a stuck open connection!

And another "left" press :

tcp 0 0 192.168.1.210:60495 192.168.1.205:60128 TIME_WAIT
tcp 0 0 192.168.1.210:60590 192.168.1.205:60128 ESTABLISHED
tcp 0 0 192.168.1.210:60618 192.168.1.205:60128 ESTABLISHED
tcp 0 0 192.168.1.210:60553 192.168.1.205:60128 TIME_WAIT
tcp 0 0 192.168.1.210:60512 192.168.1.205:60128 TIME_WAIT
tcp 0 0 192.168.1.210:60492 192.168.1.205:60128 TIME_WAIT
tcp 0 0 192.168.1.210:60568 192.168.1.205:60128 TIME_WAIT

That's two connections stuck.

Then a volume press (this clears the established session) :

tcp 0 0 192.168.1.210:60590 192.168.1.205:60128 TIME_WAIT
tcp 0 0 192.168.1.210:60645 192.168.1.205:60128 TIME_WAIT
tcp 0 0 192.168.1.210:60618 192.168.1.205:60128 TIME_WAIT
tcp 0 0 192.168.1.210:60553 192.168.1.205:60128 TIME_WAIT
tcp 0 0 192.168.1.210:60512 192.168.1.205:60128 TIME_WAIT
tcp 0 0 192.168.1.210:60568 192.168.1.205:60128 TIME_WAIT

Then lots of left presses (it jams on 4)

tcp 0 0 192.168.1.210:60590 192.168.1.205:60128 TIME_WAIT
tcp 0 0 192.168.1.210:60682 192.168.1.205:60128 ESTABLISHED
tcp 0 0 192.168.1.210:60688 192.168.1.205:60128 ESTABLISHED
tcp 0 0 192.168.1.210:60674 192.168.1.205:60128 ESTABLISHED
tcp 0 0 192.168.1.210:60645 192.168.1.205:60128 TIME_WAIT
tcp 0 0 192.168.1.210:60618 192.168.1.205:60128 TIME_WAIT
tcp 0 0 192.168.1.210:60673 192.168.1.205:60128 ESTABLISHED
tcp 0 0 192.168.1.210:60689 192.168.1.205:60128 ESTABLISHED
tcp 0 0 192.168.1.210:60685 192.168.1.205:60128 ESTABLISHED
tcp 0 0 192.168.1.210:60692 192.168.1.205:60128 ESTABLISHED
tcp 0 0 192.168.1.210:60670 192.168.1.205:60128 ESTABLISHED

They all get stuck.
The reason Hercules keeps working is obviously the amp allows conns from multiple IPs (my laptop in this case) and Hercules shuts the session ok.

So, can anyone see why THIS command doesn't upset it:

0x4953435000000010000000090100000021314d564c55500D
(Volume Up)

But this one:

0x4953435000000010000000090100000021314344564c4546540d0a0D
(CD via HDMI, Left)

kills it?
It's literally just a TCP/IP connection to the Onkyo IP, with that string sent. Nothing else. :\

Posted by ptruman at Dec 06, 2013 23:08

Okay, more diags.
I ran tcpdump to packet capture the keypresses from OR to A/V (and if you're interested, the Wireshark compatible dump file is at http://www.tainted.myby.co.uk/comm.pcap )

What I'm seeing on Vol+/Vol- and Mute are the following TCP sequences:

SYN (Setup)
ACK (Acknowledge Syn)
PSH (Send command)
ACK (Acknowledge PSH)
FIN (Close conn)
ACK (Acknowledge FIN)

When I send the following sequence (Vol+,Vol-,Mute,Setup,Setup,Setup,Vol+,Vol-,Mute) I would expect to see 9 iterations of the above. What I actually get is this :

SYN (Setup)
ACK (Acknowledge Syn)
PSH (Send command)
ACK (Acknowledge PSH)
FIN (Close conn)
ACK (Acknowledge FIN) (1st Set Ok)
SYN (Setup)
ACK (Acknowledge Syn)
PSH (Send command)
ACK (Acknowledge PSH)
FIN (Close conn)
ACK (Acknowledge FIN) (2nd Set Ok)
SYN (Setup)
ACK (Acknowledge Syn)
PSH (Send command)
ACK (Acknowledge PSH)
FIN (Close conn)
ACK (Acknowledge FIN) (3rd Set Ok)
– At this point it all goes wobbly - here comes a SETUP key press –
SYN
ACK
PSH (Sends setup)
SYN (WHERE IS THE ACK?!)
ACK (Here is one - but is it the ACK to the PSH, or the ACK to the new SYN?)
PSH (Sends setup - but no FIN before it....)
SYN (and so on)
ACK
PSH (Sends setup)
SYN
ACK
PSH (Sends Vol+)
SYN
ACK
PSH (Sends Vol-)
ACK
FIN (Ahah, a FIN, but no idea which SYN this relates to now!)
ACK
ACK (two ACKS now?!)
FIN (but no idea which SYN this relates to now!)
FIN (but no idea which SYN this relates to now!)
ACK
ACK
ACK
ACK
FIN
ACK
FIN
ACK
ACK
SYN
ACK
PSH (Send Mute)
ACK
FIN
ACK

No idea why it's broken. The only thing I remember doing is loading my panel in Preview designer (which I do due to using ColorWheel) and rather stupidly, saving. I suspect that's changed something, so when I next synced, it's broken the commands. I've grabbed the latest ORCJAVA-400 build (just in case) and that does the same.

Posted by ptruman at Dec 07, 2013 11:02

Hi Peter,

The only thing the save in the designer could/would impact is the XML file in your controller directory, and the TCP payload defined there (which you can see in the designer). It wouldn't change how the TCP packets are sent, that's the implementation of the controller. And even in the implementation at the JVM level there's no access to the network layer SYN/ACK behavior so those would never change.

So if the payload itself is still the same, and you haven't changed the controller implementation, the network layer frame management wouldn't change on OR side. The answer to the mystery must be something else.

Posted by juha at Dec 07, 2013 11:13

I think I'm narrowing it down to the A/V receiver, but I'm not sure why.
I've just switched modes (manually, with the hard buttons) and fired several Vol+/- at it, and it behaved.

The only thing the "crashing" buttons are doing is sending commands to the A/V which it should send over HDMI, and now it's working again. I've now got a PCAP with correctly ordered SYN/ACK/PSH/ACK/FIN/ACKs - so I'm rather perplexed to put it mildly....(and going to keep poking it)

(At the very least there may be a note required for Onkyo/Integra amp owners that TCP commands may randomly break for inexplicable reasons...)

Posted by ptruman at Dec 07, 2013 11:26

Peter, did you ever get this totally figured out? I am having the same problem when sending TCP commands to a Windows 7 PC. It will lock up after 5 commands and then start working again a minute or two later. Please let me know what you found as to how I can get my issue resolved...

Posted by bbaskety at Jan 21, 2014 17:52

Hi,

My finger is pointed firmly at the A/V receiver.

I don't know why, but changing through all the inputs, in sequence, seems to "cure" it.
BD/DVD, VCR/DVR, CBL/SAT, GAME, PC, AUX, TUNER, TV/CD, PORT, NET, USB and back to BD/DVD

I suspect changing on/off the NET input resets something. Even after that it's not "immediate" on SYN/ACK'ing connections, but it stops holding them open.

The amp has a 5 connection limit from any one IP, so if this happens it cripples OpenRemote's ability to control it nicely.

Start/Stopping OpenRemote, disabling/enabling net support, or powering on/off the amp doesn't cure it - just cycling the inputs seems to kick it...

Let me know if it works for you....

Posted by ptruman at Jan 21, 2014 19:43

Although saying that now my OR won't turn the PS3 on. But does everything else in the macro, and will turn it off. Nothing has changed (except my having left a PS Vita plugged into the PS3 and both being in standby). Argh!

Posted by ptruman at Jan 21, 2014 20:39

The above has now been cured.

Seem even though the PS3 was set to allow HDMI control, it needed disabling, powering off, powering on and enabling. Then it's all started working again.

Posted by ptruman at Jan 24, 2014 09:24
Document generated by Confluence on Jun 05, 2016 09:39