I thought I'd list what I discovered when originally looking at this
bug. Much of this is mythtv specific. I'm currently of the opinion
that there are issues in both mythtv and mysql, with the mythtv strange
behaviour tickling a mysql issue.
On a problematic boot, mysql starts normally. This me
Hi Will,
Thanks, you're right. Restarting mythtv-backend after reboot (sudo
/etc/init.d/mythtv-backend restart) does bring the schedule back.
Is this bug what is causing my problem?
--
mysql thinks it has crashed when it hasn't
https://bugs.launchpad.net/bugs/326768
You received this bug notif
Barney - could you clarify your comment for me?
You say "Running mythtv-setup, removing all encoder cards and adding
them again fixes this." Is this a permanent fix, or does the problem
recur if you reboot?
If this is only a fix for that boot, there are easier ones. Anything
that causes mythbac
I believe I am also encountering this bug. Running Mythbuntu 9.04 Beta
I find my recording schedule on mythtv is empty after reboot. Running
mythtv-setup, removing all encoder cards and adding them again fixes
this.
Output of "cat syslog | grep mysqld":
Apr 19 11:54:05 barney mysqld[3497]: 0904
Since I upgraded to Jaunty RC, my mythtv database gets corrupted after
almost every new boot. This results into a confused mythtv-backend which
fails to record the scheduled recordings. After a "repair table" command
everything returns back as normal. I'm trying the " & wait" fix
mentioned above, h
Adding mythbuntu. It seems to me that the " & wait" should make things
more reliable and predictable rather than less, so I must be missing
something. Any danger in removing the " & wait"?
** Changed in: mythbuntu
Importance: Undecided => Critical
** Changed in: mythbuntu
Status: New
** Also affects: mythbuntu
Importance: Undecided
Status: New
--
mysql thinks it has crashed when it hasn't
https://bugs.launchpad.net/bugs/326768
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubun
Yeah - it looks to me like Bug 358173 is the same bug.
I find it very strange that this bug only affects mythbackend (all the
possible duplicates seem to reference mythtv). I suspect that it is
doing something strange. I reported a mysql bug because I figured that
the mysql server shouldn't beha
Bug 358173 may be a duplicate of this.
Thanks to the original reporter for proposing a solution.
** Changed in: mysql-dfsg-5.0 (Ubuntu)
Status: Incomplete => Confirmed
--
mysql thinks it has crashed when it hasn't
https://bugs.launchpad.net/bugs/326768
You received this bug notification
Without the fix I mentioned in the original report, mysql gets restarted
once. Obviously mysqld_safe uses some CPU to do this (it will do one
iteration of the loop at the bottom of the script). mysqld_safe is not
looping and restarting mysql multiple times, which is, I think, the
behaviour you we
Thank you for taking the time to report this bug and helping to make
Ubuntu better. When you're running into the issue, does mysqld_safe
takes up 100% of the cpu?
** Changed in: mysql-dfsg-5.0 (Ubuntu)
Status: New => Incomplete
--
mysql thinks it has crashed when it hasn't
https://bugs.la
I can confirm this behavior.
--
mysql thinks it has crashed when it hasn't
https://bugs.launchpad.net/bugs/326768
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubu
12 matches
Mail list logo
