Gee, I wonder what that would do for Avid's marketing and publicity! How about a slogan - "Make edits, not bugs!"
Larry Rubin
Senior Editor
The Pentagon Channel
www.pentagonchannel.mil
BLKDOG: If you are going to run a DNA, it needs to be on the CPU's internal FW bus. Hopefuly that's where yours is.
If you are going to run a DNA, it needs to be on the CPU's internal FW bus. Hopefuly that's where yours is.
We are swapping our computer with a new HP8600. I was told by Avid tech support that our Adrenaline DNA needs to be on a third party FW card. And it's stated in this configuration whitepaper for HP8600: "Adrenaline and Mojo must connect via an add-in 1394a Firewire card (with 4K buffer) installed in Slot #1 The XW8600 embedded 1394 port should not be used." Is this different for different systems, perhaps?
"Adrenaline and Mojo must connect via an add-in 1394a Firewire card (with 4K buffer) installed in Slot #1 The XW8600 embedded 1394 port should not be used."
Is this different for different systems, perhaps?
It is. I believe that support started putting it on a PCI card for the 8600 this year. If I'm not mistaken, slot 1 in the 8600 is its own segment.
Project Manager, Avid Professional Services Group
FCP2Avid
Hi,
I'm not sure if there's a notification problem in the forum, but I've said many times above that the problem doesn't exist. It was caused solely by Avid starting to put media on a 3TB USB backup drive that happens to be on the same segment, but is only used for nightly backups. Avid had created mediafile directories on this drive and started using it, despite the fact that there's 100GB free on the DESIGNATED render drive. Obviously, the combination of a slow drive and the fact that it happens to be on the Mojo PCI bus segment, would cause stuttering. This is already a 3rd party FireWire card, BTW, so I have complete control over what goes on what segment.
But as I've said, there's no problem. MC3.0 plays back just as fine as Xpress Pro 5.8. The problem is the ancient bug, and it is a bug, that Avid will suddenly, out of the blue, start rendering to a different and not-user-selected drive, despite the fact that a specific drive is selected. There are no two ways about it, this is a bug. It's been reported a million times, and Avid seems in no hurry to fix it. One cannot fathom why, but there you go.
Best,
Per
Per, I want to make sure I'm understanding you correctly. Are you saying that (for example) when preparing to render, the render dialog box pops-up, you set a particular drive as the destination for those renders, launch the render only to find the files have been written to a drive other than the one you specifically selected in that box?
Not that I'm aware of. The render dialog will show the designated drive many (thousands) of times, so you simply click enter. Then one day, without warning, it'll start showing another drive, and you keep instinctively clicking enter because the dialog has had the correct setting 2,000 times, but now it has changed. That means that you might get half a day into rendering onto the wrong drive until it catches you out the corner of your eye that the dialog is now showing a different drive -- or the media starts to stutter, as I experienced.
The point is that you can't trust the software. You've selected one drive. It presents that drive in all render dialogs thousands of times. Then suddenly, it changes the drive. No warning. No reason. The designated render drive has tons of space. That drive has also never been disconnected or turned off. There's no reason, it just suddenly changes the drive.
So no, it's not a matter of the system rendering to a different drive than is presented in the dialog. It's a matter of the dialog suddenly not honoring the setting in Drive Filtering and making its own (new) decisions about where media should go. Since you've been presented the right drive 2,000 times, and a change is unexpected, it fades from consciousness, and you just click enter. That means that you might click Enter many many times before you notice that it has changed the drive.
Therefore, you need to religiously check that Avid hasn't changed the drive behind your back. It suddenly will. And it's not supposed to.
OK good, that's what I thought you meant, but I wanted to be sure. And yes, I've experienced that same exact issue.
Wow !
Avid switching target drive (for render) on it's own.
Interesting... I've never had that issue in 15yrs Avid editing on HP/Dell/Mac. The only site setting that does not seem to remain is the "Save Current" under Toolset. The bin/effects windows seem to appear here and there, but not consistently.
Michel
Michel:
Really? You've never seen even one deviation from what you've chosen in the media creation settings for target drives? You may be the first (and possibly the only) user that can say that.
Hi Larry,
OK, this bothers me enough that I've written a Window batch script to assist. First of all, I can't come up with a way to BLOCK the Avid from using drives, because all the previous known hacks don't work anymore. They now actually cause the Avid to crash.
But we can at least get it reported, so that if the Avid starts putting stuff on illegal drives, then we'll know.
I've written the following batch script, which tells you if there are any Avid MediaFiles or OMFI MediaFiles folders on specific drives. If there are none, the program quits and disappears within 0.1 seconds. If there are problems, it'll report which drives have been tampered with by the Avid and stop with "Press any key to continue...".
You can schedule it to run nightly so it doesn't interfere, which is good enough, because then you won't make it far into using the wrong drive, and you can fix it before you start rotating the wrong drives and making the problem permanent. You can also schedule it to run every hour but only when CPU is below 5%, so it'll never run while you're editing or capturing. Use Windows Scheduler, that works fine.
Simply paste the following into a file called "testavid.bat", dump it on your C Drive, and schedule it to run. If nothing is wrong, it returns immediately without feedback.
@echo off
set stop=0
:: Check drives for Avid MediaFiles:: When duplicating, remember to change echo statement too
IF EXIST "G:/Avid MediaFiles" (echo Found Avid MediaFiles on Drive Gset stop=1)IF EXIST "K:/Avid MediaFiles" (echo Found Avid MediaFiles on Drive Kset stop=1)IF EXIST "L:/Avid MediaFiles" (echo Found Avid MediaFiles on Drive Lset stop=1)IF EXIST "M:/Avid MediaFiles" (echo Found Avid MediaFiles on Drive Mset stop=1)IF EXIST "S:/Avid MediaFiles" (echo Found Avid MediaFiles on Drive Sset stop=1)
:: Check drives for OMFI MediaFiles
IF EXIST "G:/OMFI MediaFiles" (echo Found OMFI MediaFiles on Drive Gset stop=1)IF EXIST "K:/OMFI MediaFiles" (echo Found OMFI MediaFiles on Drive Kset stop=1)IF EXIST "L:/OMFI MediaFiles" (echo Found OMFI MediaFiles on Drive Lset stop=1)IF EXIST "M:/OMFI MediaFiles" (echo Found OMFI MediaFiles on Drive Mset stop=1)IF EXIST "S:/OMFI MediaFiles" (echo Found OMFI MediaFiles on Drive Sset stop=1)
:: Stop if anything was found to keep window on screen:: Replace the following line with the word "pause" without quotes for testing
if %stop%==1 (pause)
I'm really gonna have to give myself some compliments here, this solution totally works! Yesterday, the Avid again, out of the blue, started rendering on a different drive than the drive selected as the rendering drive. This is UTTERLY CONFIRMED. I managed to get 5 seconds into rendering an effect, when I suddenly felt it didn't say "SafeRaid 2Z (Z:)" in the Render dialog. I cancelled the render, did it again, and sure enough, it had changed to "Backup 2B (L:)".
I changed it and went back to rendering on the (friggin) designated drive.
But the good news is that a few hours later, the script came forwards and told me that there was an "Avid MediaFiles" on the backup drive.
Avid is really stepping way out of its bounds here. What exactly is the point of having a Render Drive in the GUI, when the Avid will, through buggy programming or boredom or whatever, suddenly switch to another drive? I have 100 GIG free on the render drive, and the render drive is an internal RAID 5, and the OS boots off of a partition on it, so it has NEVER been disconnected. The Avid has zero reason, I repeat zero reason to suddenly switch drives.
Excuse the comparison, but in some regards, Avid is like an old piece of Windows 98 shareware that hasn't been updated in a decade but is still used because it barely works. This is just poor engineering. Avid can really not have a lot of respect for its customers when it lets such a well known bug sit around for 10 years.
I'm really starting to get a little tired of Avid for this and similar reasons. I detect a behavior in companies who have come to feel indispensable, that a certain fascism develops, where the mentality is that "we're so big that we can do whatever we want". Google does the same by adding Sender: headers to Google Apps emails so that anyone can see the emails come from Google Apps. Microsoft cripples IMAP in Outlook. As for the iPhone, well, who's counting. The point is that a smaller company, which has something to prove, can't behave like this, and doesn't behave like this. The only thing that prevents bugs like this from being fixed in a small company, is lack of resources. But to a small company with something to prove, bugs like these are an emergency, and a PR problem, and have to be fixed ASAP. Avid on the other hand, is so confident that you're forced to use Avid whether you want to or not, because "we're a standard", that they can ignore such obvious and grotesque problems without doing anything about them, because "our users are so loyal, and have so much invested in our products that they can't simply walk". "We're Avid, we're great, and you HAVE to use us, whether you want to or not. Therefore, we don't have to do anything to keep you as a customer".
I'm really tired of this. If our company ever becomes successful enough to dominate our particular market, we'll never develop this kind of fascism. There is such a thing as doing the right thing, even if you don't have to. I would never let a well documented bug like this slide for years and years. And I can't wrap my mind around the mind-set that says that it's not worth the 5 minutes of coding to fix it.
But regardless, at least this alarm-script works. It just came forwards to tell me that Avid had started using the rotating backup. So now I can fix the problem before this backup gets rotated into a Fire-Safe.
Avid Technology, Inc. brands: Digidesign | M-Audio | Sibelius | Pinnacle Systems | Sundance Digital
© Copyright 2000-2008 Avid Technology, Inc. All Rights Reserved — Legal Notices | Terms of Use | Privacy Policy | RSS Feeds | Site Map