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