<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="MS Exchange Server version 14.02.5004.000">
<title>RE: [mythtv-users] writeStringList error no data written on writeBlock (Python bindings?)</title>
<style type="text/css">body { font-family:'DejaVu Sans'; font-size:13px}</style>
</head>
<body>On Thu, 12 Sep 2013 02:16:57 +0100, Mark Perkins <perkins1724@hotmail.com> wrote:<br><br><blockquote style="margin: 0 0 0.80ex; border-left: #0000FF 2px solid; padding-left: 1ex">
<p dir="LTR"><span lang="en-au"><font size="2" face="DejaVu Sans">I believe these events relate to slave backends but I have none.</font></span></p>
<p dir="LTR"><span lang="en-au"><b><i><font color="#1F497D" face="Calibri">[Mark]</font></i></b></span><span lang="en-au"> <font face="Calibri">I also have no slave backends.</font></span></p></blockquote><div><br></div><div>That was a red herring. The 'slave backend' event is always generated whenever a connection dies, even when there are no slaves.</div><div><br></div><blockquote style="margin: 0 0 0.80ex; border-left: #0000FF 2px solid; padding-left: 1ex">
<p dir="LTR"><span lang="en-au"><b><i><font color="#1F497D" face="Calibri">[Mark]</font></i></b></span><span lang="en-au"> <font face="Calibri"> Thanks for the response Roger, greatly appreciated. And yes you are 100% spot on I am getting quite a significant number of those info messages</font></span><span lang="en-au"><font face="Calibri"> (>1000 on rough guess)</font></span><span lang="en-au"><font face="Calibri"> MainServer::ANN Monitor</font></span><span lang="en-au"> <font face="Calibri">/ MainServer::ANN Playback /</font></span><span lang="en-au"><font face="Calibri"> adding: xxxxx as a client. I didn’t understand the significance of those messages but yes I am a heavy user of the silence commflagging script (essentially for all my commflagging). And I have allowed up to 3 concurrent jobs so I could quite easily have 3 real time commflag jobs in progress at the same time.</font></span></p></blockquote><div><br></div><div>The problem occurs when a commflag job finishes. If 2 or more finish at the same time (quite common with my schedules) then the poor BE will be really thrashing.</div><div><span lang="en-au"> </span></div><blockquote style="margin: 0 0 0.80ex; border-left: #0000FF 2px solid; padding-left: 1ex">
<p dir="LTR"><span lang="en-au"><b><i><font color="#1F497D" face="Calibri">[Mark]</font></i></b></span><span lang="en-au"> <font face="Calibri">So IIUIC the hypothesis is that each time silence.py updates the skiplist and flags that an update has been made i</font></span><span lang="en-au"><font face="Calibri">t gets a new socket to the database. But that socket doesn’t automatically close immediately</font></span><span lang="en-au"><font face="Calibri"> after the write</font></span><span lang="en-au"><font face="Calibri"> so the number of open sockets</font></span><span lang="en-au"> <font face="Calibri">increases until the number of permitted sockets is reached then things start to fail</font></span><span lang="en-au"><font face="Calibri"> (</font></span><span lang="en-au"><font face="Calibri">which of course</font></span><span lang="en-au"><font face="Calibri"> happens quicker if multiple instances of silence.py are run</font></span><span lang="en-au"><font face="Calibri">ning all calling their own sockets</font></span><span lang="en-au"><font face="Calibri"> – or if other MythTV elements are trying to also access the database</font></span><span lang="en-au"><font face="Calibri">)</font></span><span lang="en-au"><font face="Calibri">. So two possible solutions would</font></span><span lang="en-au"> <font face="Calibri">be to</font></span><span lang="en-au"> <font face="Calibri">either</font></span><span lang="en-au"> <font face="Calibri">work out</font></span><span lang="en-au"> <font face="Calibri">how to reuse a socket so that only one was needed per execution of the silence.py script o</font></span><span lang="en-au"><font face="Calibri">r</font></span><span lang="en-au"><font face="Calibri"> work out how to close a socket immediately after it has been used so that t</font></span><span lang="en-au"><font face="Calibri">here is not too many open at the same time</font></span><span lang="en-au"><font face="Calibri">?</font></span></p></blockquote><div><br></div><div>No. My reply to Raymond was a bit obscure but I now think there is no problem with the backend skiplist messages themselves. It occurs when the script finishes - this seems to screw the backend connections as it tries to tidy up the sockets that were being used. This seems to cause a 'socket hangup', of which one of the first noticeable symptoms is the skiplist messages of other commflag jobs fail with writeStringList errors. IIRC you also complained of FE connection failures.</div><div><br></div><div>I suspect the objects of the python script are being destroyed before the python bindings have finished doing its networking business. But I haven't looked further.</div><div><br></div><div>My solution is much better/simpler - delay the end of the script! </div><div>I've been monitoring it for a few days and haven't seen a single error since. I might try to avoid the problem by rearranging the script but the brute force fix is to simply add a sleep to the end of silence.py, so that it now looks like this;</div><div><br></div><div># Signal comflagging has finished<br> rec.commflagged = 1<br> rec.update()<br></div><div><strong>import time</strong></div><div><strong>time.sleep(1)</strong></div><div><strong><br></strong>if __name__ == '__main__':<br> main()</div><div><br></div><div>Let me know if it works for you.</div><div><br></div><blockquote style="margin: 0 0 0.80ex; border-left: #0000FF 2px solid; padding-left: 1ex">
<p dir="LTR"><span lang="en-au"><b><i><font color="#1F497D" face="Calibri">[Mark]</font></i></b></span><span lang="en-au"><b><i> </i></b></span><span lang="en-au"> <font face="Calibri">Thanks again for your response, it has given me much to think about which is far better than staring at the screen and scratching</font></span><span lang="en-au"><font face="Calibri"> my head.</font></span></p>
</blockquote><div><br></div><div>Thanks for raising the issue. I saw these errors a long time ago but, as they had no impact on my system/usage, it wasn't at the top of my list. And no-one else had commented, so I rather assumed it was just a feature of my much-neglected system (a brand spanking new 0.27 is planned when time allows).</div><div><br></div><br><br></body></html>