Reply to post:

Fairly certain I've posted this, but..

Back in the olden days, when I used to run a computer lab dedicated to the then trendy (and always rather vaguely defined) subject of "Multimedia". We had 40 good (for the time) spec machines, and 10 really high spec (again, for the time) machines. The really high spec machines were primarily used for video editing, so each machine had a good sound card, good cpu, and a video capture card with it's own 4 Gig SCSI drive.

All was running well, until one day, several of the applications we'd installed started failing due to missing files. Thinking we had a virus, I started investigating one of the machines. As policy dictates, I pulled it from the network, logged in with the local administrator account. Found that all the image files were missing. Unfortunately some of our software required those JPEGs, GIFS and PNGs, so failed. The virus scan came up clean. Not being one to entirely trust the virus scanner (after all, how did I know that the scanner itself wasn't infected and reporting a false negative?), I put the machine back on the network, wiped it and rei-installed the software.

Sure enough, the next day, the machine had all the software installed, and was working. So, I allowed students to use it. The day after, the problem came back.

I discussed it with my colleagues, one of whom looked sheepish, and said "I know what's causing the problem". Apparently, in an effort to keep the disk usage down, he'd written a script that, overnight, logged on to every student machine, searched for every conceivable kind of image, copied every image to his own HDD, then cleared out both those images and any student browser caches left on the machine. He said he copied the images to his machine because it's *ahem* evidence. We eventually came up with a solution to the problem, in that we adapted his script to ignore the folders that the broken software was installed in.

Thankfully, the 4 gig drives for the capture cards were never made available on the network, so his script could not access them even if it tried to.

Which brings me to a second story. Those capture cards made there drives available to the OS as what appeared to be a normal HDD. I say appaeared, because the user couldn't directly access the data, and it had quite a rigid file system. The root of the drive had folders with various file types (JPG, WAV, AVI etc), and in each folder were the project folders for user work. The weird (and I actually think quite nifty) part is the the folder structure in each of these root folders was exactly the same. The root folders all gave access to the same data, it was just converted on the fly to the data type shown in the root folder. So, your captured video file would be in the AVI folder, and you could access the individual frames in the JPG, PNG and GIF folders, with the audio track(s) being in the WAV folder. Obviously, the conversion, took a finite amount of time, so where as Premiere might take 10 milliseconds to open a JPG file on a conventional HDD, it would probably take a second to open a JPG on this drive (because the card was extracting it from the video on demand).

A student complained to me that his project was taking > 20 minutes to open on Premiere. I thought that was odd , so went to investigate. Now, on opening, Premiere checked all the media in each project, and what he'd done was to import the entire JPEG folder on the drive into his project, then put that on the timeline (Premiere will treat consecutively numbered images as frames in a video) and imported the WAV for the audio track. I explained what was wrong, deleted both the JPEG and WAV folders from his project, then imported the video file from the AVI folder. All of a sudden, Premiere was able to open the project in seconds, because it wasn't asking the capture card to extract and convert thousands of frames.