<br><br><div class="gmail_quote">On Wed, Feb 1, 2012 at 4:28 PM, Raymond Wagner <span dir="ltr"><<a href="mailto:raymond@wagnerrp.com">raymond@wagnerrp.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">On 2/1/2012 16:24, Michael T. Dean wrote:<br>
> On 02/01/2012 04:22 PM, Matt Emmott wrote:<br>
>> On Wed, Feb 1, 2012 at 4:12 PM, Raymond Wagner wrote:<br>
>>> On 2/1/2012 15:32, Matt Emmott wrote:<br>
>>>> If you'd like to see how MythicalLibrarian does its thing, here's the<br>
>>>> output from my log as it figured out a recording of In Living Color -<br>
>>>> Posted to pastebin at <a href="http://pastebin.com/HqPq265Q" target="_blank">http://pastebin.com/HqPq265Q</a><br>
>>> I know the basic operation. I spent a decent amount of time with the<br>
>>> author about a year and a half back working out some bad things he was<br>
>>> doing to the database, and trying to encourage him to learn a more<br>
>>> capable and more sensible language. Of course I failed, because it was<br>
>>> already written in BASH, "which everyone knows is designed for textual<br>
>>> data". All that built in capability for textual data must be why the<br>
>>> script is a mess of calls out to curl, sed, grep, and awk to fake XML<br>
>>> processing.<br>
>>><br>
>>> This script really kicked off my hatred of bash. There's nothing<br>
>>> inherently wrong with bash, per se. If you're doing some limited<br>
>>> variable manipulation, and just intend to string together or run<br>
>>> external utilities, it's great. That, plus the fact that it's light<br>
>>> weight, and can be statically linked, is why it's used for init scripts<br>
>>> so often. On the other hand, I see far too many instances on this<br>
>>> mailing list where people write absurdly long bash scripts, doing all<br>
>>> sorts of database manipulation, because bash is what they know and<br>
>>> they're afraid to leave their comfort zone. That's not to say more<br>
>>> advanced interpreted languages are immune to that, as there are plenty<br>
>>> of other examples of things that would do well to be implemented<br>
>>> directly into the code base, but are left in perl/python because<br>
>>> "compiled languages are hard!"<br>
>> So, does anybody want to write a feature that does it "the right way"? I<br>
>> need to read more about mythvidexport to see if it does what we're (I'm)<br>
>> looking for. I have a boatload of dual-opteron servers, anybody want to<br>
>> write this feature into Myth in exchange for some hardware? If I'm<br>
>> violating the TOS or good nature of this mailing list, then please<br>
>> disregard this as just a joke. :-)<br>
> After 0.25 is released, mythvidexport.py will be more likely to be able<br>
> to do exactly what you want (i.e. using season and episode information<br>
> from ttvdb to create the name) due to additional data available<br>
> for/about recordings.<br>
<br>
</div></div>It already does that prior to 0.25, calling the grabbers selected for<br>
use in MythVideo against the title and subtitle in an attempt to find a<br>
match, but then that's still not quite what he's looking for.<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br></div></div></blockquote><div><br>Right, I'm looking for a file format that I can point an aggregator at and have that aggregator interpret the show and episode information.<br>
<br>One final piece about MythicalLibrarian - It does have this option:<br><br>SYMLINK=LINK - Keeps the original MythTV file in it's place and creates a
link for XBMC to read. This link is not maintained and the symlink will
remain after the original file has been deleted<br><br>So, if some sort of logic existed that could periodically check the symlink sources and prune those pointers whose destinations had been deleted, that would accomplish exactly what I'm looking for. But now we're getting pretty deep into an external app's behavior, so I'll contact the developer and see if there's a a way to bake in this logic. Feel free to chime in with ideas though. :-)<br>
<br>I look forward to .25's handling of episode data.... I'll try to keep a close eye on the release and see if I can set up a dev environment to help with the testing.<br></div></div>