[mythtv-users] Labels instead of Recording Groups

[Joseph Fry]

>
>  This sounds like something to look forward to.
>>>
>>>> I was wondering how wide a role you are planning for the labels?
>>>>
>>>> I've also been using Recording Groups as simple user accounts, but
>>>> something I've been trying to work out (and failing for the most part)
>>>> is
>>>> how to bundle together recording rules so I only have to set the
>>>> Recording
>>>> Group when creating a new recording schedule, and different  actions are
>>>> performed based on the selected recording group. For example,
>>>>
>>>> Person A wants her cooking programmes indefinitely  stored, so
>>>> auto-expire should be false
>>>> Person B only watches via a tablet after its been transcoded into xyz
>>>> format and copied to a network share
>>>> Person C is two, and so their programmes can be transcoded immediately
>>>> after commflagging so they don't see all the toy adverts.
>>>> Person D records dvb radio broadcasts, so if its a radio channel extract
>>>> the audio and move it to his podcast archive.
>>>>
>>>> Currently this is set up each time I set a new recording schedule, but
>>>> I've been thinking about implementing some script triggered at the end
>>>> of
>>>> the recording which decides what to do based on Recording Group.
>>>>
>>>> The holy grail though, and i accept, probably a nightmare to engineer,
>>>> would be to define a user/tag/label and associated actions, and then
>>>> when
>>>> creating a schedule, select the type of recording and who its for, -
>>>> with
>>>> the normal scheduler options accessible behind an 'advanced' button for
>>>> when you occasionally need to tweak things further - like when one
>>>> action
>>>> conflicts with another.
>>>>
>>>> Is this beyond what you're planning? If the answers 'yes', and i expect
>>>> it is, then thats fine. I can't code and don't expect anyone to do it
>>>> for
>>>> me - i'll get on with the script and see if i end up with something
>>>> robust
>>>> enough for the wiki...
>>>>
>>>>
>>>>  At this point, yes, it's beyond my plans.  Once the labels are in
>>> place,
>>> it's quite possible that they will be extended and used for additional
>>> things.
>>>
>>> That said, a script-based approach using user jobs sounds like a good
>>> idea.  I'll try to remember to update the user job code to add a %LABELS%
>>> expansion.  And, if you create a script to do this (before and/or after
>>> labels), it would be welcomed on the wiki scripts category (
>>> http://www.mythtv.org/wiki/****Category:Scripts<http://www.mythtv.org/wiki/**Category:Scripts>
>>> <http://www.**mythtv.org/wiki/Category:**Scripts<http://www.mythtv.org/wiki/Category:Scripts>>+
>>> specifically
>>> http://www.mythtv.org/wiki/****Category:User_Job_Scripts<http://www.mythtv.org/wiki/**Category:User_Job_Scripts>
>>> <http**://www.mythtv.org/wiki/**Category:User_Job_Scripts<http://www.mythtv.org/wiki/Category:User_Job_Scripts>
>>> >).
>>>
>>>
>>> Oh, and FWIW, eventually (though this one has been on the TODO list for
>>> many versions/years, now), we hope to allow recording rule templates (to
>>> allow you to define your preferred settings) so creating recording rules
>>> with non-default values should become easier.
>>>
>>>  Sounds like his thoughts are similar to mine with regard to tags... make
>> them more than just a way of organizing/filtering recordings... make them
>> the logic that the system uses to perform actions or report information
>> about the recordings as well.  A single recording could have many tags,
>> both user selectable and system generated, and all of those tags can be
>> used to filter the recordings using a single common interface (so I could
>> filter to show my HD movies that include closed captioning)  Obviously
>> starting with just user tags makes sense, but ultimately I would love to
>> see tags for post processing, and tags for recording details too.
>>
>
> I just don't get why you would want to duplicate already-existing data
> from some other part of the schema as a label.  Why not just use the
> original data--such as recorded.transcoded and/or
> recordedprogram.subtitletypes or recordedprogram.audioprop or
> recordedprogram.videoprop?  Having a "single common interface" is still
> required/a good idea, but duplicating other data doesn't seem to add
> anything--and I don't want to change our schema to a 2-column recorded
> table with recordedid and label and then put all the other data we need in
> as labels.  :)
>
> That said, I will be completely reworking the filtering to take advantage
> of labels (and other data), and I think you'll see that what you want will
> be possible with or without labels.
>

I would never suggest duplicating data... instead I am proposing that
applicable metadata be stored and presented as tags so that a single
'filter' interface can be used.  Sure you could include non-tag data in the
filter screens, but it would require far more complicated queries.  This
wouldn't be such a big deal in the Mythtv code, but for folks who wanted to
write external tools or plugins, I would expect that it would be easier to
have all of this information represented the same way.... just a thought.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mythtv.org/pipermail/mythtv-users/attachments/20120424/ce5a60dc/attachment.html>