A few weeks ago I had the misfortune to have a Green Hippo media server sent to me for a show by a well-known company that provides gear such as this. The misfortune was not so much that I got a Hippotizer, because they’re excellent media servers that I’ve worked with before – but this particular server (or more accurately the software on it) was a giant lemon.
There are really four separate issues here, and all were solved in different ways. I’ll take them one by one.
The first problem began when I was first telling the server to fade the layers up and down. What we (the video designer and I) noticed was that the fade-up was happening…sort of. The video appeared to pop on at 50%, then fade to 100% This seemed very odd, eventually I grabbed the layer directly, set my encoder to “fine” and started moving the layer up and down. Nothing happened until the DMX value got to 127, at which point the layer would pop to 50% (we knew the exact value by looking at Zookeeper) and would fade up from there. Very interesting. The first thing I did was to rule out the console by looking at my DMX output for that universe as I moved the dimmer, and looking at this confirmed that the console was sending the expected values from 0 to 255, and not suddenly starting at 127 and going up from there. When playing with the dimmer control directly in Zookeeper, we had no issue fading in the layer manually. Eventually, I opened up the personality editor of in Zookeeper and looked at the dimmer setting. Sure enough, someone had set the dimmer attribute of the layer personality to go from 0.5 to 1, instead of 0 to 1. Why anyone would do this was (and is) beyond me, so I changed the personality and the layer dimmer then worked as expected.
Problem the second began when we tried to play audio back through the server. It sounded…weird. As though the pitch were going up and down. This particular Hippo came with what is basically an external sound card – a MOTU device – with a TON of extra bells and whistles that were totally unnecessary to our show. That’s fine, maybe they’re necessary to someone’s else’s show. After hunting around through the (bloated, slow) MOTU software, we finally discovered that the sample rate had been set to 41,000kHz instead of the 48,000kHz that the audio was clicking by at. This one I can’t really blame anyone for, it’s just a setting you have to know about when using media mixed / recorded by someone else, so we set the sample rate correctly and that fixed that problem. I can say that the “auto” setting on the MOTU’s sample rate interface didn’t work, and had to be set manually. I could further digress into a side rant about how product manufacturers should STOP USING non-native window system widgets when coding their applets (referred to as “craplets” on the Coding Horror blog), and how it’s a huge performance hit and completely unnecessary, but I’ll let someone else do that for me.
Once the pitch problem was fixed, we noticed a further problem with the audio…it sounded as though it was clipping. We played with the output gain, the gain on the console, and the layer and master volume settings, and nothing would make the clipping sound go away. Finally in frustration, I extracted the waveform and brought it into Audacity, and looked at it directly. It wasn’t even close to clipping. At this point, with myself, the video designer, the head audio guy, and all the house audio guys being stumped, we decided to walk away and play the clip from a backup server for the first show.
This was not an ideal solution, and also my mind can’t just “drop” unexplained problems. I could play the video directly from a media player instead of Zookeeper and it sounded fine, and sounded clipped when I played it from the server software. This didn’t make any sense, because I as far as I could ascertain Zookeeper doesn’t have the ability to decide which audio interface to use, it uses whatever the default is as set by Windows. If both applications (Media Player and Zookeeper) were using the same interface, the problem had to be somewhere in Zookeeper.
Finally, I noticed that the speed setting on the media server was set at 100.4%. This was particularly odd because I knew that the speed setting on the grandMA was set to 25%, which should correspond to a speed of 100%. I unplugged the MA and set the speed to 100% manually, and the audio sounded perfect.
Next, I went over the MA and selected the speed setting, and turned it down a click. The speed on the server clicked to 98.8%. I set the encoder to fine, and clicked it up again. 100.4%. I looked at the personality in the MA. The speed channel on the personality I had downloaded off ma-share was 8 bits. (The reason I didn’t download it from Green Hippo is that they don’t provide a personality for V3 for the grandMA2 that I could find, despite the grandMA2 being like ten years old and one of the most-used consoles in the entire freaking world. Seriously, Hippo, WTF?) I went and looked at the personality in the server, and checked out the speed channel there. 8 bits. And then a thought occurred to me…what if the server software will only go at 100% when it sees a value that is exactly at 25% of the channel’s range? My personality said that “normal” playback speed was 25% of the channel. Well, that’s not possible, you can’t evenly divide 255 by 4. But you can get a lot closer with a 16-bit channel. So, again editing the personality, I added a channel onto the end to act as the high byte for the speed channel, and added another in the grandMA, turning the 8-bit speed channel in a 16-bit speed channel with 65,535 values. This also does not divide evenly by four, but you can get a hell of a lot closer, and with this workaround I was able to get the speed setting to exactly 100% on the server via DMX.
I suspect that the speed channel was originally intended to be programmed as a 16-bit parameter, but along the way someone forgot, or just figured that 100.4% would be good enough. I invite someone from Green Hippo to contact me and tell me…what’s up with that?
This fixed all the issues I was having with the server until a few days later when I had to load some new clips into the server. I first started by deleting the old clips (the clip in question was a new intro video, and I didn’t want there to be any chance of the server playing the incorrect old clip) and then rebooting the server. I then – as one would – loaded the new clip, and put it into the appropriate bin, and played it back. The clip played…with the old audio. So I tried the process again…several times. Finally, I decided this wasn’t going to work, and went into the directory where Zookeeper stores the clips. Now, when you load a clip into Hippo (as of V3) the server separates the audio and the video and saves them as separate files, video with the extension .MED and the audio with the extension .AUD, but they’re still just regular MPEGs or whatever playable by Windows Media Player or VLC or whatever. However, it also gives the files a unique reference number that is totally meaningless and like 24 digits longs, like “a7g8j8sn82bs62uhs83okjs0.MED”. So to find the clip, I had to look for files approximately the correct size in Explorer, drag them into media player, listen, and then try again until I found the right files, manually deleted them, rebooted the server, then loaded the clip again, and this time the correct audio played.
I still have no idea why the server was chasing an incorrect reference to the audio or how that might have ever happened. Certainly, by the time I got the whole thing running the way it was supposed to I was extremely frustrated, though I lacked a clear entity to direct my frustration at. Should I be angry at the rental company? At Hippo? Is it reasonable that I be intimately familiar with the deepest inner workings of the server to make it work? I’m an extremely computer-literate guy, and I have no doubt that I could have sat down with a command line, RegMon and FileMon and the other SysInternals tools, pored over the data for several hours, and at least discovered the reason this was happening, if not a magical fix. But I feel as though that’s asking too much, especially in a time-critical environment like a live show. Green Hippo presents their media servers as a turnkey solution. Certainly, nowhere in the manual do the instructions for finding the long internal filename and matching it up with its associated .AUD and .MED files appear, and the functionality of deleting the existing clip and putting in another was simply broken in this case, and only my experience in poking around where I shouldn’t helped me save the day.
In the end, the server ran without issue for the whole of the show run, and once I worked out all the kinks everything went just swimmingly. In the future, I’ll have a list of things to look out for when working with the V3.1.0 version of the Hippo software, though hopefully I won’t have occasion to run across it ever again.