Here is the full fix:
https://github.com/david-mark/EventGhos ... _init__.py
...It hasn't been merged into the official trunk as of yet and occurred to me that it's not the easiest journey from the pull request I linked earlier and this file.
And just in case we do run into trouble when asyncore barfs up the mystery datagram, here's a debug version of handle_read:
Code: Select all
def handle_read(self):
data, addr = self.recvfrom(1024)
# Check if the sending address is any of our interfaces
my_addr = addr[0] in self.addresses
if (not my_addr) or self.selfBroadcast:
print 'Datagram received';
print 'Raw data:';
print [data];
data = data.decode(eg.systemEncoding)
print 'Decoded data:';
print [data];
bits = data.split(self.payDelim);
print 'Split data:';
print bits;
commandSize=len(bits)
print 'Command size:';
print commandSize;
if commandSize==1:
self.plugin.TriggerEvent(bits[0])
if commandSize==2:
self.plugin.TriggerEvent(bits[0],bits[1])
if commandSize>2:
self.plugin.TriggerEvent(bits[0],bits[1:])
...Note that I wrap every output in an array; for whatever reason, it helps to see whether the strings are Unicode objects or plain old "str" objects.
In case anyone wants to give up and have the mysterious (corrupted?) datagrams fail with just a log entry (and without taking down asyncore), this should do the trick:
Code: Select all
try:
if commandSize==1:
self.plugin.TriggerEvent(bits[0])
if commandSize==2:
self.plugin.TriggerEvent(bits[0],bits[1])
if commandSize>2:
self.plugin.TriggerEvent(bits[0],bits[1:])
except:
eg.PrintError('Failed to trigger event!');
KG, perhaps you can expand on the except clause to print the stack trace and anything else that would help? I know you had that in one of your earlier posts, but too tired of this stuff to go back and dig it up. I recall you had recently posted about stack traces that come out of asyncore and how to get the most out of them. Also, I didn't see any inaccurate stack traces when I had exceptions in my original fixes; they always led me straight to the issue. That being said, though I got the same error
messages, I never duplicated the exact stack trace in my testing earlier today. Though have seen it many times over the years, always indicating line 84 of EventGhostEvent.py; which, unless I miscounted yesterday, is off by a few lines from the only culprit in the vicinity (the concatenation I mentioned yesterday).
Could also do something like this on exception:
Code: Select all
eg.TriggerEvent('asyncore.sucks');
...And have it speak or play a sound or whatever as a reminder to check the log for any clues. Mine only had the mystery datagrams every few weeks IIRC; And asyncore logged them in such a way that they were as good as invisible (unlike the red PrintError results), so I didn't event notice this was going on for months. Just noticed that my voice commands and X10 reception from AHP stopped working as those were coming from VC on the same box as EG (in which case I assume UDP is as close to guaranteed delivery as it could be). The whole experience was so mysterious and maddening (as everything else worked virtually 100%), I almost gave up on EventGhost entirely.
Hopefully we won't need any of that exception handling and I will finally be able to remove my workaround that disables and enables the plug-in after a period of inactivity. Thanks to everyone that helped and looking forward to status reports on the latest (last?) fixes, regardless of the outcome.
