<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 3/26/23 11:19, Ram Ramesh wrote:<br>
</div>
<blockquote type="cite"
cite="mid:bbefe28b-20b5-2b8a-fd7b-4879cb064dd8@gmail.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<div class="moz-cite-prefix">On 3/25/23 22:37, Stephen Worthington
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:oqdv1idu5f3c6r17v5pa4qlen8uklq47og@4ax.com"><br>
<pre class="moz-quote-pre" wrap="">sudo
/usr/share/doc/mythtv-backend/contrib/maintenance/optimize_mythdb.pl
(That should be all one long line - my email client wraps long lines)
That should check and repair all the database tables. Usually, if a
recording was in progress when the space ran out, recordedseek will be
corrupt, but optimize_mythdb will repair it. And if you are lucky,
that will be the only table affected. If you have done any recordings
while it was corrupt, those recordings will not have had their seek
tables written to recordedseek and you will need to fix that by
running "mythcommflag --rebuild" on each of those recordings. If you
do commercial skip processing, you would also then need to redo that
as it is also stored in recorded seek - use mythcommflag with the
settings you use for commercial skip processing. Make sure to do the
--rebuild first, as a separate run of mythcommflag as they can not be
combined and --rebuild will delete the results of commercial skip
processing.
If other tables have been corrupted, then you may have permanent
damage there and have to restore from your backup. Run
optimize_mythdb again until no tables are repaired, then see if
everything is working before deciding to do a database restore.
If you do restore the database, then any recordings done since the
backup will become orphaned - find the recording files
(find_orphans.py) and move them to a videos directory, then rescan
your videos:
mythutil --scanvideos
_______________________________________________
mythtv-users mailing list
<a class="moz-txt-link-abbreviated moz-txt-link-freetext" href="mailto:mythtv-users@mythtv.org" moz-do-not-send="true">mythtv-users@mythtv.org</a>
<a class="moz-txt-link-freetext" href="http://lists.mythtv.org/mailman/listinfo/mythtv-users" moz-do-not-send="true">http://lists.mythtv.org/mailman/listinfo/mythtv-users</a>
<a class="moz-txt-link-freetext" href="http://wiki.mythtv.org/Mailing_List_etiquette" moz-do-not-send="true">http://wiki.mythtv.org/Mailing_List_etiquette</a>
MythTV Forums: <a class="moz-txt-link-freetext" href="https://forum.mythtv.org" moz-do-not-send="true">https://forum.mythtv.org</a>
</pre>
</blockquote>
<br>
Thanks for the guidance. Like I said, shutdown (on the new machine
with old system kernel copied over) was working just fine until I
added sas 9211 hba card and a couple disks that were on my old
system. Now it completes every step and comes to reboot target and
then reports that some one is trying to do some extra work that
kernel is ignoring. I will get the exact message and post it here.
I am almost sure that if I take out the hba card, everything will
work fine. However, I do not have enough SATA ports that I need
this card. Apparently, this is one of the cards that has excellent
(long time) support on the linux side. Since my backend is always
on machine, I am not too inconvenienced by this limitation as of
now. Still it bothers me that I have to push the power button and
hold it to force the situation. <br>
<br>
I will try to post on one of the kernel threads or debian-user
to see what I get. I doubt there are any filesys corruption issues
because on screen log shows everything except actual power off or
reboot is done. So, I am less worried about pushing the power
button. However, I will try all of your above suggestions and
will learn what internal system state is and go from there.<br>
<br>
Regards<br>
Ramesh<br>
<br>
</blockquote>
<br>
Sorry, please ignore. I posted on the wrong thread.<br>
<br>
Regards<br>
Ramesh<br>
<br>
</body>
</html>