EG intermittently reverts to default xml

If you have a question or need help, this is the place to be.
Post Reply
jongbray
Posts: 3
Joined: Tue Jul 09, 2019 11:14 am

EG intermittently reverts to default xml

Post by jongbray » Tue Jul 09, 2019 11:53 am

I'm using EG 0.4.1.r1722 and Windows 10 (version 1803, with the last cumulative update done on 12/6/2019 - this has been going on for a while though so I couldn't tell you the version numbers when it started).

Installed plugins are Autoremote, Speech, Keyboard, Timer and Webserver. Process watcher is installed but currently disabled.

At the moment EG is set to autostart, but via a shortcut in the start menu (all the compatibility options in the shortcut properties are unticked, ie EG is not currently running as admin - IIRC if I tick that it asks for confirmation first, which doesn't really work for my purposes (one of which is to be able to remotely boot the computer and then start a game server via a website).

Sometimes (like today for instance) it loads my tree fine. Other times I find it has quietly loaded the default tree instead.

The first bit of the log is an error; the traceback is

ActionItem.py L121 in SetArguments self.compiled=self.exectutable.Compile(*args)
PythonScript.py L71 in _init_ self.PrintTraceback()
PythonScript.py L97 in PrintTraceback treeItem.PrintError("Traceback (most recent call last):")
AttributeError: "'NoneType' object has no attribute 'PrintError'

- However as this is the log on an instance when everything continues to load I'm not sure how useful it would be.

The only other error I'm seeing is an "Error checking for AutoRemote plugin updates" - but AR does appear to be working fine.

I'm guessing that there is an intermittent fatal error which is causing EG to load default next time, and as (because I don't notice when it happens) its not obviously replicable I'm not expecting miracles WRT easy fixes (if anyone is feeling particularly miraficent though, be my guest) but:

1.) Is this an acceptable way of loading EG or does it silently break something somewhere?

2.) Is there any way to edit the default xml (so that it at least puts up a warning message when its loaded)? I did a computer wide search for it but can't find it anywhere, so it strikes me it might be created on the fly.


Cheers.

Jon

jongbray
Posts: 3
Joined: Tue Jul 09, 2019 11:14 am

Re: EG intermittently reverts to default xml

Post by jongbray » Wed Jul 10, 2019 6:40 pm

I think I might actually have worked out what is doing this.

I have an Alexa command "Trigger shutdown" which sends a system shutdown command to Eventghost via Autoremote, but then about 10 seconds later also sends a command to an arduino which turns off the RF socket powering my computer, monitor, lights, etc*. This works fine when the computer has already shut down by this point, but if its a bit slow the power is lost before the computer has shut down completely, and I think this might be what is causing the issue.

I'll try tweaking the delay between the two and see if this sorts it.

*Yes, I used to use one of those devices which detected a drop in the current being drawn from the computer and used that to depower other devices, but after upgrading my graphics card it started behaving erratically (turning off monitors while I was in the middle of something). Replacing the device didn't sort the problem. Besides, my way has more nerd cred. When it works :-)

User avatar
kgschlosser
Site Admin
Posts: 5508
Joined: Fri Jun 05, 2015 5:43 am
Location: Rocky Mountains, Colorado USA

Re: EG intermittently reverts to default xml

Post by kgschlosser » Wed Jul 10, 2019 9:57 pm

you need to update your EG to 0.5 because you are running on Windows 10 you can end up with "phantom" type bugs that will appear. This is fixed in eg0.5

That error you encountered is caused by a Python Script action This was a long standing bug in EG and has been repaired in 0.5 as well. The issue with that error is it is an error that gets generated from another error, The problem as is there used to be no way to identify what Python Script action was causing the error. In eg 0.5 if you see an error for a Python Script action in the log the actual script that is causing the error is going to be automatically selected in your tree. So pay attention when starting EG. Python Script action errors that occur at startup are typically syntax related issues in the script. because the script gets compiled when EG starts up is the reason the error occurs. Another time you will see errors is when you "OK" the Python Script dialog. The errors have also been "upgraded" and it will tell you the line number that the error is on. So be sure to read the whole error as it can give you clues as to what is wrong.
If you like the work I have been doing then feel free to Image

User avatar
kgschlosser
Site Admin
Posts: 5508
Joined: Fri Jun 05, 2015 5:43 am
Location: Rocky Mountains, Colorado USA

Re: EG intermittently reverts to default xml

Post by kgschlosser » Wed Jul 10, 2019 10:07 pm

You also need to be very careful when using any of the System.* events. You do not want to use any of the System.* events to process any lengthy macros. and definitely DO NOT use a wait in any macro that contains a System.* event. This is because of how the Windows notification system works. You cannot stall the Windows notification system. this is going to cause a cascading failure in EG. and it may not happen right away but over time it will.

