[mythtv] mythvideo DB enhancement

Anduin Withers awithers at anduin.com
Thu Jan 3 20:48:26 UTC 2008


> 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
> settings.

Allowing them to be configured in the frontend would make sense to me. In
MythVideo a screen to check which of the currently configured SGs to use
along with a button to bring up the SG editor. Then again, I'd also be fine
with just the ability to do it somewhere in the frontend.

> 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.

I'd break them out into another MV specific table (unless something ugly
like codecparams were done). Some minor code to keep the table clean when
SGs are deleted (luckily you cannot rename them) would be needed though.

> Is there anything in the new UI code that would be appropriate here?

I'm actually not up on the new UI stuff, I expect a push to start converting
things after the release though. I do know that what I'd like wouldn't be
too hard using the current UI (which probably shouldn't be done as it will
just need to be converted, this time maybe for really).

> > It is only this easy because you want to skip the prefix name part,
> > and
> > scans will need to do that same prefix placing (currently done with
> > string
> > compares) with file existence tests.
> >
> 
> 
> 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
> the file is in) and that's what we want for constructing folder views
> and also for comparing scans with what's in the DB.

It is what you want for folder views, because you want SG->file, if
VideoStartupDir were converted to a single SG, SG->prefix name->file would
allow the same tree plus an extra node.

I still think GetAllFiles() is heading down the wrong path, that is a return
to the separate scanning logic between DB scans, DB views, and file browse
mode. A simple function taking depth, some context holder, and performing
callbacks to handle unique directories could be shared everywhere (including
outside MV). Not to mention, something like GetAllFiles() would throw away
information you would then need to recreate (individual directories,
currently we only reconstruct when the path is from the DB).

-- 
Anduin Withers



More information about the mythtv-dev mailing list