[mythtv-users] Experiences with 0.19 and Schedules Direct

Scott M. Sorrentino scott at sorrentino.net
Sat Aug 25 14:37:23 UTC 2007


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

In case anyone's interested in getting Schedules Direct working with a MythTV
0.19 install, below is a copy of my experience that I posted to the Schedules
Direct forums.  

I realize that a new release of Myth has just come out with SD support and
that is obviously the preferred path for most.  Myself, I am always slow to 
upgrade due to my Myth box's "appliance" status with the family and the 
various things I customize to make Myth "my own".  So, for anyone else like
myself out there that can't or won't upgrade Myth in the next few weeks, here's
one option to keep things going until we can upgrade.

- --

I am currently subscribed and running MythTV 0.19. I did the following to make
Schedules Direct work for me with my existing version. I should note that I am
no stranger to mysql, coding and system interaction and that made this process
easier, despite the length of this post. People not comfortable with the steps
outlined might be better off attempting a packaged upgrade of MythTV. Read on
and see if this might work for you.

Prep:
1. Create account with Schedules Direct and add lineup(s)
2. Download, compile and install xmltv-0.5.48 from http://xmltv.org/
3. Configure tv_grab_na_dd with my SD login/lineup info
4. Run a test grab of one day's data via tv_grab_na_dd
5. Fix temporary table creation in libmythtv.so.

The last "prep" step is is the only step that required the Myth source. I had
it, since I built Myth myself, but others relying on binary distros might not.
The file libs/libmythtv/datadirect.cpp contains several temporary table
creation stanzas that set define programid as 12 characters. The new programid
is 14 chars, so each instance of "programid char(12)" needs to be modified to
"programid char(20)" I chose 20 as that was the size of programid in the
program table. I counted 5 references that needed fixing. Once the source is
updated, a simple "make" in libs/libmythtv/ will update the shared object
(libmythtv-0.19.so.0.19.0); copy that over your existing shared library and
you're set.

Not taking this step will result in truncated programids in your "program"
table, causing quite a bit of trouble and confusion. The first time I tried SD
I had not fixed libmythtv and wondered why MythTV was trying to re-record old
shows and why the guide data looked odd. It took a few tries for me to see what
was happening and why libmythtv needed fixing.

Migration:
1. Find a time when the Myth system wasn't being used (recording/viewing/etc).
2. Stop mythbackend.
3. Back up mythconverg MySQL database (simple mysqldump to text file is
   sufficient)
4. Run the following SQL commands on the mythconverg database to update the
   existing programids in the recorded and oldrecorded tables. This ensures
   Myth won't "forget" it recorded a show because the SD programid is
    different:
    UPDATE recorded SET programid=CONCAT(SUBSTRING(programid, 1, 2), '00', SUBSTRING(programid, 3)) WHERE length(programid) = 12;
    UPDATE oldrecorded SET programid=CONCAT(SUBSTRING(programid, 1, 2), '00', SUBSTRING(programid, 3)) WHERE length(programid) = 12;

5. Download a full set of listings (13 days) via the tv_grab_na_dd grabber.
   tv_grab_na_dd --download-only --config-file <config file> --days 13 --dd-data <data output>

6. Run mythfilldatabase on the downloaded file from step 5, substituting your source id and lineup id:
   mythfilldatabase --refresh-all --dd-file <sourceid> -1 <lineupid> <data output>

7. Restart mythbackend with the "--nosched" option, just to check things out.

I chose to stop mythbackend prior to the update simply to ensure my database
backup would be "good", giving me a state to revert things to if something went
wrong. I suppose someone with a busier system could manually fix programs
recorded/deleted during the "update" if they wanted. I was playing it safe.

If everything looks okay, restart mythbackend without the "--nosched" and you
should be set. One step I took to help with the "Looks Okay" check was to use
MythWeb before and after the update. Prior to shutting down mythbackend
(step 2), I opened three MythWeb tabs in Firefox, one with the "listings" view
for a specific time frame, one with my "upcoming recordings" and another
viewing some random program. I kept these tabs opened and, after the update,
opened three new tabs for the same URLs. This allowed me to check that the
listings were identical, the schedule looked right and that I could see the
updated program ID for the random program I had chosen before. Those without
MythWeb will need to find their own validation technique.

If something goes wrong, just stop mythbackend (optional) and import your
database backup: mysql -u <user> mythconverg < <backup file>
Restart mythbackend and you should be back to where you were before the update.

I disabled the automatic run of mythfilldatabase from within MythTV. From this
point on, updates need to be a two step process: Grab data file with XMLTV and
run mythfilldatabase on that file (Migration steps 5 and 6). To make this easy,
I wrote a script to grab the data, run some tests to make sure it looks valid
and then run it through mythfilldatabase. Any errors result in an email to me.
This script will likely run from cron. I have seen posts from folks who have
replaced mythfilldatabase with their custom scripts so it can still be kicked
off by mythtv (rename/move actual mythfilldatabase command to something else
so you can still call it from your script).

For those not able to recompile libmythtv or just looking for another method
of using their existing Myth install with Schedules Direct, I did see a post
on Myth-Users that took a different approach to the programid change:
http://www.gossamer-threads.com/lists/mythtv/users/285196. This approach looks
like it takes the 14-char programids and drops two characters. I have not tried
this so I don't know how well it works or how long it will work. I assume the
programid is longer for a reason.

Despite the length of this post, the actual "update" to use SD was fairly
quick and painless. I spent the bulk of my time working out the details such
as finding the libmythtv problem and working quite a bit on my custom
grab/mythfill script.

- --
Scott M. Sorrentino <scott at sorrentino.net>
AIM://sinepaw :: JABBER://scott@jabber.sorrentino.net :: HTTP://sinepaw.org/

GnuPG fingerprint: 5A4D C6C0 2B40 9644 36E7 19A7 31E5 56D5 7F5F 631F
       public key: http://sinepaw.org/personal/gpgkey.phtml

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFG0D6jMeVW1X9fYx8RAghOAKDXbTcW7KYElEv0J68g/m2YY/+e3QCfU1CQ
hjHlc5mDJQc4zJk0FQt6M9s=
=JyTs
-----END PGP SIGNATURE-----


More information about the mythtv-users mailing list