[mythtv-users] recordedseek table content

[Michael T. Dean]

  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

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

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

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.

Mike