I’m doing some WordPress development right now using the excellent Thesis framework and my workflow is streamlined by using a combination of Dreamweaver, Fireworks, and Photoshop in conjunction with the WordPress Dashboard and the cool Dashboard panels that Thesis makes available.

Lately, however, Dreamweaver has taken to inexplicably locking up; freezing the interface and showing ‘Not Responding’ when I continue to try to interact with it. This has just been happening recently, like within the past 3 weeks or so. Before then, Dreamweaver never gave me any problems.

I did some poking around and evidently there’s a situation when you’re editing PHP or ASP files in Code view where Dreamweaver will lock up. But this only happens just after the time change to DST ends. Evidently it’s also when  it starts. The Adobe KB Technote is kb402776.

The solution is to shut down Dreamweaver, if it’s running, find the file: WinFileCache-AD76BB20.dat, (which is corrupted somehow during the time change, of all things), and delete it. The file will usually be found in: C:\Documents and Settings\[username]\Application\Data\Adobe\Dreamweaver 9\Configuration for Win XP, or C:\Users\[username]\AppData\Roaming\Adobe\Dreamweaver 9\Configuration for Vista.

Restart Dreamweaver and it will automatically recreate a fresh version of that file for you. I did that and Dreamweaver went back to being rock solid again.

Another vexing problem tracked down and subjugated! Now back to work!

This is only a test.

Had this been an actual post it would’ve been much more interesting than this.

Follow me on Twitter!

Testing to see if the stripping of the < and > tags when published through Windows Live Writer has been fixed.

Whoo Hoooo!!! Live Writer is working again!

Robert at Esosoft is the best! Thanks Robert!

For those of you who use Microsoft’s Windows Live Writer to create your WP blog posts, if you find that your posts are showing up unformatted and with the < and > symbols stripped out, you can find the reason and the fix here.

That link contains the fix other links with background info about the problem and its causes. If your blog or site is on a hosted service, you’ll need to contact your provider and send them that link so they can update their servers.

If they don’t or won’t update and fix the problem, I highly recommend ditching them for a quality provider, like Esosoft.

I’ll be making changes to the site as I learn more about the Thesis framework in preparation for some upcoming WordPress development.

So if you’ve wandered in here and things are a mess, please pardon the construction dust. I’ll have everything back up and running shortly.

It’s called WPtouch and it was suggested to me by friend, Composer, and iPhone user Jonathan Scary.

Here’s a link directly to the WordPress Plugin site where you can download and install manually, if you’d like. If you’ve upgraded your WordPress installation to v2.7 (highly recommended!) you can click one button in your Plugins Dashboard and it will download and install the plugin automatically.

Couldn’t be easier, and it just works. You can change the colors and look and feel of the interface and icons that will be shown on the iPhone for your blog, but I left everything at the defaults and am happy with the results.

Here’s what DigitalDoyle, The Blog looks like on the iPhone:

Let all the cool people see your stuff! Give WPtouch a try.

Thanks Jonathan, for the plugin suggestion and the testing!

Update: 5:37pm
Blog pages via WPtouch on iPhone…

In the comments Amy asked how blog pages showed up on the iPhone via WPtouch.

You have to activate the option to show your blog’s pages in the plugin’s admin panel, but it’s a piece of cake. Here, via the ever helpful Jonathan, is what the About DigitalDoyle page looks like on the iPhone:

Thanks again for the screengrabs, Jonathan!

On January 24, 1984 Apple Computer released the very first Macintosh. I didn’t hear about it until I received the very first issue of Macworld magazine in March, I think it was.

Being the packrat I am, I saved and preserved that issue. That’s a scan of the cover on the left. If you click it you can see a larger version.

I had to have the Macintosh. I’d been lusting after an Apple IIe for quite a while, and couldn’t afford the ten grand for a Lisa, but this Macintosh thing was a whole new ballgame.

