[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