[mythtv] New thetvdb.com query engine (grabber)

[Robert McNamara]

On Sun, Feb 8, 2009 at 6:57 PM, Jean-Yves Avenard <jyavenard at gmail.com> wrote:
> Hi
>
> 2009/2/9 Robert McNamara <robert.mcnamara at gmail.com>:
>>
>> They were two separate thoughts.  ie, if you are curious about the
>> structure, why not look at the script? Then, as a followup, I
>> explained to you what Doug's script was and how it worked.  See below
>
> Sigh...
> I guess you miss the intent of my rhetorical question..
>
> I know he wasn't using the same structure... I knew he wouldn't before
> even looking at his code.
>

If that was the case, then why not explain you had looked at the code,
and ask what could be done to interface it with find_meta instead of
leaving us to guess what you meant?

>
>> for why I did this (as the information is presented in a fashion that
>> makes sense for a script called by the UI, not for the batch update
>> stuff).
>
> there was no need to explain, all grabbers work in the same manner.
>

Actually, they *don't*, thus the need to (repeatedly) explain myself.
One set of grabbers included with myth interface with the DB (and only
some of them using the bindings).  One set presents the data in a
format parseable by mythvideo.

>>
>> I'm aware of how Python works.  And had you looked at the script, you
>> would have seen that it would not be a drop in replacement for
>> imdbpy.py.  I have already explained what it *is* a drop-in
>> replacement for.
>
> And it could have been a drop-in replacement for more than just one program.
>

No, it would require two very different implementations with very
little shared code.

>> So why not look at the script?  Then you would *know* the answer to
>> your query-- and if it's *not* the same class structure (and it's
>> not), then would you like him to re implement it for your purpose?  I
>> assume not.
>
> And why not ?
>

So... you *do* want him to rewrite it in a manner you can use?

>
>> And as I mentioned earlier, the script isn't *for* direct usage at the
>> command line.  It doesn't even use the Myth python bindings (nor does
>> it need to).  Which as I implied, you would know if you had looked at
>
> How many times do you find appropriate to repeat yourself ?
>

Generally as many as it takes for the recipient to understand it.

>> the script.  Had you done so (and if you had known about how the UI
>> calls external grabber scripts in MythVideo) then you would know they
>> do not access the DB *at all*.  They just dump text or links that
>> MythVideo itself then handles the insertion/download of.
>
> Oh? really ?
>

Yes.  Really.  Do you disagree with my explanation?

>> Except a batch update script isn't relevant to most people more than
>> once when they first start with myth.  Doug's script *is* relevant on
>> an everyday basis as it's usable by the UI.  Which is exactly what I
>> apparently wasted my time explaining to you.  The script *doesn't use
>> the bindings*, it merely formats the information in the way that the
>> mythvideo metadata handling stuff expects it and dumps it.
>
> Oh? really?
>

Yes.  Really.   Do you disagree with my explanation?

>> A batch grabber has limited application-- it can apply to people who
>> are first starting with MythTV *exactly once*, and it can help people
>> who are pirating file squirrels.  As you have been told before, Myth
>> won't change to service those who are stealing media (the people who
>> would need to regularly batch process large numbers of files).  And,
>
> Great.. So it isn't useful to you, as such it shouldn't be useful to anyone.
>
> And following your logic, let's stop any enhancements to mythtv
> because guess what, everything could be used by the "pirating file
> squirrels" with this project.

Actually, my argument is predicated on the fact that doing the work
properly *once* will make further command line batch implementations
unnecessary.  In fact, if the effort being devoted to trying to
continue to use existing hacky tools that are likely to be removed by
.22 was devoted to doing the work properly, it would likely all be
done in time for .22.  For the pirating file squirrels, the proper
implementation is even *easier* than batch update scripts, as it would
handle *all* processing automatically without even *needing* to run a
script.  Everybody wins, even the thieves!

>
> Personally, I've only started to use the metadata in mythvideo. When I
> did I discovered that while there were tools to do most of the things
> I intended, those tools didn't do the job properly. Either it crashed
> or it didn't work. I fixed those and submitted my changes.
> Personally, I would prefer to thing not be there than having tools
> there untouched for years when they are buggy (like find_meta.py)

Because you began to use it at a time where the legacy stuff is being
abandoned and effort is being devoted to moving to new, open
information sources, as well as better ways of handling it.  The
*whole point* is that devoting information to trying to use the legacy
stuff will ultimately be wasted effort that could be better spent
getting the job done right.

>
> For an ongoing use, I rip all my DVDs on my macbook laptop then copy
> them on the mythtv machine. I like the ability to fill the metadata to
> be automatically done, not having to go through some UI.
>

So getting things done right would be the ideal solution for you as it
wouldn't require the running of a cron job/command line utility/etc.

>> So again, why not ping the MythVideo maintainer for how he sees this
>> occurring in the UI itself, then figuring out how we can all
>
> My success rate in getting any of the mythtv developers to respond to
> any of my questions is very close to zero so far ...
> I must be on their ignore list or something ...
>

I'll try to put this in a manner that doesn't seem offensive to you.
You come across as feeling persecuted by people when you don't get
your way.  I've kept my nose out of the whole VDPAU backports issue,
and the various other things you have mentioned here so far.  Nobody
has tried to persecute you, or ignore you-- My *personal* belief is
that VDPAU backports are a horrifically bad idea, and we have already
seen people on Freenode asking for help about them.  When your ticket
was closed, you appealed to the users list about it, which resulted in
a discussion calling the devs all sorts of despotic, fascist, nasty
names.  So let's call that history.  When I tried to modify this
discussion and suggest a path that might lead to real collaboration,
you feel I'm "having a go" at you.

So speaking only for myself, perhaps *that's* the problem?  I stepped
in to this discussion on your behalf.  I can see that you have a
desire to be involved in the development of MythTV and I suggested the
path that has worked well for me and others-- you get to know the
maintainer of the module you want to work on, and feel out where they
intend to go with it, then you assist in that as best you can.  I've
gotten a non-trivial number of patches applied by being amenable to
what the maintainer's goals were, and I've seen a fair amount of
functionality I wanted added for me because I was in the right place
(and in the right frame of mind) to suggest a way I would like to see
things done and ask if the maintainer was amenable to it.  If you feel
you're on the ignore list, and want to get off of it, it starts with
coming to things from a position where you acknowledge that you don't
get to decide how things are done at first.  Then, over time, you can
influence the way things go.  Then, after a bit of that, you get to
take on larger tasks of your choice and make the case for them to be
done your way.  It works well and you make friends doing it.

>> collaborate on getting myth there?  I have done/will do my part, why
>> don't we agree to abstain from hacks for a bit and see if we can get
>> the job done right?
>
>
> Abstain from hacks ?
>
> Hacks are useful to many, and that includes your LATM/AAC hack ...
>

I did not write the LATM patch.

> Most things start as a hack and get merged into trunk...
>

I would hope that nothing I have written lately has been thought of as
a hack.  A hack is bending something to work the way you need it to.
It's pretty different from an actual commit-able implementation.

> As most don't have write access to svn , everything have to be
> developed as a hack and submitted as such in the form of a patch.
>
> I really don't know what we are arguing about.. Seems like you are now
> arguing just for the sake or arguing..
>

I'm giving you counterpoint, I'm not arguing with you.  You have every
right to pursue the goals you would like with the Myth source code.
You're a grownup.  I *do* hope that I can give you some insight on how
to really get involved and get your way at the same time.