I recently came across a problem where I was accessing data across multiple database instances, and it was all well and good. Until you tried to use one of the first database connections again. Running anything against it would just result in a "no such table" error.

Buh? How can there not be a table there when I just queried from it not even a second before? Doing a dump of the MDB2 object itself even showed it was using the correct database information and it claimed to be using the correct database name.

Ultimately the problem turned out to be the fact that it still relies on the old mysql_* methods. This error occurred on our dev server, which is set up to model production, but isn't quite the same. On production, all our instances are actually on separate hosts. On dev, they're in separate databases, but the host and connecting information is all the same. If you look in the PHP docs for the mysql_connect() method's new_link parameter:

If a second call is made to mysql_connect() with the same arguments, no new link will be established, but instead, the link identifier of the already opened link will be returned.

Yay. So successive calls to mysql_connect() with the same host, username, and password will return the same connection. It's a good thing to have to prevent opening too many connections, but it also largely depends on your database framework being able to correctly give you separate connections if you really want them. (In fact, I might go so far as to say it SHOULD be the code that caches connections, not the underlying driver, but whatever. mysql_connect()'s new_link param does give back a new connection if set to true.) Unfortunately, MDB2 caches the database name and checks its own cached name to ensure the database hasn't been switched, so it never detects that the same connection was pulled and switched elsewhere.

The easy fix is just to call mysql_select_db() every time you're pulling a cached DB connection to ensure your DB is correct. I'm honestly not sure of the overhead of doing that, but assuming you're not making tens of thousands of those calls, I'm sure it's reasonably minuscule. I'd honestly just suggest switching to PDO and caching your own connections, anyway.

Now obviously when you uninstall the software, it will keep this directory intact since it could potentially contain some of your music files. What it doesn't tell you is that it will automatically import any data it finds in your playlists! After running through the steps of my previous posts, it was still finding some of the albums from directories I was no longer including in monitoring and it was driving me crazy. I had kept my playlists because I had a decent number and didn't want to recreate them. Joke's on me because it just took all the tracks from those playlists and reimported every single one, including ones from when I was still using the 4.2 software!

So if you had any autoplaylists created, ensure you delete those (and really probably anything else inside that directory, to be safe) or else it will still import anything it finds in there.

First and foremost is that you can no longer keep your Libraries and your Zune monitored folders separate. If you try to remove monitored folders in the Zune software, it will remove them from your Libraries entirely, which isn't even necessarily something you want to happen! So you are forced into putting all you media into Libraries, and even more than that, you're forced into keeping media out of your Libraries if you don't want them scanned!

In my scenario, I keep a separate folder for freshly-ripped or downloaded albums so that I can tag them and set them up in such a way that they can be integrated into the rest of my collection. I like to keep these separate because there's no way to guarantee how the source of the album has tagged it, or how they've set up their album art (I am fervently against putting art in tags since it's an unnecessary waste of space) or things of that nature.

At the same time, this folder does contain music, so I do like to keep it in my Music Library so I can easily access it with the rest of my music. But now I can no longer do that with the Zune 4.2 software update because it will scan it into my collection and try to sync it with the hardware, which I absolutely do not want it to do (the Zune software already has far too many troubles with tracking moved or renamed files).

I was fortunate enough to still have my installer for 4.0, and I would urge anyone who does not like this change to uninstall 4.2 and revert back. One thing to keep in mind, however, is that the software will attempt to auto-update when you run it, so you'll need to disable your internet connection during the install. After that, it will just prompt you when you open it and you can ignore it, if you'd like.

I just don't understand how it's so difficult for these guys (Microsoft and Apple) to get their software right. Why do we need it to be tied to some ridiculous piece of software? Why can't we allow syncing from anywhere? I understand that it gives them far more control over how you use your media, but it's ridiculous for the end-users to have to conform to that.

Back when zAlternator was actually functioning, I used MediaMonkey to sync and I found one thing out: The hardware has far, far less limitations than the software. The software requires you to rename all your album art to ZuneAlbumArt.jpg, where the hardware could read folder.jpg or cover.jpg just fine. The software will create a ridiculous database and throw all your files randomly onto the player where with MediaMonkey, I just synced my files over in the exact directory structure I have at home, and the player found and played it all fine.

The Zune is really a great piece of hardware, it's just such a shame to see such a terrible excuse for software holding it back.

I picked up the Java Pocket Guide for three bucks and it was well worth the money. Near as I can tell, these are complete versions of the books at hand, and they're all running with the very slick Aldiko UI, which has many configuration options for font sizes and other reading preferences, as well as the ability to bookmark and view a table-of-contents and other things.

For those of you that have a debug or rooted phone (or the ability to pull APKs off your phone via ADB), you'll find that the files are also just split up via HTML, with an XML-based table-of-contents. I've created a quick XSLT file you can use to transform the TOC into a basic HTML file so you can browse the book on your computer if you want. You'll need to make one change to the toc.ncx file, right below the <?xml?> tag:

Then put this file in the same directory and name it 'toc.xslt' (note that I haven't used XSLT or much Javascript in like 8 years, so this may suck). I've updated it to include some basic javascript for easier navigation between the pages!

I've admittedly only tried this with one book, but I can't imagine the rest use a different format.

Aldiko Book Reader:

Java Pocket Guide:

The PS3 backup detected the correct partition and backed up like a charm. The WHS, however, didn't. Instead, it detected the PS3 partition I had created. It would correctly display the full size of the hard drive in the Server Storage tab, but when adding a new drive, it would only detect the PS3 partition (which was much, much smaller).

After some fiddling around (and accidentally reformatting the PS3 partition to NTFS, whoops!), it seems like the WHS will basically just take whichever drive has the lowest drive letter alphabetically. My PS3 partition had been set up with F:\ and the Backup partition was set up with G:\, so it was detecting the PS3 partition first. I swapped the drive letters and it detected the correct partition and everything worked swimmingly.

Kind of annoying, but I'm happy there's at least a workaround. I'm a little curious as to why WHS doesn't let you treat the individual partitions on an external drive separately, though.