I notice the my "channel" table contains up to 3 extra references to each channel with sourceid's that no longer exist. (These are source ID's that used to exist, but I deleted for various reasons.) While the entries don't cause any problems, I would like to clean them out as they occupy a total of 255 rows in the channel table. Using the channel editor in the setup utility is tedious, so I was considerng doing the following, and would appreciate it if someone could confirm that it is "safe" to delete those 255 rows directly from the database. ie:

0. Make a database backup
1. Stop the myth backend
2. login to webmin / mysql module
3. edit the channels table.
4. select all rows where the source = 2,3,4,5,7 (these are the sourceids that no longer exist)
5. Select the rows and delete them.

Can anyone tell me if I will be shooting myself in the foot doing this, or if I will be leaving any other "cruft" in various tables behind if I use this approach instead of using the channel editor? Thanks!

Marc

The plot thickens. I've found that the program table contains of 75,000 rows and appears to have downloaded program data for 5 sources, even through only 2 of these sources still exist. I am now considering the following as my approach:



I would repeat this for all the old source ID's (2, 3, 4, 5, 7)

Feedback would be appreciate from anyone who may have already gone through this...

Marc

Unless you have a burning need, I really wouldn't mess with it!

Probably a better approach is to wait until you're ready to upgrade to new hardware or a new version and then go through the setup "clean" instead of migrating.

I think that's what I'll do when the next release (post R5E50) comes out.

_________________
Do you code to live, or live to code?
Search LinHES forum through Google

liv2cod, I can understand why you are suggesting this, but I have a suspicion that this (non-trivial) amount of extra cruft is degrading performance with certain operations and I'd like to see if removing it speeds things up. Also, given how much time it took to setup all the clear QAM channels for my QAM tuner card, my inclination will be to do preserve the database on my next upgrade...


Marc

Well, if you really want to work some SQL magic, I'd suggest you figure out a way to export your QAM channel info and migrate it to a new installation. It seems like that would be more generally useful to you and other cable-TV users. While you're at it, you might figure out how to get the shows out of the database and into a new fresh database. Extra credit for figuring out how restore missing time-sync info for shows you have on disk but not in the database!

_________________
Do you code to live, or live to code?
Search LinHES forum through Google

Before doing any surgery on the DB, _make a backup!_

Once you've got that in the bag you can experiment freely.

For maximum cleanliness I'd actually drop my card definitions and listing sources sources and recreate them.

Just thought I would let people know that it appears to have worked. Reduced my database size by ~20MB and appears to have solved a problem I've had for several months where mythweb program listings would not show any guide data for my hidef channels. (The guide data did show up when browsing with the myth frontend.)

TJC, I completely agree about making a backup -- it's the only way to fly . I think that dropping the sources would require me to manually re-enter all sorts of stuff into the channel table for my clear QAM tuner and, based on what I saw in the DB, it doesn't appear to clear out all the cruft. A lot of the junk I just cleared out from "channel" and "program" tables is residual junk from sources I deleted a few months ago.

Liv2cod, I'm gonna pass on writing those scripts for now. Once I get around to upgrading my production system to the "E" series, I may do something at that point.

Marc

Yeah, HD stuff complicates that. I still might have tried dropping all the SDTV stuff, that way ytou get rid of all the extra data associated with the program guides like the cast and crew info for the listings.

TJC:

Good point about the SD source -- I may try that another time.

The real problem I am trying to nail down are the IOBOUND error messages I get periodically in my backend log. I've increased the IVTV buffer sizes and that's eliminated the "application reading too slowly" messages in kern.log, but I still get occasional IOBOUND msgs. So I have cleaned up and optimized my database, and we'll see if that helps by reducing database I/O. I' also just set "mythfilldatabase --max-days 9" so that the scheduler doesn't need to deal with as much data. We'll see what happens.

Marc