[mythtv-users] writeStringList error no data written on writeBlock (Python bindings?)

[Roger Siddons]

On Thu, 12 Sep 2013 02:16:57 +0100, Mark Perkins <perkins1724 at hotmail.com>  
wrote:

>
> I believe these events relate to slave backends but I have none.
>
> [Mark] I also have no slave backends.

That was a red herring. The 'slave backend' event is always generated  
whenever a connection dies, even when there are no slaves.

>
> [Mark]  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 (>1000 on rough guess) MainServer::ANN Monitor /  
> MainServer::ANN Playback / 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.

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.

>
> [Mark] So IIUIC the hypothesis is that each time silence.py updates the  
> skiplist and flags that an update has been made it gets a new socket to  
> >the database.  But that socket doesn’t automatically close immediately  
> after the write so the number of open sockets increases until the  
> >number of permitted sockets is reached then things start to fail (which  
> of course happens quicker if multiple instances of silence.py are  
> running >all calling their own sockets – or if other MythTV elements are  
> trying to also access the database). So two possible solutions would be  
> to either >work out how to reuse a socket so that only one was needed  
> per execution of the silence.py script or work out how to close a socket  
> >immediately after it has been used so that there is not too many open  
> at the same time?

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.

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.

My solution is much better/simpler - delay the end of the script!
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;

# Signal comflagging has finished
rec.commflagged = 1
rec.update()
import time
time.sleep(1)

if __name__ == '__main__':
    main()

Let me know if it works for you.

>
> [Mark]  Thanks again for your response, it has given me much to think  
> about which is far better than staring at the screen and scratching my  
> >head.

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).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mythtv.org/pipermail/mythtv-users/attachments/20130912/ce44f145/attachment-0001.html>