[mythtv] mutliple storage directories idea... ?

[Joseph A. Caputo]

Comments inline.

On Friday 04 November 2005 14:13, Michael T. Dean wrote:
> Joseph A. Caputo wrote:
> 
> >On Thursday 03 November 2005 21:51, Michael T. Dean wrote:
> >  
> >
> >>I was looking for a way to derive the basename from the pathname 
> >>even  
> >>in  
> >>the situation where the basename contains directory information 
> >>(allowing recordings to be stored in subdirectories of the 
> >>recordings  
> >>directory).  So, just taking the filename doesn't work.
> >>    
> >>
> >Sorry to come late to the party...
> >
> No problem.  The more the merrier...
> 
> > IIUC, you have a pathname and you 
> >want to somehow determine which part of it is the basename (which may 
> >or may not include an arbitrary number of levels tail-end 
> >directories).   
> >Do I have that correct?  Is the pathname you're parsing an absolute 
> >path?  If so I have some ideas...
> >  
> >
> It's the pathname field in the ProgramInfo class, and, specifically, 
> the  
> use of it to derive a basename on line 1222.
> 
> 
http://svn.mythtv.org/trac/browser/trunk/mythtv/libs/libmythtv/programinfo.cpp?rev=7720#L1217
> 
> The current code assumes that the basename is the filename at the end 
> of  
> pathname.  However--like you said--I would like for it to allow the 
> inclusion of "an arbitrary number of levels" of subdirectory 
> information  
> (to allow for grouping of recordings, or--more importantly--the use of 
> multiple filesystems for storage of recordings (although it does 
> require  
> manually moving the files after recording).
> 
> AIUI, the pathname may be an absolute path /or/ may be a "myth://" 
> path.  Therefore, and because of the possibility of multiple 
> RecordFilePrefixes when using multiple backends, we can't just strip 
> the  
> RecordFilePrefix.  We could check for "myth://" and if not there, 
> attempt to strip all possible RecordFilePrefixes but that would not be 
> very elegant and would likely require querying the DB (which defeats 
> the  
> purpose of deriving the basename from pathname in the first place).  
> And, even if we did this, we wouldn't be handling the situation where 
> the pathname is a "myth://" path, so files in subdirectories that were 
> recorded by remote backends would always be streamed--even if they're 
> available through a network filesystem.
> 
> The only "sure-fire" approaches I can think of are to a) add an 
> explicit  
> basename field to ProgramInfo in addition to the pathname field or b) 
> disable the code that derives basename from pathname and query the DB 
> every time GetRecordBasename is called.  I've done b) in my tree and 
> it  
> seems to work quite well, but I wasn't willing to call it "ready for 
> primetime," so I was hoping for some dialog.  It may also have an 
> effect  
> on videos not recorded by Myth, but I haven't looked into that (and I 
> don't use the Internal player for my non-Myth videos).

Ah.  Well, it seems you've covered all the bases -- the only heuristic 
way to determine basename from pathname would require a brute-force 
method of checking every RecordFilePrefix against the path; longest 
matching prefix wins.  Though I imagine you could eliminate the DB hit 
here by maintaining a QStringList of the RecordFilePrefixes, perhaps as 
a static class member or something.

The other 2 options you mention require either a modification to a data 
structure or a per-use DB query -- at that point it's kind of a "lesser 
of two evils" situtation, though I don't imagine either one would have 
an adverse effect, though modifying a data structure would require more 
of a recompile, but I don't think anybody really cares much about that.

I wish I had more to say, but I'm just not familiar enough with all the 
ins and outs of how that pathname gets passed around and who uses it.  
I will say this:  if you end up writing any more 'path-parsing' code, 
consider using QFileInfo and/or QDir.  They save all the trouble of 
string-splitting, and are smart enough to work on platforms that have 
different drive name schemes (think: mount points [Unix] vs. drive 
letters [Windows]) and/or path element separators ('/' vs. '\').

Cheers,

JAC