Mailing List Archive

On 11/02/06, Yan Seiner <yan@seiner.com> wrote:
> I have a question about channels...
>
> I have two cards in my backend; an analog card and a digital card. Both
> receive signals OTR.
>
> I've set up my zap2it accounts, and I am getting information....
> Unfortunately, there seems to be a mismatch between what myth scans and
> what zap2it provides.... I suspect this is what is causing my frontends
> to segfault and my recording schedule to be wrong...
>
> KEPB (28) (Analog)
> KEPB-HD (281) (Digital) <- scan
> KEPB-SD (282) (Digital) <-scan
> KEPBDT (KEPB-DT) (28_1) (Digital) <-zap2it
> KEPBDT2 (KEPB-DT2) (28_2) (Digital) <-zap2it
>
> Basically every digital channel has a duplicate, one from zap2it and one
> from scanning.... How should I resolve this?

I'm not US-based so can't provide a categorical answer, but I would
imagine that a new channel definition containing the tuning
information provided by the 'scan' channel definition and the naming
information provided by the zap2it channel definition should provide a
working channel. This 'idea' is based on the fact you need the tuning
information to ensure the digital card can successfully tune to the
channel, and need the zap2it information to ensure ensure listings
can be retrieved for the given channel.

Nick
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

On 2/10/06, Yan Seiner <yan@seiner.com> wrote:
>
> I have a question about channels...
>
> I have two cards in my backend; an analog card and a digital card. Both
> receive signals OTR.
>
> I've set up my zap2it accounts, and I am getting information....
> Unfortunately, there seems to be a mismatch between what myth scans and
> what zap2it provides.... I suspect this is what is causing my frontends
> to segfault and my recording schedule to be wrong...
>
> KEPB (28) (Analog)
> KEPB-HD (281) (Digital) <- scan
> KEPB-SD (282) (Digital) <-scan
> KEPBDT (KEPB-DT) (28_1) (Digital) <-zap2it
> KEPBDT2 (KEPB-DT2) (28_2) (Digital) <-zap2it
>
> Basically every digital channel has a duplicate, one from zap2it and one
> from scanning.... How should I resolve this?
>


I had this same problem and resolved by taking the XMLTV ids from the zap2it
channels, putting them in the scanned channel XMLTV id, then making the
zap2it channels non-visible to the channel list

Nick wrote:

> On 2/10/06, *Yan Seiner* <yan@seiner.com <mailto:yan@seiner.com>> wrote:
>
> I have a question about channels...
>
> Basically every digital channel has a duplicate, one from zap2it
> and one
> from scanning.... How should I resolve this?
>
>
>
> I had this same problem and resolved by taking the XMLTV ids from the
> zap2it channels, putting them in the scanned channel XMLTV id, then
> making the zap2it channels non-visible to the channel list

Could you break that down a bit for a myth newbie? Do I dump the data
from mySQL or use the channel editor? Is there a way to copy and paste
in the channel editor? How do I make a channel invisible?

