DemoPad.com

I use "Maintain active connection" for 2-way feedback with a Pioneer VSX-1021k. "Disconnect after each command" is unchecked. Multitasking obviously On.

I'm regularly seeing the following situation. Some disruption occurs on my LAN (ex: power outage, or some network component off-line). After restoring the LAN, commands from DemoPad (iPad mini) to the VSX-1021k don't get through; typically I'll witness this when I try to power on my AV system; commands to other 5 devices in my config get through ok (none of which have "Maintain active connection" set to On).

At DemoPad support's suggestion, I set up a button that performs the 2 actions 'disconnect' & 'connect' to the VSX-1021k, but still commands don't get acted upon by the VSX-1021k. If I unload the DemoPad application from memory and reload, then commands get through just fine to the VSX-1021k (it powers up).

Anybody else seeing this behavior? Could this be that DemoPad exceeds the number of retries and shuts the 2-way connection off, or gets tangled in processing further commands to it?

I was thinking of trying to check both settings "Maintain active connection" and "Disconnect after each command": is there a chance I could lose some feedback in the process? Any other suggestion?

Hi CV27

I have a Pioneer LX83, Maintain active ticked, I believe the lx83 uses the exact same protocols as your AV amp. Reading through your post, I have never experienced this before. I've had it running for over 15 months, all with feedback. I know this doesn't help, but thought I let you know.

starwarsmike wrote:Hi CV27

I have a Pioneer LX83, Maintain active ticked, I believe the lx83 uses the exact same protocols as your AV amp. Reading through your post, I have never experienced this before. I've had it running for over 15 months, all with feedback. I know this doesn't help, but thought I let you know.

Thanks for sharing your personal experience ... and re-awakening this thread: it happened again last night.

As stated in my initial post, doing a 'disconnect' & 'connect' to the VSX is unsuccessful while clearing the DemoPad app from the iPad's memory is successful. So reinitializing the app apparently does something more than connect.

Recently I discovered that at times, rapidly using the volume slider (controlling the VSX) will also render any further communication to the VSX unsuccessful. I thought the VSX was the culprit, getting lost in the exchange, but clearing the DemoPad app from the iPad's memory, without any manual intervention at the VSX, does the trick.

Although I use 2-way feedback on several IP devices, the VSX is the only device where I check for 5 different patterns, each with 1 to 3 actions on a hit.

If DemoPad support has any troubleshooting suggestions, I'm all ears.

It sounds like the app thinks it has a connection, when in fact it does not. I'd set up Hercules as a TCP Server, and connect the app to that, to make sure that a) your commands get through as expected and b) the disconnect / connect routine you have set up actually works - you can see the connected client count in Hercules.

Bear in mind that if you have maintain active connection ticked, then as soon as it disconnects (for any reason) it will attempt to re-establish the connection straight away.

Does the VSX only allow a single client connection? If so, it would be interesting to know if when the app doesn't send commands, can you connect to it with Hercules - or does the VSX think it is connected to something.

If this problem is easily duplicated, and you are able / willing to allow remote access temporarily, support@demopad.com will be able to run your project & diagnose further.

CV27

Might be a silly question, but are you ensuring you are leaving the required delays between commands, reason I ask is, I had to change a few commands to the required delay, otherwise my amp would need resetting.

Also if you use Roomie or likes, these apps maintain an active connecting, which results in no commands getting through from Demopad.

Please make sure to have at least a 100msec. interval between the 1st command and the second command.

<CR> <CR> <CR> <CR>
↓ ↓ ↓ ↓
100msec Wait 100msec Wait 100msec Wait 100msec Wait
↓ ↓ ↓ ↓
<CR>PO<CR> <CR>APO<CR> <CR>BPO<CR> <CR>ZEO<CR>

<CR> <CR> <CR> <CR> <CR>
↓ ↓ ↓ ↓ ↓
100msec Wait 100msec Wait 100msec Wait 100msec Wait 100msec Wait
↓ ↓ ↓ ↓ ↓
<CR>?P<CR> <CR>?AP<CR> <CR>?BP<CR> <CR>?ZEP<CR> <CR>AMX<CR>

<CR> <CR> <CR> <CR>
↓ ↓ ↓ ↓
100msec Wait 100msec Wait 100msec Wait 100msec Wait
↓ ↓ ↓ ↓
<CR>PZ<CR> <CR>APZ<CR> <CR>BPZ<CR> <CR>ZEZ<CR>

Good luck!!

Thanks Starwarsmike,

The number actions associated with the slider only send one command to the amp (setting its volume) and I realize sliding the volume on that slider very fast will send a great quantity of commands to the amp. So what you say makes sense and I will put the Pioneer required delay of 100ms. BUT...

The amp never freezes regardless: when I clear and reload DemoPad, the amp immediately acts upon received commands.

I'm also aware that the Pioneer amp allows only one connection, but I have no other device connecting to it aside from the iPad mini. Still a good reminder though, so thanks.

I use a slider also, iPad mini & works ok. Really strange!

What router you using?, do you have a different router to rule out that? I had to change my router because my standard BT route was causing issues when sending volume slider commands to my amp.

starwarsmike wrote:I use a slider also, iPad mini & works ok. Really strange!

Mine does as well, most of the time. I only had an issue while sliding the volume one or twice. But I did insert a 100ms delay, just to be safe.

starwarsmike wrote:What router you using?, do you have a different router to rule out that? I had to change my router because my standard BT route was causing issues when sending volume slider commands to my amp.

Keep in mind my setup works 99.9% of the time, so there must be a specific set of circumstances that triggers the issue of no commands getting through to the Amp. On that basis, I don't believe the router is the issue, and come to think of it, I had this issue at our previous house with a different router.

