When I manually turn off the lights nothing happens.

[MadKane87]

After starting Prismatik "turn off lights" function works like a charm, but after some time, when I want to turn LEDs off I need to press Prismatik icon few times. Prismatik creates strings in log file: 19:23:18:003 Warning: QObject::startTimer: Timers cannot be started from another thread 19:23:19:373 Warning: QObject::startTimer: Timers cannot be started from another thread 19:23:20:767 Warning: QObject::startTimer: Timers cannot be started from another thread Time mark coincides with time when "turn off lights" function fails to work.

Sorry for bad English.

[psieg]

I can reproduce the timer message, but the lights do turn off. Do you double-click or right-click "turn off"?

Which device are you using? Can you please provide a full log?

[MadKane87]

I've tried both options: doubleclicking and right-click "turn off" - problem is absolutely same. I've tried to run Prismatik as administrator - no changes. By the way "turn on lights" function works fine - LEDs switching on without any delay and problems. I'm using Adalight as my ambilight device. First I thought: maybe problem in my arduino, cable or sketch, so I installed Ambibox to test - LEDs switching off without issues. Here is my log file Prismatik.0.log

[dmadison]

This is mostly an Adalight issue with WS2812B LEDs, not a Prismatik one. Mostly.

I have this same issue, and did some investigating last year. It turns out that Prismatik is working properly and does send the off frame when you ask it to. But it sends it immediately, and not spaced evenly with the rest of the frames. So at low grab intervals (high framerates) the "off" serial data will be queued immediately after the previous frame. This means that the 6-byte header data for the "off" frame is lost during the LED latch. The microcontroller never sees the start of the frame, discards the "off" color data bytes, and the lights stay on.

The solution is to add some sort of flow control (#117), or to use LEDs that don't require disabling interrupts. Prismatik could also send multiple "off" frames or wait a short time after the last calculated frame before sending the off frame, but those are more band-aid solutions.

Turn down your grab rate to something like 50 ms and try again. The lights should turn off fine, assuming you don't spam the on/off button.

[MadKane87]

My grab rates already set at 50 ms, I've tried to slow down it to 300 ms - still have problems, nothing changed. Now I'm testing old Woodenshark's build (30 Sep 2014): LEDs switching off perfectly - no matter how fast I spam Prismatik icon

[dmadison]

That's quite strange. At 300 ms my lights will turn on and off as fast as I can press the button.

Can you provide more info about your setup? Baud rate, # of LEDs, LED type, etc.?

[MadKane87]

My setup: chineese Arduino Uno, 178 of WS2812B type LEDs, baudrate is 115200, resolution 3840x2160, Windows 10 Pro

[dmadison]

The low baud rate in tandem with the large number of LEDs is making things more difficult, because you're more likely to get dropped frames. But other than that I don't know why you'd have different results with the other software, unless the frame timing is significantly delayed.

My lights don't always turn off, but it's due to the issue I mentioned above. Every time I've tried sniffing the serial comms the software sends a blank frame without fail. Maybe psieg has some insight.

[psieg]

@MadKane87 Since you tested with the offical Prismatik version and that works: does it work if you run WinAPI grabbing or moodlight mode?

[MadKane87]

Yes, I have tried WinAPI mode, now I can't download old Prismatik from GitHub to test, cause our goverment forced internet providers to block Amazon IPs, sorry. Maybe tomorrow when this mess is over.

[psieg]

@MadKane87 is this still a problem?

[qwertccc]

@MadKane87 any update？

[psieg]

Closing some old issues, sorry for the spam, if any.

[taboo180]

Hi psieg. Thanks so much for keeping this project alive. I just got my first LED set up and I was so pleased to see your last update was only a few weeks ago.

I too am facing this same issue. If I turn off the lights rarely it's instant, most the time all the colours go away and they all default to a standard white, then, exactly 59-60 seconds later, they finally actually turn off.

I have noticed that if I set the "overall brightness" to anything below 8% they all instantly turn off so I know it's possible, it just seems to be the "turn off command" takes a full minute to action. Which also means they stay on when I lock or shut down my computer for that time.

The kit I have is a cheap Chinese one (that I'm 95% sure is arduino based). I am running "adalight" mode. 50ms grab interval. Win8 desktop duplication. No DX Hooking. Baud 115200 and RGB colour format.

[AndreySeleznov]

I have the same setup and experience this issue as well. "adalight", 50ms, Win8 desktop duplication. No DX Hooking. Default 115200 baud, RGB color. Profiles do not seem to matter, happens with static, dynamic, capture profiles. Usually lights turn off fine when I recently turned off the lights but after some time instead of going off they go white. I discovered that more often than not, switching profile after that makes them turn off finally. Thanks for your efforts psieg! Hope you could look into this.

[davhaa15]

I have the same setup and experience this issue as well. "adalight", 50ms, Win8 desktop duplication. No DX Hooking. Default 115200 baud, RGB color. Profiles do not seem to matter, happens with static, dynamic, capture profiles. Usually lights turn off fine when I recently turned off the lights but after some time instead of going off they go white. I discovered that more often than not, switching profile after that makes them turn off finally. Thanks for your efforts psieg! Hope you could look into this.

Mine has the same behavior! Glad you figured out switching profiles, at least now I have a temporary way to turn the lights off.