[mythtv] proposed patch: support multiple recording directories

[Lincoln Dale]

g'day,

Dave Just wrote:
> This patch sounds great (thanks!) but I wonder if we could discuss on
> the list a bit more how to manage large numbers of recordings stored
> in different places.
> 
> Automatically storing to the location with the most space sounds
> sensible at first but I imagine pretty soon people would want to have
> criteria for choosing where to record particular kinds of content,
> dealing with e.g. slave backends that come and go, maybe connected
> wirelessly, etc, etc.

This requirement is somewhat orthogonal to "multiple recording directories".
Slave backends always use 'their' own recording directory, and although this
can be shared between backends (e.g. shared nfs mount), it doesn't have to
be.

Myth already handles this - and adding additional logic to decide what tuner
+ backend to use for recording something based on some other criteria is
definitely much harder & not something I think that would be worthwhile.

The reality is that Myth expects backends to be fairly static & not be "part
time".  If you have a backend that is sometimes in wireless range &
sometimes not, that will break all other parts of myth, and you will perhaps
end up with things not being recorded because they were scheduled for a
tuner that wasn't there.....

The other part is that any changes to this area shouldn't break the existing
'expiry' functionality.
Myth's automatic expiration is a very powerful thing & adding additional
policies here was something I previously looked at (recording directory per
recording group) but quickly moved away from when I realized the
implications of that.

> With more and more recordings stored, finding
> one along a search path could be expensive (and missing recordings
> especially can cause bad delays in the watch recordings screen in the
> preview generation mechanism).

Doing a stat() call to see if a file exists is hardly expensive.
The try-10-times-with-500msec-delay-between-tries loop is expensive, but
this patch doesn't make that any better or worse because the scanning of
files is separate from that.

> In particular I'd question this basic choice:
> 
> > The patch is larger than it could otherwise be.  The rationale is
> > that I
> > didn't want to change the database format or store the pathname in the
> > database in any way.  This also means that you are free to move
> > your media
> > around _between_ your recording directories & it will still find
> > the media.
> 
> I'd thought about constructing a patch which does change the database
> format.  We already have a utility to rename recordings and modifying
> that to change the pathname as well doesn't seem too hard, so moving
> around recordings is a bit harder but not a major problem.

Well, for me, backward compatibility was an important factor & I considered
it a 'feature' to be able to move contents around and know that I don't have
to mess with SQL tables to get it all working again!

Feel free to provide code to implement what logic you would like though!

> The main reason I wanted to include pathname (or similar
> location/"MRL" type of thing) was to allow removable media to store
> nuv files in a simple and direct way.
> The idea would be that you could move .nuv files (and maybe
> generate .sql files as nuvexport does) to a data CD/DVD, and then
> automatically have them appear as a special program group in Watch
> Recordings when the CD/DVD is inserted.  To make this work, the
> database keeps a hash of the directory listing as part of the
[..]

Sounds neat, but the reality today is that storage such as DVDs is miniscule
versus that of recordings.  For example, a single-sided dual-layer DVD can
handle 9.4 GB.  I have over 100 times that amount of HDD storage for
recordings - so "archiving" off to DVD doesn't seem to make a whole lot of
sense.

[..]
> In general (e.g. with slave backends or other fileservers that come
> and go as well), we would like a way of knowing whether a particular
> pathname/location is available or not (as well as it is writable),
> and then automatically filter (or grey out) recordings which cannot
> be located, rather than search every directory in the path (possibly
> trying several times to generate previews? --- sorry haven't looked
> yet to see how you deal with this).

I don't change myth's existing behavior.  But the stat() call for checking
to see if a file exists won't delay things any more than they are today.


cheers,

lincoln.