[mythtv] Editing the Category

Tom Lichti 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
>

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.

Thanks!
Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mythtv.org/pipermail/mythtv-dev/attachments/20130326/09fd7e13/attachment.html>


More information about the mythtv-dev mailing list