[mythtv-users] Lost Recordings and Database

Paul Harrison mythtv at mythqml.net
Tue Jan 10 13:51:13 UTC 2023


On 10/01/2023 09:32, Stephen Worthington wrote:

> On Tue, 10 Jan 2023 14:15:24 +1300, you wrote:
>
>> On Mon, 9 Jan 2023 11:35:39 +0000, you wrote:
>>
>>> Hi All,
>>>
>>> I wonder if someone with more knowledge of the Myth Database schema
>>> might be able to advise me here. A friends Myth (0.32) system had a disk
>>> tragedy and he has lost one of two volumes where the recordings are/were
>>> held. The database entries for those recordings remain intact.
>>>
>>> Would it be possible to construct an SQL query that would take entries
>>> after a specific date in the Recorded table and arrange for those
>>> recordings to be entered into the Recording Schedules. In effect a
>>> "Delete and Re-Record" operation.
>>>
>>> Many thanks
>>>
>>> Ken
>> That certainly sounds possible.  What you would want to do would be to
>> check all recordings and get the basename field for each file, then
>> check if the file can be found on disk.  If not, then do the delete
>> and re-record.  There are API calls to list recordings with various
>> filters, and there is an API to do delete.  I would have to check if
>> the delete API has a re-record option.  If so, it would not be a
>> particularly complicated bit of Python to do this.
> The DeleteRecording API does have options to delete metadata if the
> recording file is not present and to re-record.  The GetRecording API
> will return the recording data if the recording is present, and
> presumably will do an error if it is not, so it should be able to be
> used to determine if the recording file exists.  The GetRecordedList
> API will return a list of all recordings.
>
> So what I would do would be to get the full list of recordings, then
> for each one do GetRecording and see if the file exists.  If it does,
> delete that entry in the recordings list.  Then display the list of
> recordings that have no files for the user to check.  After checking,
> the user says whether to proceed with doing a delete-and-re-record on
> each of those recordings, using the option to force a delete if the
> recording file is missing.  All of which is fairly straightforward for
> anyone who has used the MythTV Services API before, but does represent
> a few hours of work to write.
>
> I would recommend only running the program when MythTV is not busy and
> is not going to be busy for a while, as it will do a lot of database
> updates and may make it too busy to start or stop recordings properly.


Yeah there is potential to do a lot of damage if things go wrong so 
definitely a good idea to do a test run first that doesn't do anything 
that can't be undone.


Another thought. There is an option  in the mythutil command line 
utility (mythutil --checkrecordings) to do some basic checks including 
looking for missing recordings and 0 byte recordings where the file 
exists but is zero bytes in size.

It's another way to do a quick check, you get  a list of missing 
recordings etc at the end of the run and a summary so you can see how 
bad things are.

The intention was always to add more command line options to fix any 
errors found like missing recordings or zero byte recordings but the 
only one done is to fix recordings with missing seek tables that was and 
still is a common problem. You add 'fixseektable' option to the command 
line. It would be nice to have further options to fix the other common 
problems.


Paul H.




More information about the mythtv-users mailing list