7 + 2 + 7 + 5 + 2 + 3
26.
That's the number of hours I've spent this week troubleshooting a program called "AVScheduler" for one of my clients.
So far.
That's not counting the 15 hours spent at the same station installing an new on-air automation computer that turned out to have a defective sound card.
"AVScheduler" runs on several desktop computers, but keeps its data files on a central server.
It doesn't monitor disk space usage on the server, so users have no easy way of knowing if it runs out of space.
Every time it runs, it rewrites several critical configuration files.
If it runs out of space, it crashes with the typical Windows "you should report this to Microsoft" error screen, and some of the files become corrupted.
When you call tech support, they tell you the files have to be laboriously rebuilt by hand.
When you ask tech support how the files got corrupted, you get no suggestions; a few days later you'll find the maxed out server.
You also aren't told that even though the configuration screens have spaces to enter various file paths, you mustn't use them; you have to *browse* for the files or the paths will be wrong, even though they look right.
You also have to fix these paths on all the various workstations that run "AVScheduler", because the same information that is written into the central files is also written to the local machine's Windows registry.
You can fix the program on three workstations, and if it turns out that someone has a fourth copy running in some closet, that copy can poison all the others by overwriting the rebuilt configuration files with the old corrupt information.
Do I look like an idiot yet?
That's the number of hours I've spent this week troubleshooting a program called "AVScheduler" for one of my clients.
So far.
That's not counting the 15 hours spent at the same station installing an new on-air automation computer that turned out to have a defective sound card.
"AVScheduler" runs on several desktop computers, but keeps its data files on a central server.
It doesn't monitor disk space usage on the server, so users have no easy way of knowing if it runs out of space.
Every time it runs, it rewrites several critical configuration files.
If it runs out of space, it crashes with the typical Windows "you should report this to Microsoft" error screen, and some of the files become corrupted.
When you call tech support, they tell you the files have to be laboriously rebuilt by hand.
When you ask tech support how the files got corrupted, you get no suggestions; a few days later you'll find the maxed out server.
You also aren't told that even though the configuration screens have spaces to enter various file paths, you mustn't use them; you have to *browse* for the files or the paths will be wrong, even though they look right.
You also have to fix these paths on all the various workstations that run "AVScheduler", because the same information that is written into the central files is also written to the local machine's Windows registry.
You can fix the program on three workstations, and if it turns out that someone has a fourth copy running in some closet, that copy can poison all the others by overwriting the rebuilt configuration files with the old corrupt information.
Do I look like an idiot yet?