Stream Deck mini updates the keys twice

[kcsajtai]

The streamdeck mini repeats the last image before updating to a new one. So if I update key0 and sometime later for example key5 then key5 first shows the image that has been sent to key0 for 0.1 or 0.2 sec then shows the image that is actually sent to it. The included basic example also has this issue.

[abcminiuser]

Unfortunately I don't have a StreamDeck mini to test on, only the original. @Aetherdyne do you see this behavior on your device?

[Aetherdyne]

It sounds like the same thing that I mentioned in the last comment on my pull request here. It's happened as long as I've had the mini showing any images at all.

Here's a shakycam video of the current example-basic script. Note that, as I press Key 0, the exit icon briefly appears on that button. And when I press the Exit key at the end, it briefly flashes the face icon that the others normally show. On the keys I press in between these, the glitch isn't very noticeable, presumably because it's just repeating one of the images that those buttons normally show.

I've never noticed it before, but right before the button images appear, you can also see Key 0 showing a fragment of the startup logo.

[kcsajtai]

Yepp same issue. It's a bit harder to spot on the basic example since it's using mostly the same images. But if you have like 6 different images each with different states then it becomes quite noticable. Thanks for looking into it :) This glitch aside I really like this project :)

[tappster]

I am having a problem with deck.set_key_image(key,image) call back to set the image on the streamdeck.
It is only with the Raspberry Pi. That call slows my program down. Button image update is slowed down intermittently. Don't see the flashing as in the basic example but the delay is there. Any ideas?
I used a Windows computer to design and did not see the problem. Also if I make the image 0 on the windows computer it keeps the image that Streamdeck program put in. Neat if Raspberry would do that.

[abcminiuser]

@tappster USB HID on the RPi is much slower for me - although I don't know if the cause is something in the Python USBHID wrapper library, or the underlying HID library. When I used this on my Pi for my home automation client I just kept the button images in a local cache and only updated it on the device when I knew it had to change (i.e. filter out repeated calls with an identical image) which made it run at an acceptable speed.

[jbman35]

Hello,
Same problem here by connecting StreamDeck mini on Linux Desktop computer. Each time I call deck.set_key_image(key,image) the new image appear on another button and "slides" to its new position. Does anyone have any idea on how to fix this behavior?

When I run the basic examples, the image update between key press and key release is seamless.

Thanks,

[abcminiuser]

Can someone with a StreamDeck Mini please test the feature_new_encoding branch? If it still works for the Mini I'll be able to simplify a bunch of code.

[michaelkleinhenz]

I just found out that my similar issue #17 is only appearing when using an USB hub. Maybe this is also the issue here?

[michaelkleinhenz]

Ok, more exploring. It's aparrently not the USB hub. The device works before I run the animation example. After running it, it starts behaving weird, does not respond to keys, matches the wrong keys etc. See #17

[abcminiuser]

Sounds like I'm missing a termination flag in the header that resets the buffer in the receive side.

Since it looks like the mini and original share the same frame format, could you try the branch I mention above and see if it works as well as the current code? If it does, I can use that as a reference point and experiment with my Original and see if I can provoke a similar issue.

[abcminiuser]

After I figured out the StreamDeck Original and StreamDeck Mini share the same wire protocol with only orientation and key ordering differences, I did some refactoring. I've now found that I can also trigger the reported partial key image update bug on my original.

I believe I've fixed in in the feature_new_encoding branch for both devices. @michaelkleinhenz feel like testing it out?

[Aetherdyne]

I tested the new branch on my mini, and the basic example appeared to be working just like it always has, even after running the animation example.

That is, the basic example still briefly flashes up an image of whatever button was last drawn or pressed whenever you press a new button, but I didn't notice anything with it ignoring button presses or registering the wrong button.

The animated example does something similar ... before drawing the new frame on the elephant buttons, it shows the CV joint animation. Before drawing a new frame of the cube animation, it draws the elephant. Before drawing a new frame of the CV joint, it draws the cube. I believe it was doing that before.

Once you hit a button to exit the animated example, however, the button images are often left in the wrong state and python sometimes (independently) seems to crash. Generally the wrong state manifests as all of the buttons being blank except one, which shows the portion of the streamdeck logo that should've been in the bottom right position. This button is often corrupted with a vertical slice of a button image, or random colored lines/shapes. It doesn't happen all the time or in the same way every time. I've even seen the stream deck go back to the normal full logo and THEN go blank (along with a python crash).

Because a picture (or video) is worth a thousand words, have a look at the two most recent videos here

[michaelkleinhenz]

I believe I've fixed in in the feature_new_encoding branch for both devices. @michaelkleinhenz feel like testing it out?

@abcminiuser tested the branch and it indeed resolved the issue. The basic example can be run after the animation without issues. Also, I noticed that some jittering on the animation example is also gone, the animation is now flawless. Great work!