<!DOCTYPE html><html><head><style type="text/css">body { font-family:'DejaVu Sans'; font-size:13px}</style></head><body><div>On Sun, 08 Sep 2013 23:44:36 +0100, Raymond Wagner <raymond@wagnerrp.com> wrote:<br><br>> On 9/8/2013 6:05 PM, Roger Siddons wrote:<br>>> db = MythTV.MythDB()<br>>> be = MythTV.BECache(None, False, db)<br>>><br>>> # send advert skiplist to MythPlayers<br>>> tuplelist = [(str(x) + ':' + str(rec.markup.MARK_COMM_START), str(y) +<br>>> ':' + str(rec.markup.MARK_COMM_END)) for x, y in <br>>> rec.markup.getskiplist()]<br>>> mesg = 'COMMFLAG_UPDATE ' + progId + ' ' + ','.join([x for tuple in<br>>> tuplelist for x in tuple])<br>>> result = be.backendCommand("MESSAGE[]:[]" + mesg)<br>>><br>>> Not great code but it was my first attempt at Python and I couldn't find<br>>> any examples to copy...<br>><br>> I've honestly done very little mapping of the event messages, so your <br>> guess is as good as mine about how this one is supposed to function.<br>><br><br>Sorry, I don't understand your comment. If you mean the 'COMMFLAG_UPDATE' event message, then I'm confident it is being received & processed correctly. My query was really about the mechanism of sending the message via the Python bindings, as my Myth sockets don't seem very happy! I thought I might be trying to do something stupid...<br><br>However, looking more closely, I noticed the stupid error in creating my BECache - misplaced parameters - which IIUC meant the script was erroneously registering for system events. Confuses the issue but it's not the whole story...<br><br>>> I did notice <a href="http://www.gossamer-threads.com/lists/mythtv/dev/548233">http://www.gossamer-threads.com/lists/mythtv/dev/548233</a> but<br>>> it's probably the way I'm using the bindings.<br>><br>> This had to do with inserting skip lists directly into the database, so <br>> it would not apply to what you are doing.<br><br>I was referring to the re-use (or not) of connections, as my problem does seem to involve a lot of connection making/breaking. <br><br>I use syslogging, which often invokes rate-limiting (to hide the issue). So today I ran the backend in a terminal to produce <a href="http://paste.ubuntu.com/6083168/">http://paste.ubuntu.com/6083168/</a> . Test was to start up, run a commflaging job (takes 1 min to detect 5 adverts), then idle. I pruned the 16Mb log - when the script terminates the backend spends 5 mins connecting/disconnecting. Initially I thought it was the same socket but there are several in there.</div><div><br></div><div>The script ends with;</div><div><br></div><div> rec = MythTV.Recorded((chanid, starttime), db)<br></div><div><br></div><div> # Signal comflagging has finished<br> rec.commflagged = 1<br> rec.update()<br></div><div><br></div><div>Adding a 1 sec sleep as the last line solves this problem, as shown in <a href="http://paste.ubuntu.com/6083169/">http://paste.ubuntu.com/6083169/</a></div><div><br></div><div>I haven't looked further but I'm wondering if there is an issue with destructors being called 'too soon'. I note the connections are using weakrefs.</div><div><br></div><div>Anyway, I'm content with this workaround. I'll monitor it for a few days.<br><br><br></div></body></html>