[mythtv-users] Store Recording Previews in a seperate location

[E. Westbrook]

On Sat, Nov 20, 2010 at 04:04, Mike Perkins <mikep at randomtraveller.org.uk>wrote:

> I support this suggestion. One thing I've always found is that it is
> difficult to remember video filenames because they are so long, particularly
> if you are hunting for a file over several storage volumes. It's easy to
> write the wrong thing down when you have a long string of pseudo-random
> digits.
>

Indeed.  This is great source of tedium for me too, often.


> This is because so much information is encoded into the filename. IMO this
> information should be kept where it belongs, in the database. Each file
> could be identified by a simple record_id value, say a 4- or 5-digit number,
> perhaps with a simple prefix indicating that it's a recording or a video or
> whatever.
>

Bingo.


> Side benefit: if it is necessary to do a rescan and the channel_id changes,
> it isn't going to affect previously-recorded files, whereas with the current
> system old files now end up referencing the 'wrong' channel.
>

I didn't immediately think of that one; nice benefit.

Thoughts?
>

This question goes to the heart of the filename's purpose.

If it's not for human consumption, then why put human consumables in it at
all?

If it is for human consumption, it should be more usably so, to the point we
wouldn't need mythlink.pl just to reliably find a show's file.  That's just
not practical, and would probably be impossible to get a consensus on for
format anyway.

I suspect the current scheme is simply the way it happened to come about
early on, pretty much worked, and stuck for a while.  I for one am glad to
see it discussed, now that time has passed.

If file naming is to be revisited (which I would love to see), my vote (if I
get one) would be for just the ID.

Looking forward to hearing what the project leadership thinks on this one.

EW
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mythtv.org/pipermail/mythtv-users/attachments/20101120/3b2b9e3a/attachment.htm>