[mythtv] Editing the Category
Michael T. Dean
mtdean at thirdcontact.com
Tue Mar 26 16:07:47 UTC 2013
On 03/26/2013 07:11 AM, Steve Campbell wrote:
> On 24 Mar 2013 21:09:45 -0400, Michael T. Dean wrote:
>> I have a patch in the works that
>> changes MythTV to replace recording groups with "tags" (aka labels) and
>> allows an unlimited number of tags per recording. I'd prefer not
>> editing the category stuff, but working with recording group and, in the
>> future, tags for any user-specifiable values. (But I can't guarantee
>> when that patch will be done.)
> Tags do sound good. I'll hold off for the moment. One thing though -
> can a recorded program default to have a tag equal to it's category?
> That way my ultimate aim of having one click record a program and have
> it appear in the right place will be achievable.
Steve and George,
My idea for tags is to allow users to specify "literal" values as tags.
So, users can add tags to recording rules and any recording resulting
from that rule will have those tags. But they would need to know the
exact value of the tag at the time they create the rule.
However, MythTV will support dynamically adding and removing tags from
recordings--either via clients (like mythfrontend or mythweb) or via an
API (likely the services API). My own opinion is that rather than code
in support for allowing users to use specific values of program or
recorder or ... data as tags (and having to get agreement on what other
data to make available and--worse--trying to design a remote-friendly
/and/ 10-foot-UI-friendly interface to allow specifying
other-than-literal tag values***), "dynamic" tags should be added using
external programs (i.e. scripts using, for example, the Python bindings
or whatever).
So, I will make a script to go along with the tag implementation that
can be used with MythTV System Events or as a user job and have it get
the program and recorder information, then allow the user to add tags
using any value available in them. My (haven't written it, yet, but
seems like the way to go) idea for the design of the script would allow
the user to provide a configuration file that simply lists which values
to apply as tags. So, a user who wanted to apply the program listings
category as a tag would simply uncomment the line in the example
configuration file that specifies the program category.
So, Steve, ideally you would just use recording group (which I'll
eventually convert to tags) as a means of filtering and/or sorting.
When converting to tags, we'll then extend the ability to allow
specifying things like "has tag Movies and Sci-Fi and not B-Movies" or
"has tag Movies and (Sci-Fi or Fantasy)" or whatever. Then it would be
up to the user to decide what data they want to use for filtering and
sorting, but it means they would be able to filter/sort on what makes
sense to them.
This approach of using external applications to specify dynamic tags has
other benefits, too. It would even allow you to do custom
"post-processing" of the value. For example, the reason we do not (and
will not) store information on which input was used to record a show is
that the information is generally meaningless long term. For example,
on my system, I have 4 pcHDTV HD-3000 cards and 1 Hauppauge HVR-2250.
Since I only use the digital side of the HVR-2250 with MythTV, its
tuners are 100% equivalent to the HD-3300s; therefore, I have never set
up udev rules or anything to maintain device numbering. So, sometimes
input 1 is an HD-3000 and other times it's an HVR-2250 tuner. Or, even
on systems where there are differences in usage and device numbering is
maintained from boot to boot, as users add or remove or replace capture
cards, the meaning of "input 1" changes over time. So, by using an
external script, you can find that the input being used is input #1,
then use that to find that input #1 is /dev/video0 or
/dev/dvb/adapter0/frontend0 and then use that to find out (or map to) a
"real name" for the card (i.e. "HVR-2250 neptune analog 0" or "HVR-2250
saturn digital 0" or whatever makes sense to you).
And, I'm sure once the capability is available, our users will find new
and interesting ways to use it.
Mike
*** Having too many choices would just make it confusing, and if a user
has no interest in ever using any particular option, why should they
have to see it in the UI? So, the UI I envision will provide a combo
box allowing users to add any currently-existing tag value or to type in
a new one. Currently-existing means previously defined, and there will
be a separate UI allowing users to manage tags (including deleting or
renaming or merging tags or whatever). This way, the user sees only
those tags that are of interest to him/her.
More information about the mythtv-dev
mailing list