[mythtv] [PATCH]Shouldn't MythVideo store filenames relative to VideoStartupDir?

[Dan Christensen]

Neale Swinnerton <mythtv-dev.spam at isismanor.com> writes:

> I've been having a problem with MythVideo and the way it stores 
> filenames in the Database.
...
> Although MythVideo allows you to specify a VideoStartupDir, the 
> filenames stored in videometadata are absolute, so if I do a video scan 
> on one machine I can't browse them on the other.
>
> The attached patch makes VideoScan store the paths relative to 
> VideoStartupDir. It also tweaks the playVideo methods to prepend 
> VideoStartupDir before invoking the player.
...
> Anyone have any thoughts on this?

I like the idea.  One possible extra feature:  if the stored filename
has a leading slash, take it as absolute.  If it doesn't, then prepend
VideoStartupDir.  This should make things backwards compatible.
Programs which add entries to the database could then be adjusted to
use relative paths for files which are under VideoStartupDir, and if
they somehow support files in other locations, to use absolute paths
for them.

By the way, this is related to the problems I was having using
mythcommflag to build seek tables for my mythvideo recordings.  
If I invoke mythcommflag as

  mythcommflag --video test.mpg

then the entries get added to the filerecorded table with just
the filename "test.mpg", no path at all.  And these aren't found
when the internal player tries to look them up.

On the mythtv-users list, I wrote a few messages about this
on March 5, 6 and 7 with the subject "seek problems in mythvideo,
internal player".  Here's some of the last message:

> I figured out the problem.  You need to specify the full pathname to
> mythcommflag.  When given a relative path, would it be reasonable for
> mythcommflag to either guess the full pathname, or to refuse to
> operate?  Also, the usage info should document this.  (It would also
> be nice if the usage info went to stdout when produced because of -h
> on the command line.)
> 
> I was also wondering why the filename is stored in the filerecorded
> table.  Duplicating this info with every record seems like a bit of a
> waste (although maybe mysql is smart enough to store it only once)?
> Wouldn't it make more sense to use the intid from the videometadata
> table as the key instead (which might also get rid of the problem
> of relative vs. absolute paths)?

I thought this might be relevant if some of the tables are going to be
changed (and even if not).

Dan