I have been trying figure out a way to deal with this problem I have not been able to come up with a good solution. The reason is if you want to run a task based on a windows notification typically you want it done right away. so placing that notification into a queue and releasing the notification system will cause you to perform actions after whatever the notification was for has been carried out.

Here is an example. If you have a macro with the "System.Monitor.On" event in it. and in that macro you have the Find Window Action looking for a specific application window and if the window does not exist then you want to start the application.

This is going to cause a cascading failure because the Find Window action is a beast and it takes a while to sift through every single "Window class" object being displayed. If you take a look in the Find Window action you can see all of the objects.. there are actually about 3 times more then what you see in that list. So this takes a long while to do. and because of the stall EG will start to crash and the Windows notification system may get a little out of sorts until EG does finally give up and crash. So if you have anything macros like the one above it is best to use the Syste,.* action and trigger another event with it. and then use that event to process your macro. this will release the notification system correctly.

That is about the best solution I have for the problem at hand.
If you like the work I have been doing then feel free to Image

User avatar
kgschlosser
Site Admin
Posts: 5508
Joined: Fri Jun 05, 2015 5:43 am
Location: Rocky Mountains, Colorado USA

Re: EG intermittently reverts to default xml

Post by kgschlosser » Wed Jul 10, 2019 10:11 pm

I had a thought. I can upgrade the Trigger Event action some more. add the option "move to the front of the line" this will place that event next in line. so it will process right after the macro that called it. This way if your EG happens to be super active.. receiving lots of events and processing lots of macros "important" events will be able to get processed faster.
If you like the work I have been doing then feel free to Image

dan Edens
Experienced User
Posts: 110
Joined: Mon Sep 24, 2018 7:57 pm

Re: EG intermittently reverts to default xml

Post by dan Edens » Wed Jul 10, 2019 10:34 pm

kgschlosser wrote:
Wed Jul 10, 2019 10:11 pm
I had a thought. I can upgrade the Trigger Event action some more. add the option "move to the front of the line" this will place that event next in line. so it will process right after the macro that called it. This way if your EG happens to be super active.. receiving lots of events and processing lots of macros "important" events will be able to get processed faster.
Process priority option is one of the big things I love about Tasker and would use the shit out of it here. Good idea.

User avatar
kgschlosser
Site Admin
Posts: 5508
Joined: Fri Jun 05, 2015 5:43 am
Location: Rocky Mountains, Colorado USA

Re: EG intermittently reverts to default xml

Post by kgschlosser » Thu Jul 11, 2019 4:49 am

Ultimately there would be no need to have that feature. I already have a running version of EG that runs each event in it's own thread. the events are the core of EG. and the event is what causes other things to run. Right now EG only has a single thread that the events get processed in. so only one can get processed at a time. Here is an example of why this is not a good idea. In my house I have several HTPC's all of these HTPC's are controlled by a single "server" EventGhost. the remotes are also handled by the same EG... EG has what is called an enduring event. these events are used is the device gives you an on and off status.. some remotes will have a pressed and a released. An enduring event can be used to loop and the loop will exit hen the event is told to stop. (because the button was released). Now this is good in theory but in practice it is not good. Because of the single event thread if you loop for say a volume up button being pressed no other event will get processed. So if i am holding down the volume down on HTPC 1 remote and then someone else using the HTPC2 remote wants to change the channel they cannot. Not until I release the volume button. But if the second person presses the button and nothing happens they will press it again and again and again.. and when I finally release the volume button.. surprise surprise everything starts going nuts doing all of the things that were queued.

I set it up so that only a single thread can exists for an event. so you will not end up with conflicts between 2 threads running the same macros. if an event comes in that there is already a running thread for then the event will get queued and run in the same thread as the event that is currently running. it does not end the thread and then start a new one to much additional overhead to do that.

The hard part actually is this.. How do you keep the logging correct.. and how do you display it to the user? The log you see now in EG in my version only shows events that have run. no macros and no actions. and the entries for the events never go away until you restart EG. if you click on one of the events it expands to show you everything that has been run.

Another tricky bit was how do we deal with variables like eg.event which is what holds the currently running event, It can only hold on object at a time.. or can it?? well since the only thing that would want to access the event would be running in the thread the event created. we use the id of the thread to hand back the proper data. so in essence eg.event is a shared object and it changes depending on what thread is asking for the data contained in it.

