[mythtv-users] MythicalLibrarian, symlinks and Myth: Will this work or will Myth lose its mind?

[Matt Emmott]

On Wed, Feb 1, 2012 at 4:28 PM, Raymond Wagner <raymond at wagnerrp.com> wrote:

> On 2/1/2012 16:24, Michael T. Dean wrote:
> > On 02/01/2012 04:22 PM, Matt Emmott wrote:
> >> On Wed, Feb 1, 2012 at 4:12 PM, Raymond Wagner wrote:
> >>> On 2/1/2012 15:32, Matt Emmott wrote:
> >>>> If you'd like to see how MythicalLibrarian does its thing, here's the
> >>>> output from my log as it figured out a recording of In Living Color -
> >>>> Posted to pastebin at http://pastebin.com/HqPq265Q
> >>> I know the basic operation.  I spent a decent amount of time with the
> >>> author about a year and a half back working out some bad things he was
> >>> doing to the database, and trying to encourage him to learn a more
> >>> capable and more sensible language.  Of course I failed, because it was
> >>> already written in BASH, "which everyone knows is designed for textual
> >>> data".  All that built in capability for textual data must be why the
> >>> script is a mess of calls out to curl, sed, grep, and awk to fake XML
> >>> processing.
> >>>
> >>> This script really kicked off my hatred of bash.  There's nothing
> >>> inherently wrong with bash, per se.  If you're doing some limited
> >>> variable manipulation, and just intend to string together or run
> >>> external utilities, it's great.  That, plus the fact that it's light
> >>> weight, and can be statically linked, is why it's used for init scripts
> >>> so often.  On the other hand, I see far too many instances on this
> >>> mailing list where people write absurdly long bash scripts, doing all
> >>> sorts of database manipulation, because bash is what they know and
> >>> they're afraid to leave their comfort zone.  That's not to say more
> >>> advanced interpreted languages are immune to that, as there are plenty
> >>> of other examples of things that would do well to be implemented
> >>> directly into the code base, but are left in perl/python because
> >>> "compiled languages are hard!"
> >> So, does anybody want to write a feature that does it "the right way"?
>  I
> >> need to read more about mythvidexport to see if it does what we're (I'm)
> >> looking for. I have a boatload of dual-opteron servers, anybody want to
> >> write this feature into Myth in exchange for some hardware? If I'm
> >> violating the TOS or good nature of this mailing list, then please
> >> disregard this as just a joke. :-)
> > After 0.25 is released, mythvidexport.py will be more likely to be able
> > to do exactly what you want (i.e. using season and episode information
> > from ttvdb to create the name) due to additional data available
> > for/about recordings.
>
> It already does that prior to 0.25, calling the grabbers selected for
> use in MythVideo against the title and subtitle in an attempt to find a
> match, but then that's still not quite what he's looking for.
> _______________________________________________
>

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.

One final piece about MythicalLibrarian - It does have this option:

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

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. :-)

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.mythtv.org/pipermail/mythtv-users/attachments/20120201/15e706aa/attachment.html