[mythtv] proposed patch: support multiple recording directories

Dave Just justifiably at cwazy.co.uk
Wed Apr 26 22:54:52 UTC 2006


Thanks for the follow on, Lincoln.

> 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.....

Yes, of course, I was loosely talking about backends when I meant  
fileservers more generally.  I do run multiple myth backends (one of  
which I power up and down, but it is only to help with transcoding).   
But they all share the same nfs recording directory.  On the other  
hand, it's quite handy to copy files over to my laptop to store there  
and take away: that does get connected wirelessly and sometimes has  
its lid closed.

> 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.

Good point.

> 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.

OK: my fear was that the try 10 times logic would be applied to each  
directory in the search path in turn...

> 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!

I guess the two could coexist: an empty location means "search all  
known paths".  Or with more trickery, we could cache the discovered  
location in the DB.

> 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.

You're right of course, although it depends on your tradeoffs (I  
transcode to a pretty low bit rate mpeg4 so I fit a lot on a DVD, and  
I have a "mere" 160GB on my master backend).  Also it how much you  
like the idea of being able to keep the best stuff around, pass to  
another friend with Myth (ssh), etc.

Anyway, I'll give your patch a spin shortly.

Cheers,

  - D.




More information about the mythtv-dev mailing list