-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Josh Burks wrote: | I've been playing with this a little, and found a different workaround: | | 1. rename /etc/rc5.d/S86mythbackend to S96mythbackend | 2. edit /etc/init.d/mythbackend and change the following line: | | from | # chkconfig: - 86 14 | | to | # chkconfig: - 96 04 | | This will delay the startup of the backend so that the channels will | change correctly. | I tried it and rebooted half a dozen times, worked every time.
I had a similar problem. It looks to me like the backend was starting before the ivtv driver was loaded, so I just made sure to load the driver early in the init process, and I've not had that problem since.
jason
Thanks to all for pointing this problem out. I have a different theory though. MySQL is not starting up soon enough, and that's leaving Myth in a weird state.
I recently downgraded by mythbackend to a Sempron 2200 from a 2800 and I noticed recordings weren't changing the channel from the default which is 4, even the watch TV tuner was stuck. This caused me to miss some TV. Very annoying. I noticed if I restarted mythbackend it was able to change channels again. I took a quick look at mysql and it has a start up of chkconfig of 90, exactly the same as the default for mythbackend.
On the faster CPU, MySQL started up quick enough this wasn't an issue. Since mythbackend is dependent on MySQL it is better to make sure the DB is up and running before we try and start it. Moving to a slower chip made the race condition more apparent. The fix is we need to make mythbackend start up after MySQL, not at the same time. I changed mythbackend to start at 99 and deleted and added the chkconfig entry and everything seems to be fine again.
I guess we need to add this to a FAQ or Jarod's guide.
Yan _______________________________________________ mythtv-users mailing list [email protected] http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
