BugFixes ... #523
BugFixes ... #523
Conversation
added comments on function
timeout for led color refresh
|
Awesome, let me know when ready and will merge it 👍 |
Why is it needed that the PRs will build? You mean open PRs? |
Klar ist es wichtig, das der Master Branch erzeugt wird. Ich möchte aber auch nicht das Leute die vor mir PRs erstellt haben wegen mir das nachsehen haben. Deshalb hat @RickDB die Leute informiert. |
Ok, verstanden. Macht sinn, danke. |
|
Only 2PRs left to fix, @Paulchen-Panther any ideas what we need to correct for #530 ? |
|
@Paulchen-Panther Btw since you did a considerable amount of work on this would you like to get the team member status on Github and forum? |
|
@RickDB I would feel honored. |
|
I feel it's only right, you've done some great work @Paulchen-Panther |
|
@Paulchen-Panther Awesome, team invite sent 👍 |
|
@RickDB Thank you very much! 😃 |
|
@Paulchen-Panther Is there a way to include the CoreElec patch from PR #534 without it conflicting with our other platforms? Patch is listed here: #534 (comment) |
|
@RickDB |
|
Hello @Paulchen-Panther,
The database itself seemed stable to me. With the signal/slot thing it should also work across threads. Actually you have seen a lot of segfaults for sure while saving/interacting. A reason is the direct access of the threaded webserver to the threaded Hyperion class which interrupts the Hyperion thread in a very dangerous way. You can see this at the stacktraces, it crashes everywhere with no reason (I had further issues with the LED device thread) I implemented the database primarily to remove the need of config files. As a user wish was also to use multiple Hyperion instances at the same time (multiple led devices) with no hassle. After a lot of internal reorganizing the live apply of settings was simply part of it. As i am a huge fan of addons and extensions, a database to save their state and settings was helpful. Especially as we are talking about multiple Hyperion instances which can run each addon on their own with own settings. That would be a mess without (You can handle this but...) :) Was the api auth broken? Probably i didn't pushed the last changes to gh. The system itself is probably slighty oversized. On the other hand some default security might kill no one (for example just local network access to Hyperion by default) I found a .gif of the token system And the state of the webapp (created with Quasar (Vue)), a simple control interface with multi instance support. The coolest thing from my view was the SSDP server detection when compiled for Android. Sadly the overall support of minimum required Android versions is critcal and the performance in a browser is better(!!!) |
|
Hallo @brindosch |
|
The database feature is indeed nice. But I remember that I was not able to compile your work because of a restriction in version compatibility with QT and your DB dirvers. The Feature with the api is also nice and something we should add for security. I also think that the way you implemented the feature is good for us regarding the scope. I also think about setting a password for access the webui. The Webapp is nice! Is there a way to test? This should not replace the webui right? It is more meant for an remote app, right? |
|
Hallo @Paulchen-Panther , Du kannst aber gerne jederzeit einen Gedankenaustausch anstoßen oder nachfragen, sollte was unklar sein. Du hast dich da allerdings schon sehr rein gehangen (Docker,Azure,Travis und co), da gehört schon viel Zeit dazu bis es Resultate gibt (Ich denke mal ich kann das so sagen - als ebenfalls Laie) und so wirklich dankt es keiner. Ich fand das mit redPanther immer ganz toll, ich hatte nur kaum ein Wort verstanden was redPanther immer schrieb, als redPanther ging bin ich mehr in C++ eingestiegen, hab ich davor ja nur etwas am Javascript gebastelt. Alleine programmieren ist ok. Gedankenaustausche oder gegenseitig nachfragen was so Sache ist, dient aber der zusätzlichen Unterhaltung und motiviert. (Damit ist nicht gemeint: Wie lange noch?) Zumindest sehe ich das so. So, genug geplappert @b1rdhous3 I copied the app to the hyperion-project server. But due to nginx settings it won't work, but i didn't contacted @RickDB. The solution is for sure very simple to adapt the settings for a vue app in a subfolder. All in all. The webapp was much more stable than my rework branch 😆 Probably i should start there :) |
|
With our new server nginx is running with kaltura modifications which can a bit shitty to deal with but know that @wolph wants to run vanilla nginx on it again at some point, can of course make any config changes if needed to it or add additional domains if you want as we have plenty of resources on it :) @brindosch We did do some cleaning in the user rights area a while back (forum and github) for inactive admins, if you want to work on Hyperion again just let me know and will restore those 👍 |
|
@brindosch Ich hätte mal eine frage bezüglich der HardwareLedCount Angabe in der config. Für was ist diese Angabe da? Es gibt doch schon ein LED Array in der Config. Warum dann noch mal dieser Wert? |
|
Gerne, der hardwareLedCount wurde eingeführt um LED-Streifen die länger sind als nötig auf schwarz zu setzen (die LEDs die man nicht nutzen will). Das war von jemandem ein Anliegen und redPanther hat es so integriert. Über den Nutzen dieses sehr speziellen falls darf gestritten werden. |
|
Viel Dank für die Erklärung. So ähnlich dachte ich mir das. Entweder hat es nie oder nur kurz funktioniert. Es verhält sich nämlich genau andersrum. Ist der Wert größer, schmiert Hyperion ab und ist der Wert kleiner oder gleich startet Hyperion. |
|
Wo crasht es denn spezifisch? Hab im code nichts gesehen, aber läuft wahrscheinlich irgendwo über den vector index raus? In jedem Fall Hyperion::update() oder eine Initialisierung/settings update das iwas zerhaut Edit: Könnte auch im einem LED Device passieren. Sollte der ledcolor vector größer sein als die ursprünglich angenommene Größe PhilipsHue hatte auch so einen lustigen Fehler. Da hat man sich an der ledconfig entlang geloopt. Wenn die bridge weniger lampen zurück gab als die config, lief der halt ausm index hehe |
|
Also wie gesagt, wenn die Anzahl der LEDs größer ist im hardwareLedCount chrasht es. [hyperiond EFFECTFILES] 36 effects loaded from directory :/effects/ [hyperiond MAIN] Hyperion aborted: Abgesehen davon gibt es auch eine Fehler im WebUI. Wenn der Device type geändert wurde und man startet Hyperion neu, wird immer "file" als type angezeigt. Also Fehler hat NG noch genug. EDIT: Sehe auch gerade in deinem Branch "Rework" ist da auch noch eine Lücke. |
|
Als wäre es erst gestern gewesen. Die Asserts hab ich rausgeworfen und gegen debug statements ersetzt. Da die Methoden nen void zurückgeben, geht ein return. Ich hab den Fehler entweder gefunden oder er ist noch da. Gut wäre es wohl du lässt dir in der Hyperion::update() mal die vector size(s) ausgeben, vielleicht sieht man da was komisches. Eventuell fehlt da ein vector update(), welches nicht auf die ImageToLeds übertragen wird Was das file device angeht. Ich hab jetzt nichts gesehen was auf einen Fehler offenbart. Konntest du eingrenzen ob Hyperion die richtigen Daten liefert oder die ui Blödsinn macht? Ich hab gesehen du hast das signal vom settingsManager auf config Änderung angezapft. In der API ist aber noch der reload drin. Fehlt noch was zur vollständigen live Anwendung der Einstellungen? |
|
Kann sein das du dich da vertan hast? im assert ist es == und im debug statment ist es != ??? |
|
ImageToLedsMap.h:93:getMeanLedColor() |
Verstehe ich nicht. Sorry. |
|
Das ist natürlich nicht die Lösung, aber Hyperion läuft weiter und mit zusätzlichem debug findet man evtl die Lösung. Die Frage ist, tritt das einmal auf oder immer. Ich wollte nur sagen, versuch den assert raus zu machen und so ggf besser das Problem einkreisen zu können. |
|
So, ich habe den Fehler gefunden. |
|
Glückwunsch, vielleicht wäre es sinnvoll, das komplett aus Hyperion::update zu werfen und im handleSettingsUpdate einmalig zu verarbeiten. Die loops dürfen aber nicht mit falschem ledCount laufen :) Da die update() methode ständig aufgerufen wird, wäre das sogar eine kleine Verbesserung in der Leistung. |
Massive overhaul and bugfixes
10 participants
The following changes have been made:
... and many small changes.
Notes: This PR is mostly from @brindosch's and @MartB's rework branch .
After a successful test I have taken over all important changes from Brindosch and MartB.
I will omit not fully functional changes such as the plugin system, the database,
the instance management and the API authentication for the moment.
@wolph, @RickDB, @penfold42, @SJunkies and all other People:
TESTERS WANTED