<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Apr 7, 2021 at 10:56 PM Stephen Worthington <<a href="mailto:stephen_agent@jsw.gen.nz">stephen_agent@jsw.gen.nz</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
Do not despair - recordedseek is fixable. If necessary, mythbackend<br>
can completely recreate it.<br>
<br>
The first thing to try is to see if you can get the recordedseek table<br>
repaired. Shut down mythbackend. Shut down MySQL/MariaDB.<br>
<br>
Optional but highly recommended step - if you have enough room<br>
somewhere on the system, make a copy of all the files in<br>
/var/lib/mysql/mythconverg. You can not run the database anywhere<br>
except in the mythconverg directory, but if you make a mistake trying<br>
to fix it, you can always copy back this backup copy and start the<br>
repairs again.<br>
<br>
Then delete the *.BAK and *.TMD files in the mythconverg directory.<br>
>From the /var/lib/mysql/mythconverg directory do these commands:<br>
<br>
du -b recordedseek*<br>
df -b .<br>
<br>
You must have at least as much room left on that partition as the size<br>
of the files for the recordedseek table, as repairing a table makes a<br>
copy of all the existing files (except the .frm file, which is<br>
information about the format of the table). If you are out of space,<br>
that will be the most likely cause of your problems.<br>
<br>
Restart MySQL/MariaDB.<br>
<br>
Then do:<br>
sudo mysql<br>
use mythconverg;<br>
check table recordedseek;<br>
<br>
It is possible (but unlikely) that the table will report OK at this<br>
point, simply due to the removal of the recordedseek.TMD temporary<br>
file. If so, just exit and restart mythbackend.<br>
<br>
If recordedseek is still crashed, do:<br>
<br>
repair table recordedseek;<br>
<br>
If that works, then everything is likely OK again. Do this to check:<br>
<br>
check table recordedseek;<br>
analyze table recordedseek;<br>
<br>
If not, then shut down MySQL/MariaDB again and delete any new<br>
recordedseek temporary tables. It should only have .frm, .MYD and<br>
.MYI files. The from the /var/lib/mysql/mythconverg directory, run<br>
myisamchk. I have never had to use myisamchk so I can not really<br>
recommend the right options, but its man page suggests this:<br>
<br>
myisamchk --silent --force --fast --update-state \<br>
--key_buffer_size=64M --sort_buffer_size=64M \<br>
--read_buffer_size=1M --write_buffer_size=1M \<br>
recordedseek.MYI<br>
<br>
I think I would not put the --silent option so I could see what it was<br>
doing, and I would keep a log file of the results:<br>
<br>
myisamchk --silent --force --fast --update-state \<br>
--key_buffer_size=64M --sort_buffer_size=64M \<br>
--read_buffer_size=1M --write_buffer_size=1M \<br>
recordedseek.MYI 2>&1 | tee recordedseek.log<br>
<br>
If that works, good. Otherwise, the next thing to try is to restore<br>
an old pre-crash copy of recordedseek if you have one. I presume that<br>
you have been backing up the database regularly. I have daily and<br>
weekly backups. But it is possible that the table has been crashed<br>
for a long time and it is bad in all the backups also. That may or<br>
may not be a problem, as restoring from a backup can make a table<br>
usable so that it can then be repaired as above, because the process<br>
actually involves deleting the table and recreating it, then reloading<br>
the data from the backup. But you may need to try restoring the<br>
recordedseek table from all the backups to find a good copy.<br>
Unfortunately restoring one table is not simple as there is no tool<br>
that does it. The process involves uncompressing the database backup<br>
file, then editing the uncompressed .sql file so that only the<br>
commands applying to that table are left - you delete all the other<br>
lines in the backup file. But to do that, you need to have an editor<br>
program capable of editing massive (multi-gigabyte) text files with<br>
quite long lines. Most text editors can not do that. I use my copy<br>
of SlickEdit which is a professional programmer's editor, and even it<br>
takes quite a while. I think it is also possible to do the editing<br>
using awk, but I have never done that. If the worst comes to it, you<br>
could give me a copy of your database backup and have me edit it for<br>
you.<br>
<br>
Once you have a .sql file with just the lines for recordedseek, then<br>
you do this (with MySQL/MariaDB running but mythbackend shut down):<br>
<br>
sudo mysql<br>
use mythconverg;<br>
source /path/to/the/backup/recordedseek.sql<br>
quit<br>
<br>
The edited backup file should have all the commands to delete the<br>
existing recordedseek table, re-create it and then load all the data.<br>
<br>
After that, you need to figure out which (recent) recordings no longer<br>
have recordedseek table entries and get mythbackend to re-create them.<br>
<br>
sudo mysql<br>
use mythconverg;<br>
select chanid,starttime,title,basename from recorded r where (select<br>
count(*) from recordedseek s where r.chanid=s.chanid and<br>
r.starttime=s.starttime)=0;<br>
<br>
The above is a big query - it will take a long time to produce any<br>
results. It should produce a list of basenames you can then use with<br>
the mythcommflag --rebuild command to rebuild the recordedseek entries<br>
for those recordings. Alternatively you can these days also try:<br>
<br>
mythutil --checkrecordings<br>
<br>
which is supposed to tell you which recordings do not have<br>
recordedseek entries, and then it also has a --fixrecordings option. I<br>
have never used this, so I am not quite sure how it works, but it was<br>
added just for situations like this.<br>
<br>
If you do not have a backup copy that works, then you will just have<br>
to re-create the entire recordedseek table. The --fixrecordings<br>
option should do that, but it will take ages (days? weeks?) as it will<br>
have to read all your recording files. I think that it is possible to<br>
do new recordings at the same time as that is happening, but I expect<br>
that the disk load will be very high and there might be problems. And<br>
playback will likely be affected also.<br>
_______________________________________________<br>
mythtv-users mailing list<br>
<a href="mailto:mythtv-users@mythtv.org" target="_blank">mythtv-users@mythtv.org</a><br>
<a href="http://lists.mythtv.org/mailman/listinfo/mythtv-users" rel="noreferrer" target="_blank">http://lists.mythtv.org/mailman/listinfo/mythtv-users</a><br>
<a href="http://wiki.mythtv.org/Mailing_List_etiquette" rel="noreferrer" target="_blank">http://wiki.mythtv.org/Mailing_List_etiquette</a><br>
MythTV Forums: <a href="https://forum.mythtv.org" rel="noreferrer" target="_blank">https://forum.mythtv.org</a><br></blockquote><div><br></div><div><div>Stephen,</div><div><br></div><div>Thank you so much! mysql is definitely not my forte.</div><div><br></div><div>I only needed to go as far as "repair table recordedseek;" as confirmed by the re-run of the check command and the analyze command reported the table was up to date.<br></div><div><br></div><div>Depending on how you look at it, (I'll take the optimistic view here) there's only 86 recordings for which I need to create recordedseek entries.</div><div><br></div><div></div><div>I'll save that list of recordings to a file and nibble away at it for the next few days (weeks?) until they're all addressed.</div><div><br></div><div>BTW, I'm saving the list by selecting it in one xterm window and pasting it into a new file vi session in another. Is there a way to direct/redirect/tee the mysql output to a file instead? That would be useful for future reference.<br></div><div><br></div><div>In any case, I'm off to get the list saved, exit out of mysql, restart mythtv-backend, and start an invocation or two of mythcommflag.</div><div><br></div><div>Thanks once again. I really appreciate the help.<br></div><div><br></div><div>--</div><div>Craig.</div> </div></div></div>