DemoPad wrote:... Bear in mind that if you have maintain active connection ticked, then as soon as it disconnects (for any reason) it will attempt to re-establish the connection straight away.

A few side questions:
1- Do I really need to select "Maintain active connection" in order to use 2-way feedback? If unselected, I assume the connection will remain active unless some external factor breaks it, right?
2- What would be the scenario and benefits for selecting both "Maintain active connection" and "Disconnect after each command"?

DemoPad wrote:... If this problem is easily duplicated, and you are able / willing to allow remote access temporarily, support@demopad.com will be able to run your project & diagnose further.

Unfortunately the issue cannot be duplicated on demand, but you've given me a hint to my next debugging task. Next time I see a freeze I'll start a network monitoring session. I'll then see the exact traffic issued by my iDevice and the one getting to the end device.

It is unusual to select both maintain active & disconnect after each command. You don't need to select maintain active if using feedback as long as you are sure the connection is going to be established somehow - for example by sending commands. If all you were doing was listening, without maintain active ticked, a connection would never be established by the app unless a command was sent, or a manual connection action was initiated.

DemoPad wrote:It sounds like the app thinks it has a connection, when in fact it does not. I'd set up Hercules as a TCP Server, and connect the app to that, to make sure that a) your commands get through as expected and b) the disconnect / connect routine you have set up actually works - you can see the connected client count in Hercules ...

On point b), just validated with WireShark that the disconnect (RST) & connect commands (SYN) get through ok and the Amp responds correctly, in a normal situation.

I now need to monitor traffic when the communication appears to freeze between DemoPad and the Amp.

cv27 wrote:

DemoPad wrote:It sounds like the app thinks it has a connection, when in fact it does not. I'd set up Hercules as a TCP Server, and connect the app to that, to make sure that a) your commands get through as expected and b) the disconnect / connect routine you have set up actually works - you can see the connected client count in Hercules ...

On point b), just validated with WireShark that the disconnect (RST) & connect commands (SYN) get through ok and the Amp responds correctly, in a normal situation.

I now need to monitor traffic when the communication appears to freeze between DemoPad and the Amp.

It's always uncomfortable to awaken an old thread. Too often now, I'm getting the issue where the DemoPad client is all of a sudden unable to send commands to my Pioneer amp. Given that the "disconnect" action does not work, my work around is to offload the client app from memory and reload it. This workaround may do the job but is not elegant. I'm also worried that, when I move to the Centro-8M, it will be cumbersome to reboot the unit to get things going gain.

I've done a trace on the last occurrence (WireShark log sent to support). Here are my warnings and findings:
- it only happens when sending commands to a particular device, a Pioneer VSX-1124K amp; this also happened when using a Pioneer VSX-1021k
- it happens quite randomly, no discernable pattern
- when this situation occurs, the client is still able to send commands to all other devices
- the trace shows that sending any command to the amp triggers absolutely no IP traffic, which explains why a disconnect/connect command does not work
- the trace also shows the amp interacting with other devices so its network stack is still functional
- every time, with no other intervention, simply offloading DemoPad from memory and reloading establishes a working socket with the amp and commands are successfully processed thereafter
- unfortunately, the issue is not repeatable at will.

I need help from DemoPad support in trouble shooting this. A few questions and thoughts:
- why is it that the client app sends stuff on that socket, which does not end up creating an IP packet (according to the trace), without returning any error?
- why is the issue just with this amp (both a 1021k and a 1124k)?
- I suspect it may have nothing to do with the device itself, but rather with the client logic, which has remained pretty well the same from the time I was using the 1021k to today with the 1024k
- the amp is the device where I have the most 2-way logic, close to 45 conditions
- if you trust the trace, there has to be an anomalie in the fact the client app thinks it' sending an IP packet but isn't in reality; someone is not reporting an exception: IOS, client app? Or the client app is simply nor processing commands for that device?

I'm lost as to what to look into next. What are the conditions for failure in the logic of accepting user requests (commands to the amp) all the way to requesting an IP packet be sent out?

The app won't report any errors. It is common for errors when trying to send commands - eg if a device is offline, no network connection etc - so the app just silently handles them, retrying for a period of time, and then eventually giving up.

As the issue is not repeatable on demand, it is going to be difficult to diagnose the issue - but as it is limited to Pioneer equipment, it would seem the issue is at that end.

When the issue occurs, does a power reset of the amp bring it back to life also?

I assume you are running the latest version of CentroControl?

I realize that I put a lot of information in that post.

DemoPad wrote:... but as it is limited to Pioneer equipment, it would seem the issue is at that end ...

1- As I explained, without any intervention on the Pioneer, simply offloading the app from memory and reloading clears the issue, commands are then processed by the Pioneer
2- If the Pioneer was at fault, it would be stuck in that state and would not in my opinion process any further requests. Also keep in mind that my trace shows that the Pioneer network stack remains active after the client app stops processing requests to that device
3- I acknowledge it is easy to point to the Pioneer, being the only device with this issue. But the other factor is that the amount of 2-way checking is significantly greater than for my other devices; is there a chance that the client app gets tangled up dealing with all those 45 conditions?
4- The trace shows that the Pioneer is pretty chatty; is there a chance that the client app gets overwhelmed and somehow overshoots a buffer, gets lost in a pointer array, etc.?

DemoPad wrote:... I assume you are running the latest version of CentroControl?

Good point. I'm currently still using the old DemoPadControlHD. I was waiting for the Centro-8M before jumping to the CentroControl.