[HANG] Deadlock in backend on starting a new recording?

[mythtv@…]

Not sure about this, but maybe a deadlock in some threads? Sometimes scheduled recordings are not recorded and the frontend goes very slow when this happens. Also the recordings screen on the frontend is empty until I restart the backend. I waited about 15-20 minutes here before I restarted.

2011-02-13 15:11:55.225 Reschedule requested for id 0.
2011-02-13 15:11:55.348 Scheduled 17 items in 0.1 = 0.04 match + 0.08 place
2011-02-13 15:12:03.695 Reschedule requested for id -1.
2011-02-13 15:12:03.880 Scheduled 17 items in 0.2 = 0.10 match + 0.08 place
2011-02-13 15:12:24.165 TVRec(1): ASK_RECORDING 1 29 0 0
2011-02-13 15:12:24.805 TVRec(2): ASK_RECORDING 2 29 0 0
2011-02-13 15:21:17.457 AutoExpire: CalcParams(): Max required Free Space: 5.0 GB w/freq: 15 min

As you can see, the "Changing from None to RecordingOnly?" line never showed up.

Any debug-level flags you want me to enable until next time it happens? I've had "important,general" until now, but added "record,channel".

[mythtv@…]

Backtrace on runnig process

[beirdo]

Please attach the version of mythbackend you are running (mythbackend --version)

[beirdo]

Seems to be EIT related. Possibly a dupe of #9261

[mythtv@…]

I used v0.24-158-g48d554e-dirty the last time this happened

Now I have

# mythbackend --version
Please attach all output as a file in bug reports.
MythTV Version   : v0.24-177-g316718a-dirty
MythTV Branch    : branch-fixes/0.24
Network Protocol : 63
Library API      : 0.24.20101129-1
QT Version       : 4.6.3
Options compiled in:
 linux debug using_alsa using_oss using_backend using_bindings_perl using_bindings_python using_dvb using_frontend using_lirc using_mheg using_opengl_video using_opengl_vsync using_qtdbus using_qtwebkit using_v4l using_x11 using_xrandr using_xv using_bindings_perl using_bindings_python using_mythtranscode using_opengl using_ffmpeg_threads using_mheg

And some other info from the backend server, I use separate frontend/backend system.

# snippet from /proc/cpuinfo
vendor_id       : AuthenticAMD
cpu family      : 15
model           : 95
model name      : AMD Athlon(tm) Processor LE-1600
stepping        : 3
cpu MHz         : 2209.887

# grep -i dvb /var/log/dmesg
DVB: registering new adapter (Satelco EasyWatch DVB-C MK3)
DVB: registering adapter 0 frontend 0 (Philips TDA10023 DVB-C)...
DVB: registering new adapter (Satelco EasyWatch DVB-C MK3)
DVB: registering adapter 1 frontend 0 (Philips TDA10023 DVB-C)...

# uname -a
Linux vdr-be 2.6.34-gentoo-r1 #1 SMP Tue Jul 27 10:26:21 EEST 2010 i686 AMD Athlon(tm) Processor LE-1600 AuthenticAMD GNU/Linux

[mythtv@…]

Got some more logs now with more verbose flags.

Happened again yesterday while watching LiveTV and a recording was about to start. LiveTV show froze and the recording did not start so I restarted backend so the recording could start as seen around 2011-02-18 22:02 in the log.

Still on v0.24-177-g316718a-dirty

[mythtv@…]

Log with more verbose flags

[stuartm]

This should at least get looked at once before 0.25 is out

[Stuart Auchterlonie]

Unfortunately i'm not going to get a chance to look at it.

[danielk]

The problem here appears to be the mysql server going out to lunch.