[mythtv-users] Labels instead of Recording Groups
Michael T. Dean
mtdean at thirdcontact.com
Tue Apr 24 02:02:44 UTC 2012
On 04/23/2012 05:44 PM, Joseph Fry wrote:
>> 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>+ specifically
>> 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.
Mike
More information about the mythtv-users
mailing list