[mythtv] mythvideo DB enhancement
cpinkham at bc2va.org
Thu Jan 3 15:28:29 UTC 2008
* On Thu Jan 03, 2008 at 09:41:08AM -0500, George Nassas wrote:
> Last one first: so far as I know once an SG is defined the TV
> recorder will feel free to put recordings there. Perhaps extend SGs
> with a series of flags saying who can write stuff there? Easy enough
> and a small separate ticket too.
The TV recorder will only put files where you tell it that it can put
them when you setup a scheduled recording in the scheduled recording
editor. I don't see a reason to prohibit people from automatically
dumping a MythTV recording into one of their MythVideo Storage Group
dirs, but maybe others do. This could be left up to the user by
visually flagging MythVideo Storage Groups in the scheduled recording
> UI: the only place I know to define storage groups is mythtv-setup.
> That panel could be brought over to the plugin to allow per-frontend
I debated putting this in mythfrontend, but since it is necessary for
the backend to work, I put it in mythtv-setup. I don't see an issue
with people running mythtv-setup on a frontend to setup their storage
dirs. The GUI could be accessible from both places.
> Or, perhaps it could be something like the way playback profiles are
> defined now. Instead of profiles the top selector control would show
> video storage groups and instead of resolution rules there'd be the
> per-SG attributes (parental, etc) and then the list of directories
> for the group.
One question that comes to mind is are these attributes per directory
or per SG? Bruce, David, and I debated that a little bit when I
originally wrote Storage Groups. At the time, we (I think, maybe it
was just 'I') decided a global disk space setting was enough. With
other attributes for a SG, if these are per-directory they should be in
the SG table, if they are per-SG then they should be broken out into a
separate table. The SG editor could show different attributes depending
on what kind of SG this is (MythTV, MythVideo, etc.)
> Not sure what you're saying here. I would make SG::GetAllFiles return
> relative paths (since one beauty of SG's is you don't care which dir
I'd say use a flag to determine whether it returns relative or full or
possibly a QMap of both. If you don't get the full path, then you
have to call another SG method to get the full path if you want to play
the file. Throwing info away just to search for it again isn't good.
If someone were to implement the SG cache idea that I mentioned here:
then we wouldn't take that big of a hit when we re-searched because
GetAllFiles() could prepopulate the cache.
More information about the mythtv-dev