Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Alpha 8 - LED's retain last state after clearing a source #1007

Closed
1 task done
flexage opened this issue Sep 15, 2020 · 9 comments · Fixed by #1008
Closed
1 task done

Alpha 8 - LED's retain last state after clearing a source #1007

flexage opened this issue Sep 15, 2020 · 9 comments · Fixed by #1008
Assignees
Labels

Comments

@flexage
Copy link

flexage commented Sep 15, 2020

  • I confirm that this is an issue rather than a question.

Bug report

Steps to reproduce

I'm using Apa102's driven from the pi 3, I also have a second instance on the same install using WLED but this doesn't seem to be affected).

Test 1

  1. Start Hyperion (Rainbow Startup Animation Plays)
  2. Rainbow startup animation finishes, and LED's turn off for a moment, but then come back with a frozen rainbow

Test 2

  1. Set a colour using the Web UI Remote control (LED's successfully show the colour)
  2. Clear the colour source set in the Web UI (the source disappears from the source panel, but the LED's remain the colour set)

Test 3

  1. Set a colour using the Web UI Remote control (Led's show the colour ok)
  2. Send a Protocol Buffers/Hyperion Android Grabber stream (Led's are matching the video source fine)
  3. Stop the android grabber (Sources panel reflects Grabber source is gone but Led's freeze on last frame of stream, should be showing the lower priority colour source from the web ui now).

What is expected?

I expect that clearing the sources for effects, colours, and streams will also clear the LED's and not just the sources panel.

What is actually happening?

It looks like, with the APA102's at least, then when a source is cleared, it's final values are retained on the LED's - or sometimes cleared from the LED's momentarily, but then return.

System

Hyperion Server:

Hyperion Server OS:

  • Distribution: Raspbian GNU/Linux 10 (buster)
  • Arch: arm
  • Kernel: linux (4.19.97-v7+ (WS: 32))
  • Browser: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.102 Safari/537.36
@Lord-Grey Lord-Grey added needs investigation Further testing is required and removed Waiting For Review labels Sep 15, 2020
@Lord-Grey Lord-Grey self-assigned this Sep 15, 2020
@Lord-Grey
Copy link
Collaborator

Hi @flexage
thanks for your feedback. To track down the issue, may I ask you providing an export of your configuration:

via UI: Configuration->General->Import/Export Configuration-> click "Export"

Plus, could you set hyperion.ng in Debug mode logging and share the log output, please?

via UI: System->Log-> Set Log-Level = Debug

If you familiar doing things on the commandline, you might start hyperion in debug mode already and have the loglines at hand easily:

pkill hyperiond
hyperiond -d

Restart hyperion.ng, run Test 1 and 2 and share the log-output.
I assume all three test scenarios share the same root cause. Therefore, lets focus on the first two.

Thank you!

@Lord-Grey
Copy link
Collaborator

Hi @flexage

Just one additional question:

I assume that you have defined a "Refresh time for the LED device

image

Could you set it to zero and see, if the problem still exists.

image

Just to ring-fence the problem.

Thank you!

@Lord-Grey
Copy link
Collaborator

Hi @flexage I think I found the error. Let me apply a fix and get back to you for testing.

@flexage
Copy link
Author

flexage commented Sep 15, 2020

Hi @Lord-Grey, great work! Sorry for not being quicker at getting back to you, I'll be available this evening (GMT) to provide any info and do any testing, please feel free to log anything you require here after looking at your fix and I'll be happy to provide it

@Lord-Grey
Copy link
Collaborator

Lord-Grey commented Sep 15, 2020

@flexage May I ask you testing PR #1008 and report back, please?

You can download the executable package via the PR's artifacts.

@Lord-Grey Lord-Grey added Bug and removed needs investigation Further testing is required labels Sep 15, 2020
@flexage
Copy link
Author

flexage commented Sep 15, 2020

@Lord-Grey Great work dude! Just tested the Debian RPi 2/3 build from the PR and that code change seems to have fixed it 👍

I'll keep using this build for now, and let you know if I spot any related edge cases

@Lord-Grey
Copy link
Collaborator

@flexage Good to hear that it is working at your end. Thanks for your support bringing it up and doing the testing.

@flexage
Copy link
Author

flexage commented Sep 15, 2020

No problem, happy to help, thanks for all the great work on Hyperion

Lord-Grey added a commit that referenced this issue Sep 25, 2020
* Save BLACK as lastLedColor during writeBlack

* Remove debug statement overhead

* Re-Add typecasting to ensure readable output

* Revert "New language support: Russian and Chinese (simplified)"

This reverts commit 5c95fab.

* Ignore TemporaryError
@flexage
Copy link
Author

flexage commented Dec 24, 2020

Sorry, it looks like I confirmed this as fixed to soon...

I ended up staying on Alpha 6 for a while as it was the most stable for me, but tonight I have been trying Alpha 9.

I am still getting the last frame of the video effect/color/protobuffer output 'sticking' on my LED's when the source is cleared.

I checked the "Refresh Time" on the LED Device, as you mentioned above, and it was set to 5000 - must have been a default, potentially from a very old (pre-alpha) version, I had to enable expert settings to find it. I tried setting it to 0 but it didn't have an effect on the problem.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants