Slow: HTTP Request Trigger -> keycode on NVIDIA SHIELD

[MarkerB]

I've included the log of several DPAD_DOWN commands, then a few DPAD_UP commands until complete failure. It's a large log, so I put it elsewhere on the web instead of inline here.

https://embernet.com/misc/AutoMagicShieldLog.txt

The log shows that each execution gives a "Automagic input method is not started", even though the flow (see previous post) definitely switches to the Automagic input method. However, it seems the input method is switched back before Control UI's sendKey() is called. This doesn't make sense to me, since in the flow, the sendKey() is between the Automagic input method and the Leanback input method. How did they become executed out of order?

The log also reveals some signs of why it is every other keysend that doesn't work. The log alternates between the "Automagic input method is not started" proving fatal, and only being a warning.

Eventually an "Emergency stop count reached" causes the flow to be disabled.

Any ideas?

[Desmanto]

So you have trace down the source of problem. sendKey() only works when Automagic input is the default input method. The problem occurs because Automagic run much faster than the OS receiving the command from Automagic to change the input method. You can see this as the log execute Set default input method at 46.896. Then continue to execute sendKey() at 46.907; only mere 11 miliseconds (very fast).

The speed of the android to change the input method can vary depends on many things. You have to tried it out. I actually also have the same problem when testing the flow before, but it seems I forgot to mention to put sleep(100) before sendKey(); the devil is in the details. This way, Automagic wait for 100 ms, waiting the OS to completely switching the keyboard before executing sendKey(). The 100 ms vary, you should try it out, maybe 50 ms or maybe 200 ms.

But this will introduce new problem, a 100 ms latency to every execution, max 10 executions per seconds. And another one if you run the flow in parallel, the input method is set back-thru so many times. So it is better you use another flow to toggle the default input method. Create another path, maybe /automagic/keyevent/switchkeyboard, to toggle the default input method. So default keyboard will be Automagic keyboard. You can run the flow with only that control UI, without the set default input method. Then when you need to type using lean keyboard, use /automagic/keyevent/switchkeyboard to switch to lean. After finish, toggle it back to default automagic keyboard.

This will save the element execution too and reduce overhead for every flow execution. The Automagic emergency stop also can be lower. Default is 60, means 60 element execution per minute. Once you reach this, the flow will be disabled. Since you are going to use the flow a lot, you might want to increase this to maybe 300 (5 key changes every seconds should be enough). Look at my index about FEP and AEP.

[MarkerB]

Yay, that's it! Now the HTTP driven keysends are happening very fast, completely responsive for media player and d-pad usage. Thank you so much!

I stripped out all the settings of the default keyboard input, which made the whole process simpler.

I didn't even think the events would be fired asynchronously.

Anyway, thank you for working with me. Now I can get to mapping everything to a Unified Remote.

[MarkerB]

Mostly good, apart from a silly little problem.

It looks like Kodi and/or NVIDIA SHIELD ignores the "metakey" parameter of sendKey();

sendKey("A", "CTRL_ON") should toggle the audio track, but it merely behaves the same as sendKey("A") that adjusts the audio sync. There seems no way to send an "A" with a <CTRL> key held down.

[Desmanto]

Nice to see it is working in lightning speed now.

Did it only happen in Kodi? If you try the Ctrl+A in other app, such as text editor, can it select all text? I just try sendKey("A", "CTRL_ON") in MiXplorer Text Editor and it is working fine, selecting all text.

[MarkerB]

Did it only happen in Kodi? If you try the Ctrl+A in other app, such as text editor, can it select all text? I just try sendKey("A", "CTRL_ON") in MiXplorer Text Editor and it is working fine, selecting all text.

I did a test in a text editor, and it worked. So, the <Ctrl> part of sendKey("A", "CTRL_ON") only doesn't work in Kodi. I've already remapped the plain "u" key to the function I need, so I guess it's not pressing.

Unfortunately, what is really a disaster is that sendKey("HOME") doesn't work anywhere in NVIDIA SHIELD! It does nothing, and generates no error in the log. Sadly, I hadn't noticed that until doing a bunch more integration work.

Sigh... Why does every company have to deviate from the standards?

[Desmanto]

That's the problem with fragmentation and with so many company want to be stand out of crowd and create their own standard. You can try to remap existing key to another function. Or use control UI click() to manage that not working part. If you just wanna go Home (forgive the pun ), there is action Show Home screen. This will immediately jumps to home screen. For some supported launcher, such as nova launcher, you can even mention to go to homescreen page 1, 2, 3, ... etc.

[MarkerB]

That's the problem with fragmentation and with so many company want to be stand out of crowd and create their own standard.

It seems like everyone wants to be like Apple now; even Google.

You can try to remap existing key to another function. Or use control UI click() to manage that not working part. If you just wanna go Home (forgive the pun ), there is action Show Home screen. This will immediately jumps to home screen. For some supported launcher, such as nova launcher, you can even mention to go to homescreen page 1, 2, 3, ... etc.

Oh, great! I didn't think outside the box of sendKey().

[MarkerB]

I just wanted to thank Desmanto again for helping me work this out. With the addition of coding so the home() function is called instead of the non-working sendKey("HOME") under the SHIELD, I've now got a responsive and reliable remote control through UnifiedRemote, thanks to Automagic.

One additional problem was that when the SHIELD's native screensaver kicked-in, it made Kodi unresponsive to my Automagic script. Then I would have to use the SHIELD's native controller, or a Bluetooth remote or keyboard to return to the SHIELD's home screen, after which things would work again. I found that if I just configured Kodi's own screensaver (which overrides the SHIELD's native one), everything works consistently.

Kudos to Automagic's excellent support!

Hopefully this thread will help other integrators. If anyone needs assistance getting automation working with the SHIELD, I'd be glad to help. Post a message on this board, and then private message me and let me know where you posted it.