[mythtv] Storage Group behavior in MythVideo (and future Storage Group behaviors)

[Robert McNamara]

Morning All,

I've been working at patch #6159 to adapt to the new MythVideo Storage
Group code.  First off, amazing work by Greg Estabrooks expanding
Storage Group functionality, and he left me all sorts of great
breadcrumbs to show me how to use the code for my own additions.  Long
story short, I've implemented storage groups for
fanart/banner/coverart/screenshot functionality in MythVideo.  It
works well.  There is one limitation I'd like to throw out there and
see if we can hash out an agreed-upod way to handle Storage Group
behavior.

It seems everyone is trying to move as much of the storage stuff to
streaming by .22 as possible, and that's great.  In MythVideo (and
likely elsewhere), you have potentially multiple pieces of metadata
that currently need to exist on the same host.  videometadata added a
"Host" field, and my patch relies on all the files to be in the
appropriate storage groups on that one host.  That behavior seems a
little limiting, so I have a suggestion to slightly modify it.  Rather
than having one host field, all filenames for files that exist in a
storage group should be in this format:

HOSTNAME:/path/to/file.ext

Where the path to file is relative to the root of the Storage Group.
The current code checks first for a storage group, then falls back to
the existing behavior of checking for the local directory.  It looks
like this:

QString filename;
if (item->Host() != "")
       filename = GenRemoteFileURL("Videos", item->Host(), item->Filename());
else
       filename = item->Filename();

So the only modification would be something like this:

QString filename;
 if (!item->Filename().startsWith("/"))
       QString sgHost = item->Filename().section(":", 0, 0);
       QString pathAndFile =  item->Filename().section(":", 1, 1);
       filename = GenRemoteFileURL("Videos", sgHost, pathAndFile);
else
       filename = item->Filename()

What's the upside?  It allows the user to configure image storage on
host "A" and video file storage on host "B", or even more granular
than that.  What's the downside?  Well, I really can't think of one.

There's no implementation of metadata grabbing that uses Storage
groups yet, but I would suggest something like a storage group dir
listing for a given storage group.  If it comes back null, there are
no storage groups so you fall back to the old behavior and look for
the local dir.  If it comes back with a value, you prefer the storage
groups and request the right storage group to write the grabbed file
to.

On a related note, I think that having both the local directory and
Storage Groups will become confusing quickly.  Any thoughts on
breaking entirely with the past and going all storage groups for this
stuff?

Robert