I thought I had this figured out, my test recording went fine, but this
AM recordings failed and the backend cannot tune any digital
channels.... :-(

--Yan
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

On Sun, Feb 12, 2006 at 04:15:10PM -0800, Yan Seiner wrote:
> Nick wrote:
> > On 2/10/06, *Yan Seiner* <yan@seiner.com <mailto:yan@seiner.com>> wrote:
> > I have a question about channels...
> >
> > Basically every digital channel has a duplicate, one from
> > zap2it and one from scanning.... How should I resolve this?
> >
> > I had this same problem and resolved by taking the XMLTV ids from
> > the zap2it channels, putting them in the scanned channel XMLTV id,
> > then making the zap2it channels non-visible to the channel list
>
> Could you break that down a bit for a myth newbie? Do I dump the
> data from mySQL or use the channel editor? Is there a way to copy
> and paste in the channel editor? How do I make a channel invisible?

You can use MySQL directly, or use the mythfrontend channel editor,
but the simplest way is probably to use mythweb channel editor (see
"Settings" in the top navigation bar).

--Rob

It looks as if things internal to the myth database are not the problem.
In the channel table each of the mixed up channels has a different xmltvid,
freqid, and mplexid. Each has the same sourceid (I have only 1).
In dtv_multiplex each mplexid has its own frequency.

Looking in the program table, the first overlap (same show at same time)
was 2021-02-27 06:00, although it doesn't seem to have become regular until
2021-02-28 18:30:00. So the recent lockup may have nothing to do with the
problem. The entries could have been mangled after they were created, but
my notes show I noticed problems with 65.3 listings on 02-28 just after I
created a rule. This was NOT while mythfilldatabase was running, which
does suggest a local problem.

I had a bunch of network problems in the week before that, and the
partition the database was on filled a month before that.

And I haven't made any attempt to verify what's in ~mythtv/.mythtv/cache,
which has lots of stuff for mythfilldatabase.

On Sat, Mar 6, 2021 at 9:40 AM Ross Boylan <rossboylan@stanfordalumni.org>
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
>
>
>

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.
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On 07/03/2021 03:58, Stephen Worthington wrote:
> 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.

The way I do this is to configure all of my filesystems (I use ext4
across the board) to be checked at every boot, by means of the -c 1
parameter to tune2fs. Including the root fs (from which the system also
boots).

For this not only to check but also repair, it is necessary to specify
fsck.repair=yes on the kernel command line.

I take the following as evidence that it does indeed work:

# dumpe2fs -h /dev/nvme0n1p1 | grep "ount count"
dumpe2fs 1.44.1 (24-Mar-2018)
Mount count: 1
Maximum mount count: 1

That is: I'm assuming that the mount counter wouldn't be reset to 1 if
the check&repair of the root fs were skipped. I haven't investigated
this in any detail, but I suspect that the root fs check is performed
before it is mounted r/w and pivoted to.

HTH, Jan
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On Sun, 2021-03-07 at 08:12 +0100, Jan Ceuleers wrote:

That is: I'm assuming that the mount counter wouldn't be reset to 1 if
the check&repair of the root fs were skipped. I haven't investigated
this in any detail, but I suspect that the root fs check is performed
before it is mounted r/w and pivoted to.

At least on Debian it does indeed happen from the initramfs before / is
mounted:

$ lsinitramfs /boot/initrd.img| grep fsck
usr/sbin/e2fsck
usr/sbin/fsck
usr/sbin/fsck.ext4
usr/sbin/reiserfsck

I suppose /usr/share/initramfs-tools/hooks/fsck is responsible for
making this happen.

Ian.

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On Sun, 7 Mar 2021 08:12:06 +0100, you wrote:

>On 07/03/2021 03:58, Stephen Worthington wrote:
>> 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.
>
>The way I do this is to configure all of my filesystems (I use ext4
>across the board) to be checked at every boot, by means of the -c 1
>parameter to tune2fs. Including the root fs (from which the system also
>boots).

That must make it really slow to boot, even if it can fsck the drives
in parallel. I could not do that, as the full fsck time for my worst
partition (a JFS one) is over 10 minutes. I think it is a lot more
actually, but I have never waited around for it to finish to find out.
I just go away and do something else and come back much later.
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On 07/03/2021 12:33, Stephen Worthington wrote:
>> The way I do this is to configure all of my filesystems (I use ext4
>> across the board) to be checked at every boot, by means of the -c 1
>> parameter to tune2fs. Including the root fs (from which the system also
>> boots).
>
> That must make it really slow to boot, even if it can fsck the drives
> in parallel. I could not do that, as the full fsck time for my worst
> partition (a JFS one) is over 10 minutes. I think it is a lot more
> actually, but I have never waited around for it to finish to find out.
> I just go away and do something else and come back much later.

Yes, my strategy may not suit everyone because of the time spent
checking the disks. But I would still recommend doing this at least on
the boot/root partition, or in general on all partitions that contain
data you value. Whether MythTV recordings fit that description or not is
a matter of personal preference.

Having said that, on my system the fscks don't take long because all my
disks are SSDs (except for the one I store the dirvish backups on --
that's spinning rust).
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

Thanks everyone for your responses. Both the file system check on reboot
and the check and repair of the database happen automatically, though I'm
not sure if mythbackend knows or is forced to wait for the database repair
to complete. I use journaled file systems (ext4 and xfs) and so the
filesystem check and repair process is a lot faster than it would otherwise
be.

To my original question, there seems to be a simple answer: the listings
are correct. qubo and IonPlus ceased operation on Feb 28 according to
https://en.wikipedia.org/wiki/Qubo (or Feb 26 according to
https://www.xfinity.com/support/articles/ion-and-qubo-unavailable), even
though I see no sign of this on their website
https://ionmedia.com/business/qubo. And the channel was used for other
content, Bounce being one of them. It's unclear if that will be the case
long-term; it would be convenient for me since I generally get better
reception for 65 than 66.

Finally, I inadvertently recorded a show on 65.2 and it was the same as the
one on 66.3.

About the relative timing for myth and the database, here's the mariadb
error.log after the crash:
2021-03-05 20:02:13 0 [Note] InnoDB: Buffer pool(s) load completed at
210305 20:02:13
2021-03-05 20:02:18 41 [ERROR] mysqld: Table './mythconverg/record' is
marked as crashed and should be repaired
2021-03-05 20:02:18 41 [Warning] Checking table: './mythconverg/record'
2021-03-05 20:02:19 42 [ERROR] mysqld: Table './mythconverg/oldrecorded' is
marked as crashed and should be repaired
2021-03-05 20:02:19 42 [Warning] Checking table:
'./mythconverg/oldrecorded'
## many more like this
2021-03-05 20:05:22 105 [ERROR] mysqld: Table
'./mythconverg/recordedartwork' is marked as crashed and should be repaired
2021-03-05 20:05:22 105 [Warning] Checking table:
'./mythconverg/recordedartwork'
2021-03-05 20:05:29 61 [ERROR] mysqld: Table './mythconverg/recordedfile'
is marked as crashed and should be repaired
2021-03-05 20:05:29 61 [Warning] Checking table:
'./mythconverg/recordedfile'

Over 3 minutes for the repairs.

Here are highlights from the mythbackend log:
2021-03-05 20:02:20.666674 I [3561/3561] CoreContext mythcontext.cpp:900
(TestDBconnection) - Start up testing connections. DB 192.168.1.10, BE ,
attempt 0, status dbAwake, Delay: 2000
# maybe next line implies some info obtained from DB?
2021-03-05 20:02:26.024289 I [3561/3561] CoreContext schemawizard.cpp:120
(Compare) - Current MythTV Schema Version (DBSchemaVer): 1350

2021-03-05 20:02:26.043584 N [3561/3561] CoreContext main_helpers.cpp:605
(run_backend) - MythBackend: Starting up as the master server.
# and perhaps this too?
2021-03-05 20:02:55.759209 I [3561/3561] CoreContext programinfo.cpp:2555
(CheckProgramIDAuthorities) - Found 1 distinct programid authorities
# Housekeeper DBCleanup, or maybe LogClean, sounds as if it might be about
DB repair, but clearly start after repairs are underway
2021-03-05 20:02:55.759574 I [3561/3561] CoreContext housekeeper.cpp:649
(RegisterTask) - Registering HouseKeeperTask 'LogClean'.
2021-03-05 20:02:55.759600 I [3561/4026] Scheduler mythdbcon.cpp:458
(getStaticCon) - New static DB connectionSchedCon
2021-03-05 20:02:55.806085 I [3561/3561] CoreContext housekeeper.cpp:649
(RegisterTask) - Registering HouseKeeperTask 'DBCleanup'.
# many other housekeeping tasks registered
2021-03-05 20:02:55.890349 I [3561/3561] CoreContext housekeeper.cpp:722
(Start) - Starting HouseKeeper.
2021-03-05 20:02:56.136280 I [3561/3561] CoreContext serverpool.cpp:415
(listen) - Listening on TCP 0.0.0.0:6544
2021-03-05 20:02:56.138746 I [3561/3561] CoreContext serverpool.cpp:415
(listen) - Listening on TCP [::]:6544
2021-03-05 20:02:56.138814 I [3561/3561] CoreContext serverpool.cpp:415
(listen) - Listening on TCP 0.0.0.0:6554
2021-03-05 20:02:56.138866 I [3561/3561] CoreContext serverpool.cpp:415
(listen) - Listening on TCP [::]:6554
2021-03-05 20:02:56.139662 I [3561/3561] CoreContext serverpool.cpp:415
(listen) - Listening on TCP 0.0.0.0:6549
2021-03-05 20:02:56.139728 I [3561/3561] CoreContext serverpool.cpp:415
(listen) - Listening on TCP [::]:6549
# rescheduling would seem to require DB access, although repairs are not
complete
2021-03-05 20:02:58.856573 I [3561/4026] Scheduler scheduler.cpp:2356
(HandleReschedule) - Reschedule requested for MATCH 0 0 0 - SchedulerInit
2021-03-05 20:03:00.597200 I [3561/4026] Scheduler scheduler.cpp:2472
(HandleReschedule) - Scheduled 898 items in 1.7 = 0.38 match + 1.15 check +
0.13 place
2021-03-05 20:03:00.732540 I [3561/4026] Scheduler scheduler.cpp:2530
(HandleRunSchedulerStartup) - Scheduler: AUTO-Startup assumed
2021-03-05 20:03:01.612374 C [3561/3561] CoreContext programinfo.cpp:347
(ProgramInfo) - ProgramInfo(): Failed to find recorded entry for 0.
2021-03-05 20:03:01.819030 I [3561/3561] CoreContext
bonjourregister.cpp:117 (BonjourCallback) - Bonjour: Service registration
complete: name 'Mythbackend on barley' type '_mythbackend._tcp.' domain:
'local.'
2021-03-05 20:03:01.947243 I [3561/3648] TVRecEvent tv_rec.cpp:1652
(HandlePendingRecordings) - TVRec[4]: ASK_RECORDING 4 0 0 0
2021-03-05 20:03:02.260543 I [3561/3650] TVRecEvent tv_rec.cpp:1652
(HandlePendingRecordings) - TVRec[6]: ASK_RECORDING 6 0 0 0
2021-03-05 20:03:06.800021 I [3561/4040] Commflag_18637 jobqueue.cpp:2343
(DoFlagCommercialsThread) - JobQueue: Commercial Detection Starting for
"Weather Gone Viral":"Man Versus Weather" recorded from channel 23601 at
2021-02-28T07:58:00Z
2021-03-05 20:03:06.804308 I [3561/4042] SystemManager
mythsystemunix.cpp:276 (run) - Starting process manager
2021-03-05 20:03:06.804268 I [3561/4043] SystemSignalManager
mythsystemunix.cpp:509 (run) - Starting process signal handler
2021-03-05 20:03:06.804374 I [3561/4044] SystemIOHandlerR
mythsystemunix.cpp:92 (run) - Starting IO manager (read)
2021-03-05 20:03:06.804904 I [3561/4045] SystemIOHandlerW
mythsystemunix.cpp:92 (run) - Starting IO manager (write)
2021-03-05 20:03:11.907278 I [3561/4051] Commflag_18799 jobqueue.cpp:2343
(DoFlagCommercialsThread) - JobQueue: Commercial Detection Starting for
"Hawaii Five-0":"Ka'ili Aku" recorded from channel 26501 at
2021-03-06T02:58:00Z
2021-03-05 20:03:56.077921 I [3561/3561] CoreContext housekeeper.cpp:740
(Run) - Queueing HouseKeeperTask 'DBCleanup'.
2021-03-05 20:03:56.077928 I [3561/3561] CoreContext housekeeper.cpp:740
(Run) - Queueing HouseKeeperTask 'JobQueueRecover'.
2021-03-05 20:03:56.077929 I [3561/3561] CoreContext housekeeper.cpp:740
(Run) - Queueing HouseKeeperTask 'LogClean'.
2021-03-05 20:03:56.080723 I [3561/4673] HouseKeeping housekeeper.cpp:142
(Run) - Running HouseKeeperTask 'ThemeUpdateNotifications'.
2021-03-05 20:03:57.603952 I [3561/4673] HouseKeeping
backendhousekeeper.cpp:389 (DoRun) - Loading themes for trunk
2021-03-05 20:03:57.603965 I [3561/4673] HouseKeeping housekeeper.cpp:160
(Run) - HouseKeeperTask 'ThemeUpdateNotifications' Finished Successfully.
2021-03-05 20:03:57.606269 I [3561/4673] HouseKeeping housekeeper.cpp:142
(Run) - Running HouseKeeperTask 'DBCleanup'.
2021-03-05 20:04:15.269424 N [3561/4027] Expire autoexpire.cpp:261
(CalcParams) - AutoExpire: CalcParams(): Max required Free Space: 1.0 GB
w/freq: 15 min
2021-03-05 20:04:56.100880 I [3561/4872] HouseKeeping housekeeper.cpp:142
(Run) - Running HouseKeeperTask 'JobQueueRecover'.
2021-03-05 20:04:56.102410 I [3561/4872] HouseKeeping housekeeper.cpp:160
(Run) - HouseKeeperTask 'JobQueueRecover' Finished Successfully.
2021-03-05 20:04:56.103101 I [3561/4872] HouseKeeping housekeeper.cpp:142
(Run) - Running HouseKeeperTask 'LogClean'.
2021-03-05 20:04:56.103862 I [3561/4872] HouseKeeping housekeeper.cpp:160
(Run) - HouseKeeperTask 'LogClean' Finished Successfully.
2021-03-05 20:05:21.210745 I [3561/4906] ProcessRequest mainserver.cpp:1780
(HandleAnnounce) - MainServer: MainServer::ANN Monitor
2021-03-05 20:05:21.210752 I [3561/4906] ProcessRequest mainserver.cpp:1785
(HandleAnnounce) - MainServer: adding: barley(564a68f69a10) as a client
(events: 0)
2021-03-05 20:05:21.210868 I [3561/4907] ProcessRequest mainserver.cpp:1780
(HandleAnnounce) - MainServer: MainServer::ANN Monitor
2021-03-05 20:05:21.210874 I [3561/4907] ProcessRequest mainserver.cpp:1785
(HandleAnnounce) - MainServer: adding: barley(564a68f6a490) as a client
(events: 0)
2021-03-05 20:05:21.211488 I [3561/4906] ProcessRequest mainserver.cpp:1780
(HandleAnnounce) - MainServer: MainServer::ANN Monitor
2021-03-05 20:05:21.211493 I [3561/4906] ProcessRequest mainserver.cpp:1785
(HandleAnnounce) - MainServer: adding: barley(564a68f4eaa0) as a client
(events: 1)
2021-03-05 20:05:21.211561 I [3561/4907] ProcessRequest mainserver.cpp:1780
(HandleAnnounce) - MainServer: MainServer::ANN Monitor
2021-03-05 20:05:21.211567 I [3561/4907] ProcessRequest mainserver.cpp:1785
(HandleAnnounce) - MainServer: adding: barley(564a68f65440) as a client
(events: 1)
## DBCleanup task finishes after last cleanup in maria logs
2021-03-05 20:05:29.307447 I [3561/4673] HouseKeeping housekeeper.cpp:160
(Run) - HouseKeeperTask 'DBCleanup' Finished Successfully.
# although some activity appears to have preceded the cleanup
# recording does not start until it's done.
2021-03-05 20:05:29.472933 I [3561/3647] TVRecEvent tv_rec.cpp:1091
(HandleStateChange) - TVRec[3]: Changing from None to RecordingOnly


Ross

On Sun, 7 Mar 2021 11:53:49 -0800, you wrote:

>Thanks everyone for your responses. Both the file system check on reboot
>and the check and repair of the database happen automatically, though I'm
>not sure if mythbackend knows or is forced to wait for the database repair
>to complete. I use journaled file systems (ext4 and xfs) and so the
>filesystem check and repair process is a lot faster than it would otherwise
>be.

Have you done some special setup to cause the filesystems and database
to be fully checked automatically at boot? If not, then it is not
happening.

What happens at boot time for the filesystems is that any partition
that is marked as dirty (having been written to but not shut down
properly) will have its journals processed. This is *not* a
filesystem check. It is *not* sufficient to prevent corruption,
although it does help quite a lot.

Some distros will also run fsck (once only) when they find a dirty
partition. However, if there have been any repairs done, fsck needs to
be run repeatedly until it reports there are no more problems. I once
had to run fsck seven times on my mother's MythTV box boot partition
before it finally fixed all the problems caused by a power failure. So
one run of fsck done automatically will *not* prevent corruption,
although it certainly helps a lot. This automatic fsck seems to be
dependent on the type of filesystem - it seems to be done on EXT
filesystems, but not some other types. I do not know if it is done on
XFS (I use JFS for my recording drives).

For EXT filesystems, there is also a counter that counts down one
every boot and when it gets to zero, a filesystem check is done on
boot. However, this is also *not* sufficient to prevent corruption,
as it only happens infrequently and when it happens, fsck is only run
once.

For the database, if you have put optimize_mythdb in /etc/cron.daily,
as is recommended, that will be run daily at the time anacron is set
to run daily jobs. Depending on how anacron is set up on your system,
daily jobs that have been missed will be run at boot time, so if your
PC is off at the time anacron normally runs (eg midnight or 07:00),
the daily jobs will be run shortly after boot time. There are two
problems here: "shortly after" is a typically a few minutes, during
which time mythbackend may well start a recording and will write to
the database, potentially further corrupting it to the point where it
will be unrecoverable. And if the boot time is after the time anacron
normally runs jobs, so the daily jobs have already been run that day,
depending on how anacron is set up, the daily jobs will not be run
shortly after boot but only many hours later at the next scheduled
time.

Further, like fsck, if there is repair work done by optimize_mythdb,
it may seem to succeed, but a further check of the repaired table(s)
can show that there is still corruption present, requiring further
repairs.

So, as I said, whenever you have a crash or bad shutdown, you need to
manually run full filesystem and database checks.
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org