I really do want to do more work on that version of EG. I started working on it a long while ago. I have a lot more working knowledge of python now then i did back then. I have only been programming for about 3.5 years or so. (I think it's 3.5 years) and i started working on that when i was roughly a year and a half to 2 years in.
If you like the work I have been doing then feel free to Image

User avatar
kgschlosser
Site Admin
Posts: 5508
Joined: Fri Jun 05, 2015 5:43 am
Location: Rocky Mountains, Colorado USA

Re: EG intermittently reverts to default xml

Post by kgschlosser » Thu Jul 11, 2019 5:04 am

and as far as the default XML thing...

Let me explain how UAC works in Windows. When you right click on the EG icon and select "run as administrator" it will run EG with administrative privileges. or so you think that is what it does. This is not what it does. It actually creates a terminal session and then loggs in the administrator to that session. an RDP (remote desktop) session is also a terminal session. The difference between RDP and run as is that only the application is shown with run as. run as is effectively a remote desktop connection and that connection has signed in with a different user..

So if you loging to you computer with the username "Bob" and you change the wallpaper to a photo of the moon.. and then you logout.. and then a family member sits down and logs in with their username.. say it's a daughter or wife.. and the username is "Sandy" when the user "Sandy" logs in is their wallpaper going to be that picture of the moon??.. No it will not be. each user has it's own saved settings. same goes with EG. so changes to the settings made using "run as administrator" are not going to populate to all the other users. If you upgrade to EG 0.5 when you start it one of the first events is going to be the user name that is logged in when EG started. if you then close EG and run it as Administrator. it is going to tell you that the Administrator is logged in. We added this feature in EG so EG can behave differently based on who is logged into the session when EG is run. There are also events that occur if someone RDP's into the PC that EG is running on. and the event will tell you who it is.. This is a great feature for remote administration. you would want EG to disable any macros that could bump heads.. like setting the PC volume if they try to do it at the same time some not so nice things will happen. You can end up with the 2 instances of EG fighting each other and you would most likely end up with a BSOD.

So make sure the default xml thing is not happening because of a different user launching EG. or you running EG as administrator..

The other thing is.. check the location you are saving the config tree to. if the location is anywhere in the user profile another user will not be able to access the file.. and EG will then open the default file..
If you like the work I have been doing then feel free to Image

jongbray
Posts: 3
Joined: Tue Jul 09, 2019 11:14 am

Re: EG intermittently reverts to default xml

Post by jongbray » Thu Jul 11, 2019 1:38 pm

First off, many thanks - that was obviously a lot of thinking / typing time on your part with very little delay and much appreciated (do let me know if you fancy installing my new kitchen, because I wish the guy who is supposed to be doing it responded as quickly and as thoroughly!)

Just to clarify, the wait command is actually done arduino side, but that stuff about the system.* commands being usable with caution is worthwhile knowing.

Thanks for the explanation of "Run as Administrator" - it sounds like that tidbit will be handy not only for EG but for other misbehaving (or in this case properly behaving I guess) apps (I've done a few VB ones myself but they just read/write to the home directory of the application, which works fine for single-user scenarios, but I can see how you kinda have to do things properly with things as flexible as EventGhost!

User avatar
kgschlosser
Site Admin
Posts: 5508
Joined: Fri Jun 05, 2015 5:43 am
Location: Rocky Mountains, Colorado USA

Re: EG intermittently reverts to default xml

Post by kgschlosser » Thu Jul 11, 2019 8:10 pm

Sorry to hear about the Kitchen remodel not going so well...

The funny thing is I do not conform to the typical IT guy persona. I do construction/remodel kind of work and I have the callouses to prove it too.
I am an odd bird when it comes to construction... I treat anything I work as if I am working on it for me. So detail is of utmost importance. I am not fast when working. But I am accurate. An example would be when I was leveling my house. my house is 60 years old and I leveled it out. Houses settle over time and it needs to be corrected. Now most contractors will say that a house is level if it is within 1 to 1.5" variation over 30ish feet. My house is less then 1/8" variation across 30ish feet. and I didn't have all of the fancy tools they have to do that kind of work. I had ratchet straps, automotive bottle jacks, 8 foot bubble level, string bubble levels, a shovel and a pick axe. took me a month to get it that way. partly because I had to pull the house up hill. and I only made 1/8" adjustments a day..

Here is a photo of the electrical panel I installed in my house..
28514853_10211631217161810_4375031472564032471_o.jpg
and this is what is typically seen in a house.
electrical_panel.jpg
needless to say I probably didn't finish my installation in the same amount of time as the guy that did the panel in the bottom photo..

I have been told I have a disorder.. I actually took all of the twists out of the wiring that is run through my house. it all lays flat and is attached at least every 14.5"

I am very detail orientated and I also like to provide as much information as I can. You as the person receiving this information need to be fully "educated" so you can make whatever decision is needed. You cannot make a proper decision without having all of the information. The same thing applies to every aspect of life. In order to track down the cause of a problem both you and I alike need to be given all of the information. I have come to realize that the easiest problems to solve are always the most difficult to solve because something gets "assumed" or overlooked.

In order to track down what is happening in this case you will need to document exactly what you are doing when the problem occurs.. You can also add the /debug command line switch to your eventghost icon for both the startup group and the icon you use to start EG.. This is going to make a very detailed debugging output that gets saved into %appdata%/eventghost/log.txt

This file can become very large so be sure to delete it every so often if the problem has not occurred. You will need to shutdown EG to delete the file
If you like the work I have been doing then feel free to Image

Post Reply