I went down to my local computer store… Compuware, I think it was, and happily plunked down $3300. For that princely sum I got the original Macintosh (with a whopping 128K !), an Imagewriter II dot matrix printer, and the only three, (count ‘em, THREE!),  entire programs that ran on it at the time; MacWrite, MacPaint, and Multiplan(a spreadsheet program). That was it.

I still have that Macintosh and the Imagewriter and every piece of software I ever bought for it. And you know what? It still works.

I never use it though. I keep it here on a shelf in my studio as a memento and a personal trophy.

I was one of the first people in Texas to own a Macintosh.

Here’s what it looked like the day I bought it on May 19th, 1984, and it’s on my original Unistation prototype workstation.

I justified the purchase of the Mac by using it to produce marketing materials to help get a government contract for my line of Unistation workstations (which I got a year later and had to refuse, but that’s a story for another day).

In the early days I designed, built, and sold solid oak furniture for the Macintosh. Below is a shot of some of those items. I sold a bunch of these tower stands, and rolltop disc storage boxes to the very first CompUSA store, when it opened on Beltway Rd, off Beltline Rd in far North Dallas. I was about to spend a big chunk of money (for me, anyway) on magazine ads to ramp up the business, but right before I did, a company overseas started advertising very similar units at about half the price I could make them. So that ended that. Better to find out early than late!

I use Macs to this very day, although I started switching over primarily to the dark side back in 1996 when Newtek came out with the first version of Lightwave 3D for the PC.

Eventually it got too expensive to keep software updated for both Mac and PC, and I gradually migrated all my production apps to the PC. I still love my Macs, though. I’m platform agnostic. Use the tool you’re most comfortable using and be happy.

I got my upgrade to CS4 a couple of weeks ago and was excited to get into it and start using it on projects. Adobe applications have always been extremely solid for me over the years, and I’ve grown to rely on that stability.

But I was rapidly disappointed when I crashed Flash CS4 within 10 minutes, doing nothing special or difficult at all. Then SoundBooth CS4 crashed on shutdown (of all things), after successfully letting me find the sound effects I needed for a project with the cool new Resource Manager. Then Premiere Pro CS4 crashed on takeoff. Didn’t even make it past the splash screen. When I did get Premiere to come up and tried to access and use the new Adobe Media Encoder for the first time, it crashed my normally rock solid PC so hard it instantly rebooted.

I. Was. Not. Happy.

I did like the new crash report system that Adobe’s instituted, though. You can send detailed info straight to the engineers after a crash. At first I thought maybe Adobe had released CS4 a little prematurely, as I have never had as many crashes in any of the programs as I did with CS4.

I was about to call Adobe and demand my money back and go back to using rock solid CS3, when I noticed after one crash while my computer was trying to shut down for a reboot, that I got several other crashes in background apps. One of them I recognized as my audio driver program for my Emu 1212 audio card.

That made me wonder, as I have had that one give me trouble in After Effects and Premiere CS3 a few times before, (when I attempted to use the Emu’s ASIO drivers in those programs). So I wondered if maybe checking for and installing any new drivers might make CS4 a bit more stable.  I decided to update my video drivers while I was at it.

Guess what? Not one single crash since, save a Adobe Media Encoder crash, which was actually caused by a faulty Quicktime player app (QT has always given me problems). Otherwise CS4 is solid as a rock.

So if you’re experiencing crashes in your CS4 apps, try updating your audio and video drivers and life might be a lot more pleasant and productive for you.

Oh, and CS4 ROCKS!!!

Before your eyes glaze completely over, H.264 is simply a type of video file suitable for playback on the web. It’s also the same file type that BlueRay DVD and most satellite and cable companies use to deliver HD to your widescreen. The quality of this kind of video can be much higher and the filesize much lower than ever before, and the results can be amazing.

