[mythtv-users] recordedseek table content

[D. R. Newman]

On 28/11/10 19:37, Michael T. Dean wrote:
>  On 11/28/2010 09:23 AM, D. R. Newman wrote:
>> On 28/11/10 14:13, Michael T. Dean wrote:
>>> For the record, it is not safe to go in and delete /any/ data in the
>>> database directly.
>>>
>>> MythTV cleans up the database to ensure you don't have any extra garbage
>>> in there.
>> Except when it fails, and corrupts a database table. Then you need to
>> repair the table
> 
> with optimize_mythdb.pl or mysqlcheck--both of which leave all the
> actual repairing to MySQL

It is mysqlcheck I use (or rather the same check and repair routines
called from MySQL Administrator). I didn't know about
optimize_mythdb.pl, thanks for the mention, I will try that.

>>   - which in extreme cases drops all the data.
> 
> In which case, MySQL is actually deleting all of the data in that
> table--not you.  And it's not safe--having lost all that data, it
> becomes your responsibility to find a way to recover it (such as
> restoring from a good backup or if it's the recordedseek table, by
> running mythcommflag --rebuild on every single recording you have)--it's
> still not safe to lose it.

Normally the MySQL repair routines don't empty the table. But if they do
on the recordedseek table, so what? It just means that next time I view
a programme, I will have to start from the beginning, not at the place I
stopped watching it. That's no great loss.

>> Also, when restarting MythTV (e.g. after a crash), it is worth deleting
>> currently running jobs (status = 4) from the jobqueue, otherwise a
>> duplicate job will be started.
> 
> Actually, you're better off killing the running job on the system and
> letting MythTV restart the job--so that it can manage the job in the
> queue.  Otherwise, you'll end up having MythTV start the next job(s) in
> the queue without knowing that a job is already running, so your max
> jobs setting isn't respected.

That is what I do if the job has just started. But if the job is already
in Avidemux's 2nd pass of a conversion to Xvid or MPEG4, a restart
repeats hours of conversion.

> If there's any situation that /requires/ direct DB editing, please
> submit patches so that we can fix MythTV to actually do whatever you
> feel is so important that you're editing raw data without any data
> integrity checking.

Well, having converted the video to a more compressed format, I store it
in the mythvideo directories, add its name to the videometadata table,
delete the file from the TV directory and remove the entry from the
recorded table. But that isn't a patch, I could possibly turn it into a
user contributed script after some more testing.

Of course, if I could track down what occasionally causes MythTV to
crash, then there wouldn't be any problems. But is seems to happen when
my DVB-T card's driver crashes, so that isn't MythTV's fault.

--
Dave Newman