Opened 16 years ago

Closed 16 years ago

#5231 closed defect (invalid)

mythbackend stops working in some way

Reported by: udovdh@… Owned by: Isaac Richards
Priority: minor Milestone: unknown
Component: mythtv Version: unknown
Severity: low Keywords: stops responding
Cc: Ticket locked: no

Description

Hello,

Myhtbackend keeps running but stops recording/responding. When clicking in mythweb for the backend status I get the attached error screen. I have three custom searches running, each recording a national Dutch public TV channel.

MythTV Version : exported MythTV Branch : trunk Library API : 0.22.20080320-2 Network Protocol : 40 QT Version : 4.3.3 Options compiled in:

linux release using_oss using_alsa using_backend using_dbox2 using_dvb using_firewire using_frontend using_hdhomerun using_iptv using_ivtv using_joystick_menu using_lirc using_opengl_vsync using_v4l using_x11 using_xrandr using_xv using_xvmc using_xvmcw using_xvmc_vld using_bindings_perl using_bindings_python using_opengl using_ffmpeg_threads using_libavc_5_3 using_live

Attachments (1)

mythbug.txt (9.7 KB) - added by udovdh@… 16 years ago.
the errors plus some mytbackend log

Download all attachments as: .zip

Change History (11)

Changed 16 years ago by udovdh@…

Attachment: mythbug.txt added

the errors plus some mytbackend log

comment:1 Changed 16 years ago by anonymous

Mythbackend is indeed still running: # ps -ef|grep mythbackend root 17676 1 11 14:42 ? 00:30:53 /usr/bin/mythbackend --daemon --logfile /var/log/mythtv/mythbackend.log --pidfile /var/run/mythbackend.pid root 20530 16258 0 19:01 pts/2 00:00:00 less /var/log/mythtv/mythbackend.log root 20537 32430 0 19:04 pts/0 00:00:00 grep mythbackend

as is the database: # ps -ef|grep sql root 16916 1 0 14:25 pts/2 00:00:00 /bin/sh /usr/bin/mysqld_safe --datadir=/var/lib/mysql --socket=/var/lib/mysql/mysql.sock --log-error=/var/log/mysqld.log --pid-file=/var/run/mysqld/mysqld.pid mysql 16970 16916 6 14:25 pts/2 00:17:09 /usr/libexec/mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --pid-file=/var/run/mysqld/mysqld.pid --skip-external-locking --socket=/var/lib/mysql/mysql.sock root 20539 32430 0 19:05 pts/0 00:00:00 grep sql

As is apache: # ps -ef|grep http root 1897 1 0 Apr10 ? 00:00:28 /usr/sbin/httpd apache 9511 1897 0 04:05 ? 00:00:29 /usr/sbin/httpd apache 9513 1897 0 04:05 ? 00:00:36 /usr/sbin/httpd apache 12243 1897 0 06:22 ? 00:00:23 /usr/sbin/httpd apache 12256 1897 0 06:22 ? 00:00:22 /usr/sbin/httpd apache 16054 1897 0 13:32 ? 00:00:16 /usr/sbin/httpd apache 16781 1897 0 14:15 ? 00:00:03 /usr/sbin/httpd apache 16784 1897 0 14:15 ? 00:00:02 /usr/sbin/httpd

comment:2 Changed 16 years ago by anonymous

There is program listing data, there is enough CPU and RAM.

comment:3 Changed 16 years ago by udovdh@…

Last evening I restarted mythbackend, this morning (about 12 hours later) again mythbackend stops reacting. just after 1 o' clock (am that is)

comment:4 Changed 16 years ago by anonymous

I have the same problem running latest 0.21-fixes. I'm using 2 DVB-C tuners and multirec (total of 6 tuners in myth, 3 virtual on each hw tuner). The mythbackend process is alive but it don't accept connections from frontends/mythweb. What is the best log setting to capture a log of this problem?

comment:5 Changed 16 years ago by udovdh@…

On my system this issue does not appear anymore since a few changes were made. Went to 0.21-fixes (although at first other issues remain also with that version). Changed the three power searches somewhat so that they are limited w.r.t. amount of data to search: channel.callsign = "NL1" AND program.starttime < DATE_ADD( NOW( ) , INTERVAL 8 HOUR ) Now the system quite reliably continuously records all three dutch public TV channels NL1/2/3. The root of the cause may be related to the scheduler, I suppose. I have 5-7 days of program info, updated each morning. Maybe you have more program info?

comment:6 Changed 16 years ago by ksalmela@…

I think I have the same problem. I had two DVB-C cards, and it happened every now and then, then the other card broke down and I removed the broken one from the box. The problem disappeared, until now when I did put in a new card and started seeing it again. It may or may not have something to do with database, since the error condition seems to clear if I stop and start mysql.

comment:7 Changed 16 years ago by danielk

Priority: majorminor
Severity: mediumlow
Status: newinfoneeded_new
Version: unknown

We need the mythbackend log to have any idea what's going on here.

comment:8 Changed 16 years ago by anonymous

I did put on database debugging on mythbackend and there are a LOT of these queries while system is 'idle' (EIT crawling?):

2008-06-25 08:16:05.666 MSqlQuery: SELECT chanid, useonairguide FROM channel, dt v_multiplex WHERE serviceid = ? AND networkid = ? AND

transportid = ? AND channel.mplexid = dtv_multiplex.mplexid

2008-06-25 08:16:05.667 MSqlQuery: SELECT chanid, useonairguide FROM channel, dt v_multiplex WHERE serviceid = ? AND networkid = ? AND

transportid = ? AND channel.mplexid = dtv_multiplex.mplexid

2008-06-25 08:16:05.667 MSqlQuery: SELECT chanid, useonairguide FROM channel, dt v_multiplex WHERE serviceid = ? AND networkid = ? AND

transportid = ? AND channel.mplexid = dtv_multiplex.mplexid

2008-06-25 08:16:05.719 MSqlQuery: SELECT chanid, useonairguide FROM channel, dt v_multiplex WHERE serviceid = ? AND networkid = ? AND

transportid = ? AND channel.mplexid = dtv_multiplex.mplexid

2008-06-25 08:16:06.179 MSqlQuery: SELECT chanid, useonairguide FROM channel, dt v_multiplex WHERE serviceid = ? AND networkid = ? AND

transportid = ? AND channel.mplexid = dtv_multiplex.mplexid

2008-06-25 08:16:06.231 MSqlQuery: SELECT chanid, useonairguide FROM channel, dt v_multiplex WHERE serviceid = ? AND networkid = ? AND

transportid = ? AND channel.mplexid = dtv_multiplex.mplexid

2008-06-25 08:16:06.537 MSqlQuery: SELECT chanid, useonairguide FROM channel, dt v_multiplex WHERE serviceid = ? AND networkid = ? AND

transportid = ? AND channel.mplexid = dtv_multiplex.mplexid

.. so I took a look at dtv_multiplex table and there are apparently incorrect (duplicate) entries in the db (possibly from crashed channel scans or something). I will try to fix the db tables and report back if I can reproduce the problem.

comment:9 Changed 16 years ago by udo

For me 21-fixes didn't show this specific issue (yet).

comment:10 Changed 16 years ago by stuartm

Resolution: invalid
Status: infoneeded_newclosed

Requested information not provided.

Note: See TracTickets for help on using tickets.