Just a quick post to let you know about a fix to a problem that has been dogging me for the past couple of weeks with the normally rock solid Dreamweaver CS3. I’m on the PC side, so Mac folks, this may not apply to you.

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!

Testing…

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.

Just wanted to let you know about a fix I discovered for Production Premium CS4 applications.

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!!!

I’ve been doing a lot of work for clients lately with h.264 video encoding, including searching for the optimal encoding settings for various sizes of videos intended for deployment on the web and for each of the social networking sites like YouTube, FaceBook, MySpace, etc.

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.