Six Beeps and Disk Warrior
by Paul
on
Sep 6, 2005 at 3:22:03 pm
Here I am again. During a render I got the dreaded six beeps on my U320-S Dual Max. After finally powering down and restarting the drive will not appear. Tried it several times to no avail. The drive shows up in system profiler and in Disk warrior but not mounted. Any thoughts before trying to rebuild and/or any success stories with DW?
Re: Six Beeps and Disk Warrior by Lance R. Gropper on Sep 6, 2005 at 3:45:56 pm
Hello Paul:
Most of the time, 6 beeps during render is caused by the computer locking up during the render - usually a gap in the sequence, or an invalid clip setting. You will need to use Disk Warrior to bring the array back, but will need to correct the mistake in the sequence prior to attempting to rerender again, otherwise it may occur again. If you'd like, you can e-mail me the project (no clips), and I can examine it for the mistake. Also, you might be able to render smaller pieces of the sequence.
Re: Six Beeps and Disk Warrior by michael Benson on Jan 7, 2006 at 12:07:40 pm
I am also have the same problem with a 1.25 TB Huge 320R and FCP 5 and would like more details on this problem. It seems to be corrupting files while rendering.
Re: Six Beeps and Disk Warrior by michael Benson on Jan 9, 2006 at 8:54:05 pm
Yes, I am looking for more specifices on the errors in the sequences and if something the user may be doing to cause this problem. He is working on a project that needs about 300 GB and the 320R is still beeping as of this afternoon.
Re: Six Beeps and Disk Warrior by Lance R. Gropper on Jan 9, 2006 at 9:56:32 pm
Hello Michael:
Here's the complete list of beeps and what they mean:
1-5 slow beeps: The drive with that # is not responding within the alloted time period (Bad drive).
6 quick beeps: Usually indicates there was a communication problem between the array and the computer. Most of the time, this is caused by bad cable, terminator, Atto card, or incorrect/corrupt Atto drivers installed. The computer sent a command indicating it was going to send a block of data, but the block of data wasn't received from the array.
2 quick beeps: Indicates the unit mode has been successfully changed.
3 quick beeps: Rare: Sometimes occurs when the reset button is held down too long. Also occurs when mode 6 has completed (On late firmware).
We recently had two customers insist their arrays were having problems with 6 beeps, only to send them in and have us check them out and find no problem, then later had to replace their Atto cards (which had port failures). Because we provide the "beeper tool" doesn't mean that we are the cause of the problem...
Re: Six Beeps and Disk Warrior by michael Benson on Jan 10, 2006 at 12:51:30 am
Thanks, these are the 6 fast beeps that mean scsi time out or other error. the first thing I did was put in a new ATTO card and change the cable for one that is 12 inches. it has happened 6 or 7 times since then and today he lost the huge. I will bring it back up tomorrow with DiskWarrior.
What I am looking for is more info on the possibility of a bad setting on FCP causing this. clip setting as you mentioned on your answer to the start of this thread.
Re: Six Beeps and Disk Warrior by Lance R. Gropper on Jan 10, 2006 at 1:22:21 am
Hello Michael:
It's a lot of common-sense stuff, but basically there are a number of things in FCP which could cause a render to crash, consequently causing the array to 6-beep. Here's a couple of things/clues:
1. Look at the size of the project (The project file itself -- not the media or render files): If the project file is over 40MB, then something is really really wrong. 40MB would be the size of a project which is a music video the length of a feature film (i.e. 2 hours of 4-5 frame clips).
2. gaps in the video portion of the timeline don't seem to matter at the beginning or end, but if there are gaps in the sequence which are 1-2 frames in length, where there is no video on any other track, the sequence may crash during a render. These are really hard to spot without zooming in and scrolling across the sequence.
3. Down-converting HD to standard def, using QuickTime to translate can crash the system. This is a known bug, and I think Apple may have fixed it already -- the bug is in QuickTime, and not directly in Final Cut Pro.
4. Audio gaps won't stop a rendering, but will cause speaker popping if rendered.
5. Down-converting stills which are larger than 4096x4096 resolution will crash rendering.
6. Telling FCP to do a time change on a 1-frame clip can sometimes crash rendering.
There are others, but these are ones I've seen submitted by customers. Here is a story about one of them: We had a customer who placed 10 video clips (no audio) into the timeline, with no effects. When he would render, it would crash. He sent me the project, and it crashed here too (eliminating all hardware and OS/software). I decided this was rediculous, and recreated the sequence on another computer, using the exact times for each clip that he used. It rendered - no problem. I went back to his sequence and rendered each clip one-at-a-time, and noticed that the rendering would crash on clip 7 and clip 9. I looked at my newly-created sequence, and noticed that there was a 4-frame discrepancy in the length of the sequence - mine was 4 frames shorter than his. I rechecked the lengths of the clips, and when I zoomed in all the way, I noticed there were two black lines in the "green stripe" area above the timeline. I went to these lines, and found two 2-frame gaps -- coincidentally (not), one before clip 7, and one before clip 9. I manually moved clips 7 thru 10, to remove the gaps (I think I could have slug-filled them as well, or done an auto-remove gaps), and his sequence rendered fine without 6-beeping on the array.
Since then, two other customers sent in sequences, where finding and removing gaps fixed the render crashing. But something changed, as follows, as of Final Cut Pro 4.5: In Final Cut Pro 4.0 or previous, when you had a gap in the video portion of the sequence, it was really really obvious -- the top of the timeline (render bar) would have a gap in it -- the gap being the color of the background of the bar. Since FCP 4.5, they changed this, and the gap appears black. However, you can only see the gap if you zoom in to a point where the size of the gap is visible.
You don't want the gaps for another reason: If the computer somehow did render them, it will be filling them with superblack instead of black. One person I know said he thought superblack was cool since it was so much darker than black, however it rendered his video quite unbroadcastable...
