[mythtv] Recordings in subdirectories
Michael T. Dean
mtdean at thirdcontact.com
Sun Feb 5 05:37:41 UTC 2006
The attached patch adds the ability to store MythTV recordings in
subdirectories of the RecordFilePrefix (or its subdirectories).
Although the patch could be used to sort files (and make for smaller
directories to improve filesystem performance), moving files to
subdirectories is most useful when mounting additional filesystems
(either local or network) beneath the RecordFilePrefix.
Note that even with this patch, Myth will only record into the
RecordFilePrefix. The user must manually move recordings into
subdirectories and update the basename field of the recorded table to
include the subdirectory information (i.e. "subdir/recording.mpg" or
"sub1/sub2/recording.mpg").
I've been running my Myth system with recordings in subdirectories since
November 2. I've been running the current (better) implementation of
the patch for about 2 weeks. Both patches (see below for details) have
been very stable. I've been able to successfully play, delete,
transcode, and commflag recordings with the patch applied. Also, links
created by mythrename.pl work fine for recordings in subdirectories.
(Without the patch, deleting and commflagging (at least with "-f")
recordings in subdirectories fails to work. I never tested transcoding,
but I think it would also fail without the patch.)
Note that the patch does not update the auto-expire code to be aware of
multiple filesystems. Therefore, if you store auto-expire-enabled
recordings on other filesystems mounted beneath your RecordFilePrefix,
Myth's deleting those files will not affect the free space on the
filesystem containing your RecordFilePrefix. In other words, Myth may
delete every auto-expire-enabled recording on other filesystems before
finally deleting a recording from and making room on the recording
filesystem. So, if you move files to other filesystems, you should
disable auto-expire on those recordings.
Testing (especially by users with slave backends or remote frontends)
and comments and suggestions are very much appreciated.
Thanks,
Mike
Patch Implementation Details:
Originally, I tried modifying GetRecordBasename to no longer attempt to
derive the basename and instead always query the database. However,
this approach created a noticeable lag. Therefore, I rewrote the patch
to add a new field, basename, to ProgramInfo. The basename is always
the value stored in the basename field in the database. The pathname,
however, as before could be an absolute pathname (i.e.
/var/video/recording.mpg), a "myth://" URI, or the same value as the
basename.
I did not change the serialization format for ProgramInfo (since a
ProgramInfo with an empty basename field simply queries the database
when GetRecordBasename is called), however, a final version of the patch
should probably do so. I assume doing so would involve incrementing the
protocol version, but was unsure, so I left it off until I could get
more information. Also, I didn't modify the binary version, as I don't
think it's required for these changes.
I'm posting here (instead of Trac) to get more information on the
serialization/version issue I mentioned above and because I'm hoping I
can get someone with remote machines (slave backends and/or remote
frontends) to test the patch.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: mythtv-recordings_in_subdirectories-1.patch
Url: http://mythtv.org/pipermail/mythtv-dev/attachments/20060205/88509ead/mythtv-recordings_in_subdirectories-1-0001.diff
More information about the mythtv-dev
mailing list