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

Roger Siddons dizygotheca at ntlworld.com
Mon Sep 9 13:00:59 UTC 2013


On Sun, 08 Sep 2013 23:44:36 +0100, Raymond Wagner <raymond at wagnerrp.com>  
wrote:

> On 9/8/2013 6:05 PM, Roger Siddons wrote:
>> db = MythTV.MythDB()
>> be = MythTV.BECache(None, False, db)
>>
>> # send advert skiplist to MythPlayers
>> tuplelist = [(str(x) + ':' + str(rec.markup.MARK_COMM_START), str(y) +
>> ':' + str(rec.markup.MARK_COMM_END)) for x, y in 
>> rec.markup.getskiplist()]
>> mesg = 'COMMFLAG_UPDATE ' + progId + ' ' + ','.join([x for tuple in
>> tuplelist for x in tuple])
>> result = be.backendCommand("MESSAGE[]:[]" + mesg)
>>
>> Not great code but it was my first attempt at Python and I couldn't find
>> any examples to copy...
>
> I've honestly done very little mapping of the event messages, so your 
> guess is as good as mine about how this one is supposed to function.
>

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...

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...

>> I did notice http://www.gossamer-threads.com/lists/mythtv/dev/548233 but
>> it's probably the way I'm using the bindings.
>
> This had to do with inserting skip lists directly into the database, so 
> it would not apply to what you are doing.

I was referring to the re-use (or not) of connections, as my problem does  
seem to involve a lot of connection making/breaking.

I use syslogging, which often invokes rate-limiting (to hide the issue).  
So today I ran the backend in a terminal to produce  
http://paste.ubuntu.com/6083168/ . 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.

The script ends with;

rec = MythTV.Recorded((chanid, starttime), db)

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

Adding a 1 sec sleep as the last line solves this problem, as shown in  
http://paste.ubuntu.com/6083169/

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.

Anyway, I'm content with this workaround. I'll monitor it for a few days.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mythtv.org/pipermail/mythtv-users/attachments/20130909/86415332/attachment.html>


More information about the mythtv-users mailing list