How To Troubleshoot

Troubleshooting seems to be one of the least understood concepts of working with computers. Everyone is familiar with having software problems, and most people have a friend that they can call for advice on how to fix the situation. What is not understood as widely as it really should be is how easy it is to troubleshoot something yourself. Even if you don't solve the problem yourself, the legwork you can do on your own, before calling for help, provides very useful information to anyone trying to fix the problem for you.

Troubleshooting is a very logical exercise, and often one that involves a simple process of elimination. You have to be observant, and note when you can get the problem to happen, and equally importantly, when you can't. You also have to be aware of the immense amount of knowledge available on the Internet to help you solve any type of problem. If it's a problem with OSX, there are sites such as macosxhints.com or the Apple Support Site and Discussion Boards. Microsoft has their own useful support site. If it's a problem with Avid, then try searching the Avid Community Forums. Or just search Google, which often times has already indexed all these sites for you.

I think the big thing you need to remember when troubleshooting is this: Someone has had your problem before, and has found a way to solve it.

That bears repeating. Whatever problem you are encountering has almost certainly been encountered before, fixed or worked around, and written about on the Internet. Even if it hasn't been fixed, it's probably still been written about, and you can put your mind at ease by knowing that even if you have to wait for the next version to come out, at least other people are suffering also and it's not something unique to what you're doing.

And another thing: Looking up solutions on the Internet isn't cheating. I once impressed another assistant editor by fixing her problem with a deck configuration, only to have her turn around and scoff when I told her I'd just looked up the answer on the Avid forums. Being a good troubleshooter has nothing to do with knowing all the answers in advance, but it has everything to do with knowing how to find the answers quickly. The more problems you solve through your own research, the quicker you'll get at zeroing in on the sites most likely to have the solution to your next problem. And don't forget, if you solve a problem no one else has solved yet, write about it! Find a forum that talks about the problem you're having, and post the solution for everyone else who encounters this problem after you.

If in the end you are unable to solve the problem you're having, but still think it to be a solvable problem, make sure to tell the person you call for help all the steps you've done already. Otherwise they'll just waste their time repeating all the steps you've gone through just to get to where you are already. For example, when my Internet goes out and I call AT&T, I usually get myself bumped directly up to their Level 2 support because I immediately tell the guy who answers the phone at Level 1 all the things I've done already. Those guys at Level 1 just have a book of common procedures that people usually don't bother to do on their own, so if you call and tell them that you've already done everything in their book, you save everyone the time of troubleshooting for the wrong solutions and get bumped up to the people who actually know what they're doing.

The other thing I tell people who have a problem they need to troubleshoot on their own is that they should not be afraid to tinker. If you're at all hesitant about troubleshooting on your own, you're one of the least likely people to cause any serious harm. So go ahead, play around. Try to reproduce the error and see if you can identify the conditions under which the error occurs, and those under which it doesn't. Once you know the conditions under which the error occurs, you might then try a divide and conquer approach. This means that you go one by one through all the steps it takes to recreate the error, and test all the options to see which of those steps is the actual cause. It's kind of like a choose your own adventure book. At each step, try all the options and see what happens. Oftentimes, this approach will not only tell you which specific action is the cause, but it will also give you a good idea of what to do to fix it or find a workaround.

Lastly, I am always wary of phone tech support people who try to fix the problem for a few minutes and then give up and tell you to reinstall or reformat. In my experience, when you reinstall an application, you may reset the problem, but you haven't fixed it and it is likely to come up again. When you reformat, you're spending hours of time getting back to where you were without any guarantee that the problem had anything to do with the steps you've just taken to try to fix it. Reformatting is an especially drastic step that I find to be recommended by tech support people far more often than is actually necessary. A little patience and inquisitiveness will go a long way towards fixing your problem quickly, and in a manner that's not nearly as destructive as reformatting or reinstalling.

An Avid Example

On Hellboy 2, I ran into a Bus Error when exporting an AAF with Embedded Media. This was strange, since I'd exported tons of AAFs with Embedded Media already, and there was no reason that this process should now not work. I was even more discouraged because Bus Errors, as any Mac Avid user knows, can be incredibly obtuse and can have any number of causes. Reproducing the error reliably took a little while to accomplish, but I soon figured out a pattern. I was sometimes able to export an AAF or two successfully out of however many reels I'd selected, but the more sequences I had in the bin I was exporting the AAF from, the more likely it was to crash during export. Not only that, but the first part of the AAF export process always seemed to work, it was in the time after consolidation but before actually writing the AAF file that Avid would crash.

What I took to doing as a workaround was creating new bins, putting just a few sequences in each, and exporting AAFs for only 2-3 reels at a time instead of all 7. But one day when I had time to spend on troubleshooting, I got to actually figuring out the cause, and it was much simpler than I had imagined. Basically, when you export an AAF with Embedded Media, what you are essentially doing are these 3 steps: consolidating a sequence, saving the bin, and then copying all of the newly-consolidated media into the AAF file as it's being written. I selected one of my sequences and did the consolidation manually, saved the bin manually, and then manually exported an AAF with the consolidated media. No problem. I then selected a second sequence, since I knew the problem didn't always occur the first time around, and repeated the process. When I went to save I suddenly got a helpful error message that said I had too many clips in the bin for Avid to be able to save it. I moved a few sequences out of the bin and deleted the previously consolidated media that I no longer needed, and then Avid allowed me to save.

Based on that error message and my troubleshooting steps, it seemed that the problem during my AAF export was the same error without the helpful error message. After a reel or two had been consolidated, I then had too many clips in the bin for Avid to be able to save it. Additionally, all of the clips that were referenced in the sequences in that bin contributed to the total clip count. So even if I had only 6 sequences in the bin, in Avid's eyes that bin still contained thousands and thousands of clips. The problem was simply that Avid only knew how to handle the error of having too many clips in a bin when you approached that limit through manual consolidation. When you wanted to do a compound process like exporting an AAF with embedded media, Avid ran into the same clip count limitation, but without the error code programmed in to handle it. And, at least on Macs, when Avid is overwhelmed or encounters an error it doesn't know what to do with, it crashes out with a Bus Error.

So in this case, the workaround I came up with before I knew what the problem was ended up being the right solution anyway. But by knowing what the cause of the Bus Error was, I could not only avoid running into it, but I could also rule out any other, deeper problem.

Conclusion

When things start going wrong, don't waste your time waiting for help. You are unlikely to break things more than they already are, and you're actually more likely to fix it than you think. Just be patient, careful, and work your way through the steps it takes to recreate the problem until you can diagnose what the specific cause is. Between the steps you take to troubleshoot your problem, as well as the vast amount of troubleshooting information available on the Internet, you should be able to greatly decrease the amount of downtime you suffer due to technical problems.