Home » Forums » MythDora » Usage

Database check problem

  • user warning: Table './drupal_gding/cache_filter' is marked as crashed and should be repaired query: SELECT data, created, headers, expire, serialized FROM cache_filter WHERE cid = '1:8dfd99540cff953ed4c9b6b0b4a82f85' in /var/www/mythdora/html/includes/cache.inc on line 26.
  • user warning: Table './drupal_gding/cache_filter' is marked as crashed and should be repaired query: UPDATE cache_filter SET data = '<p>My frontend loses connection to the backend every night on my fe/be machine running 10.22. I looked in the logs and discovered that it happens at 0315 every day; exactly when the mysql table check runs. So I disabled it in crontab and now everything works fine. I ran:</p>\n<p>mysqlcheck -A -u mythtv -p</p>\n<p>and it shows that the tables are all OK. I\'m wondering if I\'ve screwed up a permission somehow that causes this problem when the check is run. Suggestions?</p>\n', created = 1369290442, expire = 1369376842, headers = '', serialized = 0 WHERE cid = '1:8dfd99540cff953ed4c9b6b0b4a82f85' in /var/www/mythdora/html/includes/cache.inc on line 109.
  • user warning: Table './drupal_gding/cache_filter' is marked as crashed and should be repaired query: SELECT data, created, headers, expire, serialized FROM cache_filter WHERE cid = '1:1dadde5bad93c390ed7b18cdae3d7be9' in /var/www/mythdora/html/includes/cache.inc on line 26.
  • user warning: Table './drupal_gding/cache_filter' is marked as crashed and should be repaired query: UPDATE cache_filter SET data = '<p>Nope. That\'s by design. It\'s set to the middle of the night to hopefully alleviate interruptions in viewing. The script disables the backend and then runs the mysqlcheck/repair. </p>\n<p>The backend is shutdown to help safeguard the database so that mythbackend/frontend doesn\'t attempt to modify the db during the database dump &amp; check. </p>\n<p>Ryan</p>\n', created = 1369290442, expire = 1369376842, headers = '', serialized = 0 WHERE cid = '1:1dadde5bad93c390ed7b18cdae3d7be9' in /var/www/mythdora/html/includes/cache.inc on line 109.
  • user warning: Table './drupal_gding/cache_filter' is marked as crashed and should be repaired query: SELECT data, created, headers, expire, serialized FROM cache_filter WHERE cid = '1:68529fe217fdf303c9de54ab158c8479' in /var/www/mythdora/html/includes/cache.inc on line 26.
  • user warning: Table './drupal_gding/cache_filter' is marked as crashed and should be repaired query: UPDATE cache_filter SET data = '<p>I first noticed this when I attempted to watch the next day and needed to restart the box to get things working again. So somehow mine is screwed up since even if I restart the backend the frontend won\'t connect to it until I restart the computer.</p>\n', created = 1369290442, expire = 1369376842, headers = '', serialized = 0 WHERE cid = '1:68529fe217fdf303c9de54ab158c8479' in /var/www/mythdora/html/includes/cache.inc on line 109.
  • user warning: Table './drupal_gding/cache_filter' is marked as crashed and should be repaired query: SELECT data, created, headers, expire, serialized FROM cache_filter WHERE cid = '1:80a3710aaefc020c677bb79b19e8646e' in /var/www/mythdora/html/includes/cache.inc on line 26.
  • user warning: Table './drupal_gding/cache_filter' is marked as crashed and should be repaired query: UPDATE cache_filter SET data = '<p>Hmm. Yes that is unusual. You should be able to just back-out of the recordings screen and go back in to get it re-connect. (at least that\'s how my frontends behave typically)</p>\n', created = 1369290442, expire = 1369376842, headers = '', serialized = 0 WHERE cid = '1:80a3710aaefc020c677bb79b19e8646e' in /var/www/mythdora/html/includes/cache.inc on line 109.
Submitted by rmnelson on January 27, 2010 - 12:58pm

My frontend loses connection to the backend every night on my fe/be machine running 10.22. I looked in the logs and discovered that it happens at 0315 every day; exactly when the mysql table check runs. So I disabled it in crontab and now everything works fine. I ran:

mysqlcheck -A -u mythtv -p

and it shows that the tables are all OK. I'm wondering if I've screwed up a permission somehow that causes this problem when the check is run. Suggestions?

‹ VDPAU and x264 videos Mythbackend crashes in the middle of a recording ›

Nope. That's by design. It's

Submitted by pisani on January 27, 2010 - 1:19pm.

Nope. That's by design. It's set to the middle of the night to hopefully alleviate interruptions in viewing. The script disables the backend and then runs the mysqlcheck/repair.

The backend is shutdown to help safeguard the database so that mythbackend/frontend doesn't attempt to modify the db during the database dump & check.

Ryan

»

I first noticed this when I

Submitted by rmnelson on January 27, 2010 - 1:50pm.

I first noticed this when I attempted to watch the next day and needed to restart the box to get things working again. So somehow mine is screwed up since even if I restart the backend the frontend won't connect to it until I restart the computer.

»

Hmm. Yes that is unusual. You

Submitted by pisani on January 27, 2010 - 1:54pm.

Hmm. Yes that is unusual. You should be able to just back-out of the recordings screen and go back in to get it re-connect. (at least that's how my frontends behave typically)

»