On 03/26/2012 08:07 AM, Tapani Tarvainen wrote: > On Mar 26 09:53, Tapani Tarvainen wrote:
>> Error: MythTV is using all inputs but there are no active recordings?
Glad to see you got things working (when you realized there were
permissions issues accessing the capture devices), but I thought I'd
respond to some of the points in here (where the most interesting for
you, now, is probably about the backup). > [...]
>> Any suggestions what to try next?
> The only thing I can think of at this point is restoring the
> database from backup - which means losing several days
> worth of information, notably data on programs recorded
> during that time. :-(
If, in fact, your MythTV configuration is correct, simply stopping and
restarting the master backend (which implies stopping all other
backends, too) should work. Generally, though (as Raymond pointed out),
this tends to occur when there's a problem with necessary prerequisites
for actually recording (i.e. capture cards are misconfigured in MythTV
or at the system level or file system permissions are incorrect or ...). > Is there any way to recover that data?
> I guess I could try to extract it from the current
> (apparently corrupt)
Generally when something like this occurs, it's not that the database is
corrupt--if anything, it just contains "misconfiguration data". So,
usually restoring a backup doesn't help--or if it does, the same effect
could be achieved by simply doing a "Delete all capture cards" (and/or
"Delete all video sources") and the (properly) re-configuring what was
just deleted. (Usually when that fails, it implies that the problem
isn't the MythTV configuration, but is a lower-level configuration (such
as device configuration/file system permissions/...) or a
misunderstanding caused the user to re-create the same broken
configuration.) > database and insert just it back
> after the recovery, but doing that by hand would be
> rather hard, especially since there doesn't seem to
> be much in the way of low-level documentation of the
The only supported place to add shows to MythTV is in the Video
Library. MythTV Recordings section is for recordings done by MythTV.
Note, also, that since the Video Library is an excellent location to
archive shows long term, you can simply move the rest of the recordings
of that series over to Video Library, too, and they're there for archival.
If you're not planning to archive them and plan to watch and delete
them, you could move them over to a "temporary" folder in the Video
Library or something, just to keep that episode with the others of the
series, so that you don't accidentally skip an episode while watching.
(And, you can choose to either leave future episodes in Watch
Recordings--such that when you finish watching the episodes, in order,
in Video Library, you continue with that series in Watch Recordings, or
if you prefer the Video Library UI, you could just keep moving them.)
I think most people move recordings using http://www.mythtv.org/wiki/Mythvidexport.py
. > Doing a partial recovery from the corrupt database
> after restoring an older (hopefully) working one
> doesn't sound too appealing either.
The only supported "partial" restore is restoring all recording and
history data (and no configuration) into an empty schema, so that
wouldn't have helped, either. > Which brings up another question: is there some reason
> against backing up the database more often, say daily
> instead of weekly?
> Will something break if I simply do this:
> mv /etc/cron.weekly/mythtv-database /etc/cron.daily
> That would make recovery in situations requiring
> database restoration much easier.
The database backup is something configured by your distro. The reason
MythTV doesn't do it internally (as it has all the code it needs to do
it internally--and has for a few versions, now), is because performing a
database backup while MythTV is busy doing something else may break that
something else (generally due to I/O or database locking issues causing,
for example, us to be unable to write all the data for a recording).
Since we don't yet have code to really track who's doing what and who
will do what in the future and how long it will be before something is
being done, we're holding off on pretty much all of the automated
database maintenance (including backups and database table checks and
repairs and analysis and optimization). We will eventually do
this--including doing automatic backups at "good" times--but it may be a
few more versions. :)
In the meantime, we're leaving it up to users (with help from distros)
to choose a "safe enough for my system" approach.
That said, if your weekly job isn't causing issues, then chances are a
daily job won't cause issues--unless it happens to be triggered at an
especially-busy time on one of those other days. If you know when your
cron.daily is run and you know it's not a busy recording time, you'll
probably be ok doing a daily backup. So, it's probably a good thing
that you've changed it to do a daily backup.
mythtv-users mailing list