Neale Swinnerton <[EMAIL PROTECTED]> 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
_______________________________________________ mythtv-dev mailing list [email protected] http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
