[mythtv-users] Error: MythTV is using all inputs but there are no active recordings?

[Michael T. Dean]

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
> database.

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.

Mike