[mythtv-users] Moved to Intel NUC - no sound & IR receiver needed

[Stephen Worthington]

On Sun, 22 Mar 2020 12:31:54 -0400, you wrote:

>On Sun, Mar 22, 2020, 11:47 AM Stephen Worthington, <
>stephen_agent at jsw.gen.nz> wrote:
>
>> On Sun, 22 Mar 2020 13:00:09 +0000, you wrote:
>>
>> {snip}
>>
>> You want to only move recordings when the backend is not in use for
>> playback, and to not move any recordings which are currently still
>> recording or being used for commercial skip processing.  A crude way
>> to do that is to just schedule the move job for say the early hours of
>> the morning, and check that you have enough time between then and the
>> next recording time.  You can get the next recording time using the
>> Services API.  But if someone has paused the playback of a recording
>> that is on the SSD, you could still get into trouble that way as I
>> believe paused playback keeps the recording file open.  So a better
>> way to handle this is to also check the contents of the inuseprograms
>> database table.  If it is not empty, do not move any file listed in
>> it.  There is still a potential problem even then, as there seems to
>> be a bug (in v30 anyway) where the DBCleanup job that is run
>> automatically at some random time each day cleans up the inuseprograms
>> table and manages to delete all the entries, even ones that are
>> current.  It is only supposed to clean up old stale entries, and its
>> code that I glanced at should only do that, but it actually always
>> seems to delete all entries on my system.  Then as the jobs update
>> their inuseprograms table entries, the entries re-appear over several
>> minutes.  If your file moving script takes into account the
>> inuseprograms, then it potentially could be run safely at any time. It
>> would want to only copy the files and re-check inuseprograms before
>> deleting the source file in case something has started using the file
>> while the copying was happening.  And the destination file should have
>> a different name from the source file until the source file has been
>> deleted so that MythTV does not see two copies of the same file while
>> the move is in progress.
>>
>> I have some Python code ("mythsgu") that moves MythTV recordings,
>> which has all this sort of thing in it.  It aborts any move that is
>> under way whenever it thinks mythbackend is becoming busy, rather than
>> just avoiding files listed in inuseprograms.  Let me know if you would
>> like a copy.
>> {snip}
>
>
>I'd love to see that script.

I have put the latest version on my web server:

http://www.jsw.gen.nz/html/mythtv/mythsgu

It is a bit of a work in progress.  Every so often I do something more
to it.  It is not set up to do exactly what you want, but I would be
happy to help adjust it as necessary.  The code you should look at is
for the "mythsgu copydir" command.  In conjunction with the "mythsgu
exportdir" command, copydir is set up to be able to copy an entire
directory of recordings from one MythTV box to another one via a
network connection, using the same technique as mythexport/mythimport
for copying all the database records for each recording.  I later
adjusted copydir to make it able to do copying between directories on
one MythTV box.  So it would need to be adapted to do a move instead
of a copy (ie to do a delete of the source recording file once it had
been safely copied), and also to handle finding the storage group on
the spinning rust drives that had the most free space and putting the
next recording file there.