[mythtv] FW: Ticket #10541: SIGSEGV when EIT updating DB and channel change

Angela angela.schmid at wolke7.net
Sun Apr 15 16:52:09 UTC 2012


>> Mythbackend didn't hang today. I observed only one time a situation 
>> where EIT was updating and a recording started, however it had a 
>> strange starting time (18:41) and I didn't see a recording with this
date. Will keep you informed.
>> 
>> I think not everything is logged (I think I have seen many occasions). 
>> I use the configuration /etc/rsyslog.d/40-mythtv.conf from 
>> http://www.mythtv.org/wiki/Rsyslog_Configuration
>> Just wonder if other people observe the same ? Is logging threadsafe ?
>
>In the last 4 days I had only one occasion, which was handled by the patch
successful. However, the recording started 1.5 minutes
>later, as you can  see from the log
http://code.mythtv.org/trac/ticket/10541 . Why does the recording earliest
start, when the DB
>writing is finished ?

Hello

No crashes anymore. However I see mythbackend hanging, which I have seen in
the past also without this patch. 
I restarted mythbackend. EIT passive scanning started (17:39:26). A
recording was asked (17:39:39). EIT writing from 17:40:01 till 17:43:16.
During this time mythweb was not responding. Socket errors were protocolied
at 17:43:31. Recording was canceled 17:43:32. Mythweb did not respond. A yet
started mythfrontend had a long time to scan the recordings in watch
recordings. Had to restart mythbackend.

During "EITCache: Wrote 14 modified entries of 252 for channel 1002 to
database" messages, I think mythbackend comes unresponsive, this behaviour
has been seen before, also without this patch.
This time the recording has been canceled. In my previous comment, the
recording started 1.5 minutes later.

Run with " /usr/bin/mythbackend --syslog local7 --user mythtv -v eit,general
--loglevel debug". 
Attached mythbackend.zip and gdb1.txt (gdb -p <pid>).
Why does mythbackend hang.

Angela

p.s. Why does MythTV not reuse prepared statements ? For each
insert/update/delete as far as I have seen, the SQL command is prepared on
each call. Why not preparing it once and reuse it. Sure needs some
re-preparing when the connection has to be re-astablished. Writing 2000 EIT
records needs 3 Minutes, which is in my eyes very long. This is on a Sandy
Bridge 2600K.




More information about the mythtv-dev mailing list