[mythtv-users] Lost Recordings and Database
Stephen Worthington
stephen_agent at jsw.gen.nz
Tue Jan 10 09:32:22 UTC 2023
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.
More information about the mythtv-users
mailing list