[mythtv-users] channel confusion

[Stephen Worthington]

On Sat, 6 Mar 2021 09:40:23 -0800, you wrote:

>I launched mythfrontend on the same machine that hosts the backend and
>database.  The whole machine locked up.  When I restarted it I found that
>the listing for channel 65.2 (qubo) was just a copy of the listing for 66.3
>(Bounce).
>
>I looked in the logs for myth and for the database (mariadb).  The latter
>show recovery from a crash, but other than that I see nothing that looks
>related.
>
>Tried mythfilldatabase --refresh all.  No change.  Waited a day so that it
>could fetch new listings, but the last available listings still show the
>same pattern.
>
>There is at least one related report about problems like this with
>Schedules Direct, https://code.mythtv.org/trac/ticket/11509 which
>references
>http://lists.mythtv.org/pipermail/mythtv-users/2013-March/347938.html, but
>that's from before the XML TV grabber.  So I'm not sure it's relevant.
>
>I'd love to hear about solutions, or even about how I could figure out
>where things have got mucked up.
>
>Thanks.
>Ross
>
>Setup:
>backend is 30.0-dmo4 with some code I backported so I could use Python 3.
>I use SchedulesDirect in the US with tv_grab_zz_sdjson
>Debian/buster

The most common cause of whole machine crashes and lockups when
running mythfrontend is a problem with the video drivers.  However,
that usually occurs when you are playing a recording or a video file,
rather than immediately on running mythfrontend.

When you restart your machine after any lockup or shutdown failure or
power failure (any situation where the system did not get to shut down
properly and flush all the data to disk), you need to do a full check
and repair of the filesystems and a full check and repair of the
database.  If you do not do that, then you run the risk of having file
system corruption or database corruption.  If you always do the checks
and repairs immediately, the problems will usually be easily repaired,
but if you fail to check, an existing corruption can cause further
corruption which can then become unrepairable.

The normal procedure for doing full filesystem checks requires that
you boot from a different partition (if you have more than one
bootable system on the PC), or boot from a live disk or USB, or use a
PXE network boot.  The reason for this is that there is no way to do a
filesystem check on the boot partition while the system is running
from it.  Even using grub to boot into "repair mode" (if your system
has that sort of menu item) will not allow fsck to repair the boot
partition.  From your alternative boot, you need to run "fsck -C -f"
on all the partitions that were mounted at the time of the crash.  If
fsck does any repairs, you have to run it again and again until there
are no errors reported.

Once you have done the file system repairs, then you can boot into the
normal system again, but it is best to not allow mythbackend to start
as that will use the database before it can be repaired.  To prevent
that happening, while you are still booted from your alternative
system, you can mount the normal system partition and delete the link
that systemd uses to start mythbackend.  In Ubuntu, this is:

/etc/systemd/system/multi-user.target.wants/mythtv-backend.service

The name of the mythbackend service and the location of such links can
vary between systems.  I think on Fedora the mythbackend service is
just called "mythbackend.service" for example.

If you are unable to do that, then it is best to shut down mythbackend
as soon as possible after booting the normal system.  On Ubuntu this
is:

sudo systemctl stop mythtv-backend

Adjust the command for the correct name of the systemd unit on your
system.

Then you should run the database check and repair script
optimize_mythdb.pl.  This is usually installed as part of the MythTV
packages.  In Ubuntu it is found here:

/usr/share/doc/mythtv-backend/contrib/maintenance/optimize_mythdb.pl

and you really should also have a copy in /etc/cron.daily (normally
renamed as optimize_mythdb) so that it is automatically done every
day.  It can be run from either copy.  If optimize_mythdb succeeds in
repairing any problems, you can then enable and start mythbackend:

sudo systemctl enable mythtv-backend
sudo systemctl start mythtv-backend

If optimize_mythdb fails, then you will need to try manual repairs -
look at the mysqlanalyze, mysqlcheck and mysqlrepair commands.

Your report of having had a full system partition is a red flag - that
often causes database corruption.  Since that happened to me, I now
run an hourly systemd task that checks my free space and emails me if
it is getting too low.

However, database corruption is unlikely to cause a system lockup.
Filesystem corruption certainly can, but is less likely than video
driver problems.