Allow me to introduce you to OMT Technologies, Inc. and their delightful software package known as iMediaLogger. This software package is used to create audio logs of, say, radio stations. When things work correctly, someone in the building can go to a website, browse the last 15 days’ worth of hourly-generated MP3 files, and download a given file. These files can be used to verify the airing of inventory (read: “commercials”) as well as to make air-checks and “best-of” sequences.

All well and good, yes, but what happens when the software turns out to be a steaming heap of moose dung? When it becomes unhappy, it exhibits the following misbehaviour: Any attempt to click on the Events view button crashes the program. Minimizing crashes the program. Any network-based requests (API client or Web interface) are acknowledged but ignored, thus making the software almost completely unusable… even before it crashes when you try to view Events or minimize the window.

Back in May I learned that part of the trick to keeping iMediaLogger happy is in clearing out the gigantic backlog of generated HTML, ASX and SMIL files in addition to activity and error logs. You see, there’s no mechanism in the software itself to take care of this. (I know, I’ve asked their tech support department twice.) (Did I mention that their tech support department seems to consist of one guy?)

I came in yesterday intent upon doing this preventive maintenance. More fool me. I went right down the line, from Logger 1 through Logger 2 to Logger 3. I used the same procedure on each computer: Close program, delete outdated logs and web content, launch program. Logger 1 and Logger 2 exhibited all the signs of an unhappy iMediaLogger, while Logger 3 woke up and ticked right along.

Oh, damn. After some futzing, tinkering and swearing I decided to try calling Tech Support. The number given on the website is apparently the main desk, and when I asked for tech support my number was taken and I was informed that someone would be calling me right back. An hour and a half later, I gave up and went home.

This morning I tried again to call their tech support, only to be told that “they’re out to lunch.” What, their entire support department? Nice. I waited an hour and called again. After a careful and thorough explanation of the problem, the helpful suggestion I received was to completely uninstall and reinstall the software. I was also informed that the newer release available would not address my problem, and that the brand new version is due out “some time soon.” Oddly enough, this is the same thing I was told back in May…

Resigned to my fate, I dutifully noted all of the settings for the audio feeds on Loggers 1 and 2, uninstalled the software on 2, did some housekeeping, reinstalled and reconfigured iMediaLogger. The program ran just fine, so I let it do so for half an hour or so. Then, as instructed, I closed the program so I could make a “pristine” backup copy in case of future corruption.

And then the program went bad immediately after re-launching. Grrrrreeaat. So running iMediaLogger more than once is enough to cause database file corruption. Out of sheer desperation I tried using the newly-created backup database files, but to no avail. I had to blow out the database files and reconfigure the software yet again to get it running once more.

After the debacle of Logger 2, I didn’t even bother reinstalling the software when it came time to do Logger 1. With the existing install, I blew out the database files and reconfigured the software. Surprise surprise, it worked. Le sigh, le double sigh.

But wait, there’s more! At some point in this process, some bit of genius software logic decided that our existing audio files were no longer necessary. Imagine my amazement when I peeked inside the inventory directories to find them empty! What idiot psychopath programmer writes a routine to cause the automatic deletion of the audio inventory that the software is designed to create? Without any sort of prompt or message or confirmation, even? My friend, the OMT Tech Support Department, had no good answer to this question. Or any of my questions, now that I think on it. There are some pissed-off Program Directors in my building right now, I can attest.

As a bonus frustration (like wasting ten working hours on this idiotic software package isn’t enough) I was informed (during my second tech support call of the day) that since we haven’t paid $995 for a year’s worth of phone support (12 calls) I can’t call them up for support anymore. I must instead rely on email-only support. Yeah, I remember emailing them back in May. Three times. Then I gave up and dialed their number…

Let’s see: A software package that has been problematic since day one. Tech support that consists of “reinstall the program, and if that doesn’t work reinstall Windows.” (Yes, that’s what he said the second time around today, after I told him about the 2nd-run problem with the new Logger 2 install. Sure, I’ll reinstall Windows. You betcha. Even though the software works just fine when first configured, it must be Windows’ fault. Moron.) And this company wants us to pay a thousand bucks a year for phone support?

The next time any of the three Loggers gives us any trouble, we’re going to install somebody else’s software. I can guarantee it.

Streaming audio is dead. Long live streaming audio.

Months after the complete dismantling of our streaming audio systems, Entercom wants to start a streaming audio system. This time, however, it’s solely for the use of program directors around the company. Guess who gets to put together the prototype server?

Shortly after noon today, I put Rosey and The Fan online with one audio channel each. The machine is a Pentium-II 400MHz with about 192 MB of RAM and an M-Audio Delta-44 audio card. Sadly, I’m using the Windows Media Encoder to source the streams. For the money it’s the easiest way to serve two simultaneous audio streams from the same Windows-based platform.

Before the zealots in the audience get all fired up about my obvious failure to avoid using Microsoft products, I’d like to state that the purpose of my efforts is to create a system that any of my peers in Entercom can set up on their own. This rules out such arcana as Icecast under Linux.

Now that we have stereo input on both streams, the next step is to torture-test the rig so we can write up specific hardware requirements as well as installation procedures and get that info out to the markets that need it.

Some days I really love my job.

(No, you can’t have the address of the server. It’s only on the company network, so it wouldn’t do you any good. Sorry.)

A bit less than 6,000 files into a 25,000 file transfer, Beast’s RAID controller crapped out. I was forced to hard-reset the machine and start the transfer again. Luckily I’m using ‘rsync’ so only files that aren’t already on the Netware server will be copied over. If I had to start the whole transfer over after every crash, I’d never get this done.

At least, that’s the way I’m looking at it now: that Beast crashes are inevitable after X amount of data moves off the drive in one steady stream. Apparently sustained data transfer is a big no-no with this 3Ware RAID controller. Dammit.

Oh yeah. You don’t know what Beast is. Well, the Enco broadcast audio system has a central server, in our case a Netware server named KGON_FS. (Clever, wot?) I was tasked with building a cheap standby server in case of emergencies, and so Beast was born. It’s a fairly large chassis with a fairly large quantity of drive space packed inside. It runs RedHat Linux 7.0, with some customization of course.

Every night during the week, Beast synchronizes its storage to match precisely what’s on the Netware server. And in cases like tonight, where the Netware server’s large storage volume has been rebuilt, Beast is the source for restoring data to the newly created volume.

I’m praying there aren’t any crashes while I’m at home later today. Well, I would be praying if I believed in a particular deity to pray to. You get the idea. I can’t live here at the office, really I can’t.