[mythtv-users] Script to use Schedules Direct with legacy MythTV installations

[f-myth-users at media.mit.edu]

Okay, so here's what I hope is the final scoop on the process:

(a) Upgrade to XMLTV 0.5.48 if you possibly can.  If you can't, modify
    the dd_service definition to be 
      http://docs.tms.tribune.com/tech/tmsdatadirect/schedulesdirect/tvDataDelivery.wsdl
    instead of
      http://docs.tms.tribune.com/tech/tmsdatadirect/zap2it/xtvd.wsdl
    
    If your XMLTV version is older than <some undetermined version>
    (and 0.5.40 is certainly too old), it'll barf and you'll -have-
    to upgrade it.  If you're using a packaged version, you'll
    probably have to uninstall xmltv and xmltv-utils, then download
    the new version from xmltv.org and build it via "perl Makefile.PL"
    in its unpacked directory.  NOTE that it will default to -not-
    building tv_grab_na_dd (presumably because it was superceded by
    Zap2it?) and you'll have to decline the default configuration and
    say "yes" at the appropriate spot when it asks you about each
    piece.  (In Breezy, it also complained that my SOAP::Lite 0.60 was
    too old and that 0.67 was required, but I ignored this and it
    doesn't seem to have done me any harm.  Knock on plastic.)

    If you're building from source, you have to do "make" -after- that
    "perl Makefile.PL" (think of that command as ./configure :) and
    then, if you want to make things tidy for your packing system,
    install it using "checkinstall make install" at that point.  Note
    that the "perl Makefile.PL; make" bit is easy to miss if you're
    using to building (e.g.) normal C code; a "make" before the perl
    step will just barf 'cause there's no makefile yet---and for some
    reason, there's no INSTALL file in the distribution:  the build
    instructions are in the release notes for the version.  Go figure.

(b) If you've installed a package, or if your XMLTV is already
    up-to-date and doesn't require the mods for the new URL, you can
    then do "tv_grab_na_dd --configure --config-file ~/.xmltv/foo.conf"
    but ~/.xmltv MUST EXIST FIRST or it'll blow out on you.  (If you've
    edited the original script according to Josh's instructions, then
    you'll have to do ./tv_grab_na_sd, etc.)  If you've been just
    using normal DD until now w/o an XMLTV grabber, you won't already
    have ~/.xmltv.

(c) The configure step will emit a nasty-looking error message
      Use of uninitialized value in pattern match (m//) at /usr/bin/tv_grab_na_dd line 517.
    even in the latest version.  It's apparently harmless, but it sure
    seems like somebody should file a bug report; should be easy
    enough to fix.  When it prompted me for my timezone offset, I
    just took the default (+0000) even though that's nothing near
    my timezone; it looks like mfdb is doing the right thing here,
    since I compared my listings on my devo machine to the production
    machine and they agree about when things are showing.

(d) Remember that your SD username looks like an email address.
    (I got -that- step correct right out of the gate.  Yay me.)

(e) Allow it to put the password in the file, by typing your password
    at it.  (You didn't use some -valuable- password for SD, did you?
    Remember that it's not an SSL connection, so presumably it's being
    blatted out in the clear for anyone to sniff anyway every time you
    get new listings.  I haven't rigorously checked to see if maybe
    the auth is being done w/crypto, but it's easy to just assume it's
    insecure and not use a password you care about...)

(f) If you have multiple lineups, you'll have to run the configure
    step above more than once, supplying a different --config-file for
    each run; otherwise, they'll just overwrite each other.  The
    lineup ID's were apparently automatically fetched from SD; I
    didn't have to do anything special & the config script just
    prompted me for which lineup I wanted to configure each time.

(g) If you have more than one lineup, the most convenient thing to do
    is to create multiple copies of Josh's script with the correct
    lineup in each copy, and call them sequentially.  (This will cause
    Myth's mfdb to run more than once, but oh well.)  Note that
    there's quite a pregnant pause with no output when the script
    runs; it takes about 3 minutes per lineup for mine to finish, and
    there's not much output while it's happening.  Use "top" or ls the
    current working directory to reassure yourself that things are
    actually happening... :)  This also means you should be using the
    "-once" arg for each call (so you get control back) and should
    then be calling all n of them via a script that's called by cron;
    yeah, that breaks the recommended-next-download logic, but it's
    presumed that this is a short-term stopgap for a small number of
    people.  (I have no idea if there's enough locking in mfdb for it
    to work if you instead let them each run in their own process and
    they fire off asynchronously and perhaps collide; I don't feel like
    being the practice target if the locking isn't adequate.)

(h) Josh's script has all kinds of hardcoded assumptions in its
    $grabcmd line; you'll have to tell it where -your- copy of
    tv_grab_na_dd (or _sd, if you've followed his naming convention)
    is living if it's not defaultly in your search path (it will be,
    if you built a package), and the relevant config file name, and it
    had better match the lineup ID you specify in the next line down
    in $mythfillcmd.  Not rocket science, but...

Thanks for the script, Josh!  It's helped take the pressure off
upgrading my ancient Myth boxes, so now I can do so at a convenient
point in various release cycles (probably using packages and when Gutsy
is finally released in a couple months, since many lirc/ivtv/kernel
issues will presumably have calmed down by that point).