MySql is a registered trademark of Sun Microsystems, Inc.

 Disclaimer: This documentation is not official or authorized in any way by any third parties.  Use the information at your own risk.

I've been lucky enough to be able to live without an undelete feature on my computer for years.  For the most part, I haven't had many problems - usually I have a backup copy of the file I can work with.  In this case, I had a backup, but the problem was it wasn't just a file that needed to be restored.  I was trying to delete a recording in my mythtv system and I managed to hit the arrow key at the same time I hit the menu key.  Without realizing it, I had deleted a recording from the system that I hadn't watched yet.  If that wasn't bad enough, I also don't have the system set up in such a way that I can undelete any recordings.  Since I have the actual video file in a backup location and since I have running backups of the mysql database, I decided to take a quick look at how I might be able to recover the recording.

Putting the recording back into the storage group is by far the easiest part of the process.  The much larger problem I had to deal with is the database and I actually expected the task at hand to be a lot harder than it turned out to be.  What I wasn't prepared for, however, is just how much data mythtv stores about a single program.  To give an overview, here are some of the more important tables (as of 0.21-fixes):

• recorded - This table contains the program start time, end time, title, subtitle, description and a few other pieces of information.
• recordedmarkup - Contains the bookmarks used by the automatic commercial skip feature
• recordedseek - A huge table containing seek information for each 1/2 second of recorded video.  A one hour program has about 13,000 entries on my particular system.
• oldrecorded - This table contains much the same information as the recorded table, but it's only used by the scheduler.
• recordedprogram - Contains in-depth program details for each recording in the system.
• recordedrating - Contains rating information for each recorded program
• recordmatch - A mystery table.  I assume this is used by the scheduler based on what I see of the table's columns, but the documentation in the wiki doesn't describe it. (http://www.mythtv.org/wiki/Category:DB_Table)

...and that's all of the places where data is changed when a program is deleted as far as I could figure out.  The information about the first three tables I got from the backend server source code in mainserver.cpp:DoDeleteInDB().  For my particular situation, I created a new database on another Linux system and restored the database to the state it was in prior to me deleting the program.  I then spent some time comparing the actual database to my restored database to figure out where the changes were.  For each place where I found data had been altered or deleted, I used mysqldump to create a script I could use to bring the data back into my live system.

mysqldump is the  reason I'm writing this post.  Sometimes it's easy to overlook the command line possibilities, but they sometimes contain some very powerful features.  In this case, I needed to dump out large amounts of information in a format that could be imported to the other database without having to do a lot of editing of the dump file to get the correct results.  As a rule of thumb, the more you can eliminate human involvement in a process, the less mistakes you'll make along the way - so editing dump files was something to be avoided. 

The primary information needed for this is the chanid and the starttime of the program.  Once you have that information, you can use it to select the information you want when you make the dump from the database.  Here is an example:

$ mysqldump --skip-opt --complete-insert --no-create-info --order-by-primary mythconverg --tables recordedseek --where="chanid = 1311 and starttime = '2010-01-14 21:00:00'" -u root -p >>program.sql

In this example, most of the options cause mysqldump to only output insert statements and the reason behind that is I didn't want or need to drop or create any tables which may have caused a much larger loss of data.  The --tables parameter tells mysqldump which tables you want in the output file.  The --where parameter allows you to select specific information from the table so that you don't get any information you don't need or want.  This is the key to using mysqldump effectively when you need to do a partial restore of information between two databases.  I repeated the above command for each table in the list above and created a script that could be run on the live system to import the information back into the live database.  Restoring the database information is easy:

$ mysql -u root -p mythconverg <program.sql

After entering a password and waiting a few seconds, I simply restarted mythfrontend and all of the information about the recording showed up in the watch recordings section of mythtv.  Playback is just as I would expect if I hadn't accidentally deleted the recording, so I'm going to consider this a success.

First, I would like to make a request of anyone reading this.  If you post in some forum somewhere about a problem you've been experiencing, please take a few moments to also post what the solution was after you've gotten your problem figured out.  I spent a good amount of time researching why I was getting the error in the title of this post and while I could easily find posts online describing the issue, it seemed like almost no one took the time to post the solution.  Those of you who do post your solutions, thank you.

This week we've been working on installing VMWare VDI/View so that we can do an evaluation of the product.  Part of that installation process involves setting up a SQL Server database for the vSphere and View pieces of the software and though we could have used MSDE or whatever MS is calling it these days, we wanted to mirror a production environment as closely as possible.  This means that we wanted to use SQL Server 2005 as the back end database and use an Active Directory service account to grant access to the database which is the best practice standard in our environment.

After configuring the account in the AD and setting group memberships, I proceeded to add the new service account to the database server, create a database for the user, make the service account the database owner, and grant further access to the msdb system database.  All of that seemed to work perfectly until it was time to create a data source so the vSphere could access the database.  Suddenly, the service account couldn't connect and the above error was appearing in the activity log on our SQL Server.

Of course, the above error means that the server was able to verify the account as valid, but had denied the logon attempt.  (Note to the MS SQL Server Product Team: this error is useless without knowing WHY the logon was denied.  Makes me wonder who did the QA on this product...) I spent some time searching online forums for a solution and I actually found one post that mirrored my situation exactly.  The only problem was the original person who posted it didn't mention if others had helped solve the problem.  Instead, they came to the forum, posted their problem, got some advice, and disappeared into the ether to never be heard from again.  I didn't want to follow the advice in the thread because it seemed like I'd be going in circles.  After all, I just created the account, added it to the server, and granted rights to the account only moments prior to this.  How could anything be different?

In an attempt to isolate the issue, I added one of my test accounts to the server and made it the owner of the database.  I then went back to the vSphere server, added the test account to the local administrators group, and logged in under the test account.  When I then tested the connection to the database, it worked as expected. Since I couldn't figure out what was different between the test account and the service account, I ended up deleting the credentials from the SQL Server management console, removing all of the rights I had granted, and then finally adding all of that information back to the server.  Strangely enough, that worked.

I have no explanation as to why that worked as a solution, but next time I run into it, this is the first thing I'm going to try.   Hope it helps.

Yes, this site is hosted by GoDaddy.com for free.  But what you probably don't know is that they are giving me free hosting only because they are my domain registrar.  For each domain you register with them, they give you a free web hosting site.  What they don't tell you is that they will use your site to advertise their services.

I'm not saying GoDaddy.com is a bad registrar.  I've used their services for some time and I'm mostly happy with the service I've gotten from them, but I do think it's a bit odd that they charge as much as they do and then have the audacity to use your site as a crass advertisement.  Normally, you wouldn't see that ad at the top ... I just haven't figured out who I'm willing to pay for hosting yet and until I do figure that out, I guess you'll just have to learn to ignore the advertisement.  I apologize for that.

Anyway - I thought that readers of the site should be informed...  I wouldn't be happy to hear that someone picked up GoDaddy.com as their domain registrar or their hosting provider based on what you see here, anyway.

Well, there's a couple of bugs.  First, the first post in the database won't publish for some reason.  I've been going in circles, but no matter what I do, I can't get the software to show the first post in the database to anonymous users.  We'll email the author about that problem.

The second thing I noticed is that this site won't show to anyone using Firefox or Chrome.  Both of those browsers report will either report a network error or they report that the site is using some kind of compression that isn't supported by the browser.  This happens even though I've  gone into the settings and turned all of the compression settings off.

Since this works fine on IIS 6 and before with those browsers, I'm suspicious that a setting in my web.config is doing this and that the fault is located in the System.WebServer section.  It seems as though whenever you have a compatibility issue between IIS6 and IIS7 and above, it's the result of Microsoft breaking backward compatibility with legacy websites.  It sure would have been nice if they would have given developers a migration tool, in my opinion.  If you know of an easy way to convert web.config between IIS versions, please let me know in the comments (if those are working, that is.... haven't tested it yet).

About a week ago, I suddenly discovered that my hosting account was suspended. Apparently at the end of November, my credit card expired and that's about the time the site was suspended. You might then wonder why ti took over a month to get the site back online and the answer to that is my hosting provider didn't exactly do their due diligence to let me know about the situation. I'm not naming names, but if you're reading this - you know who you are.  No, it wasn't GoDaddy - I cancelled my account with my prior hosting provider because we couldn't come to an agreement.
 
So - that's how we got to where we are today. I'm playing around with some different blog software - mostly to see what's currently out there. I still have my original blog software and all of the information that was on the site so I'm planning on bringing it back at some point. However, in the mean time, it doesn't hurt to see if there's something I like better that's also open source.
 
One thing to note is that since I really only just started with this software, there are some things that probably won't work correctly out of the box. I'm sure we'll get it all ironed out soon enough though...