As I was testing the videos locally, on my own hosted web server, I noticed that something that should’ve been a no-brainer simply wasn’t working. Whenever I would upload a test to the site and try viewing it in a browser, the video would most often come up completely white and the player would appear to buffer forever. The audio might or might not play, or might stutter. And when an image finally did come up, it was corrupted along the bottom of the video and stayed still. No video. Not good.

This should be the simplest of processes.  You encode your video with Adobe Media Encoder, link that video to an FLVPlayback component in a Flash document, choose your video controller options, and publish both the swf that links to the (usually mp4, f4v, or flv) video, and the html file to host it. Upload the three files to the web server and viola! You’re done.

It should’ve worked just like that. But it didn’t.

The videos would play back perfectly, if I launched them from my hard drive in a browser, but would fail when uploaded to the website.  I couldn’t deliver the files to my client if I wasn’t sure everything was perfect, so I started taking the problem apart piece by piece to try to pinpoint the exact cause of the problem.

At first I suspected that my videos were being corrupted during the ftp up to the server. But I noticed that older video files in the OnVP6 format would still play perfectly. So then I suspected the h.264 encoding. Maybe I had the wrong profile or level or data rate specified. But no, all that was on target and well within spec.

Then I thought that maybe there was a problem with the latest version of the FlashPlayer plugin, v10.0.0.0. So I googled the problem looking for significant numbers of hits with people complaining about the same or similar problem. No joy.

Whenever I find no hits for a problem I’m having, it’s a pretty good indicator that the problem lies closer to home. Often it’s staring back at me in the mirror in the form of Operator Headspace Error.

But not this time.

Since it wasn’t a widespread problem, that meant it had to be with my files, or so I thought. I double and triple checked my files, rebuilt them from scratch, built them in both Flash CS3 and CS4, built and controlled them with components and pure code, but the results were always the same. It wasn’t an Adobe problem and it wasn’t something I was causing directly. I was running out of options.

If it wasn’t my files, that only left the ftp corruption idea, (which does happen rarely), or else something wasn’t right on my webserver.

I wondered if maybe the MIME types for f4v and mp4 video files hadn’t been set up yet on the server. The file types have been out for a while now and my hosting company, Esosoft, is usually right on top of all the latest stuff, so I doubted that was the problem. But I had to ask,  just to eliminate the possibility.

I’ve used Esosoft as my web hosting company since 1996 and they are outstanding, especially their service. This time was no different. I received a reply to my email asking about the MIME types in less than two minutes. They asked for links to the problem files so they could track the problem down. I love great and responsive customer service!

About an hour later I got a reply telling me that they weren’t having any problem viewing the files in multiple browsers and on multiple operating systems and couldn’t get them to fail. That was actually very good news, though, as it meant the files were most likely ok to ship to the client and the rest of the world would have no problem seeing them.

But they also said they turned off compression for those file types (f4v and mp4), because sometimes that caused problems, and they asked me to try to get the videos to play again.

As soon as I tried them again, every one of  the files all played perfectly. The compression turned out to be the problem. I was able to ship the files with confidence, knowing they were good to go.

It was another really weird and obscure problem that was very hard to track down and solve. For some reason I seem to run into those kinds of problems all the time. Thankfully I have a gift for solving complex detailed problems, (though most of the time I would prefer things just work like they should!).

A process that should’ve taken no more than a half hour, tops, wound up taking me nearly 6 hours to track down. But I learned a lot during the process.

Moral to this story is that the key to solving off the wall problems, or any kind of problem really, is to break the problem down into smaller pieces, being patient and most importantly persistent, eliminating possible causes one by one till you find the root cause.

I hope this helps someone that might’ve run into a similar problem.

I originally started work on this blog last year, but  got busy. I deleted all the early test posts and cleaned everything up and updated to WordPress v2.7. I’m good to go.

Thanks to my good friend and creative associate Amy Stewart of Stewart Design, for the boot in the backside to get this thing up and running. You’ve done me a greater service than you know, Amy, and I appreciate it.

The comments on this post were from the original publish date.