[mythtv] Editing the Category
tom at redpepperracing.com
Tue Mar 26 17:12:49 UTC 2013
On Tue, Mar 26, 2013 at 12:07 PM, Michael T. Dean
<mtdean at thirdcontact.com>wrote:
> 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, this looks quite promising. Are you (as in the devs) also looking at
using the 'tag' system to tag recordings and videos, so that media is 'type
agnostic', in that a tag view could contain both classic 'recordings'
and/or classic 'videos'? By classic I mean 'the current MythTV method of
identifying the different file sources'. Maybe 'legacy' is a better term to
use, but regardless, that would make my life a lot easier in terms of being
able to present a converged (yes, I am using that term in full knowledge of
how it pertains to MythTV) view of content. I won't use the term
synergistic, it's too Enterprise-y :)
I look forward to this functionality, I think it will be a huge leap in
flexibility for the project.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the mythtv-dev