Piers Mcdonald
Forum Replies Created
-
I had a bit of fun setting up our Ultrascope box.
It’s unfortunate the Blackmagic specs aren’t particularly helpful and mostly refer to obsolete equipment, although I found it to be much more tolerant than is suggested. What I gathered from my experiments are:
1/ CPU, Important, but not as important as GPU, anything Core2Duo, i5 or dual core i7 over 2.8Ghz should suffice. Quad core i7’s may not work. I found increasing cpu speed does not necessarily increase the Ultrascope performance. Although BM do not specify that Xeons work, they probably do.
2/ RAM, only got 2GB in the system I built and it barely uses half of it, don’t think 4GB would really make any difference.
3/ Motherboard, most likely just about all motherboards will work, I’m yet to hear of a single case of a misfunctioning Ultrascope that was due to the motherboard, except for X58 based boards, which BM states are not compatible. I would recommend any mid to high end board from a reputable manufacturer that’s not X58 based.
4/ GPU, Very important, I found the GPU was the most important factor in influencing performance. I tested a 4670/512MB, a 4670/1GB, a 4850/512 and a 4870/512. There was definite lag when using the 4670s, probably up to 5 frames, and would drop frames frequently, was rather annoying to use. Also no perceptible difference difference between the 1GB and the 512MB card.
The 4850 was substantially nicer to use than the 4670 and the 4870 even better still. There is probably only a 1 frame delay with the 4870 and rarely drops frames. Haven’t tested any of the 5000 series cards yet.Hope someone finds this helpful.
If anyone is curious we settled on a Shuttle SXP48P2 with a 3.0Ghz Core2Duo/1GB RAM/ATI 4850/512MB (couldn’t fit a 4870 in the case), it’s small, light, quiet, portable and the case isn’t too ugly. But for the next setup I’m making a rack mount, the shuttle internals were a little too restrictive for GPU choices, and I want it to be as realtime as possible.
-
Piers Mcdonald
December 5, 2009 at 3:16 am in reply to: Edit to Tape upsetting Harris DL860 legalizerThanks for the help guys.
I wish it was a ref issue, but the legaliser doesn’t even accept a reference signal.
I thought I’d cracked it by setting the deck to PB mode instead of EE, thereby eliminating the video feedback loop I’d created by patching the deck in and out of the KONA.
I even managed to open and close the ETT window twice without upsetting the legaliser. But then on the third open, again it locked up and displayed unknown format.
I’ve spoken to Harris, and they have acknowledged it is a known issue.
That in this case has recently gotten a whole lot worse.Even though this hasn’t solved the problem, it is nice to finally have a nice stable video output from ETT when not assembling.
Thanks again everyone
-
Thankyou to you both Maurice and Bob!
I kind of thought I knew what I was doing ref wise and you guys have helped me fill in the blanks.
I’m going to sync everything up to PAL SD ref and just use the 1080i50 ref for special occasions when things are acting funky.
Now I don’t feel foolish for sticking HD and SD ref ports on the patch panel.And Bob, you didn’t even berate me for using an HD sync generator and not fully understanding how it works! You must be having a good day.
Thanks again guys.
-
Apologies for a bit of thread necromancy, but I thought I’d slip in my experiences.
We also have a Highpoint 3522 card that has experienced the same locking up problems as described in this thread.
It was going to be replaced with an Areca, but our supplier instead replaced it with a new 3522 that not only has new firmware but has also had a component replaced on the board that was causing problems. (He thought it was a capacitor)
This supplier is now recommending the 3522 again after this modification and apparently the card is now useable.
Although they did say they prefer Areca from a support perspective.Been using the card solidly for two days and it has not locked up yet. Although I am experiencing absurdly low write speeds. (Up to 1.4GB/s read but barely making 25MB/s write)
-
How is PAL broken in Color?
There was in issue with the PAL color space in versions 1.0 and 1.0.1 but they fixed everything in 1.0.2 and I’ve graded a full years worth of shows in PAL with very few problems.
-
I think it’s important for everyone who is tracking this issue to be fully aware that the issue is only occurring on Mac Pro towers. We have no problem cutting XDCAM on G5s and Mac Book Pros, but every single Mac Pro is a complete disaster. There are also plenty of posts from other people in similar threads who have no problem cutting XDCAM on MacBook Pros.
This appears to be confusing the issue, and has led to suggestions regarding disk and directory maintenance, which have so far helped noone who has reported the problem.
The issue is almost certainly Mac Pro hardware related, possibly has something to do with the ECC buffered memory. In the terminal a large number of memory allocation errors are reported directly before a crash.
I’m a bit surprised that such a serious issue is still occurring, as evidenced in various threads many people with serious fcp troubleshooting experience have tried and failed to fix this problem.
-
For some reason I think its a Mac Pro only problem. I thought it might be a PAL/25Hz only problem, but as you are in Lao, I assume you are cutting 25P material.
It wouldn’t be the first time FCP had problems in PAL land that didn’t exist in NTSC land.I should also add that in the Console, several hundred memory allocation errors are reported just prior to a crash.
Tried running with 2GB, 4GB and 8GB of RAM, also tried only Apple or only aftermarket (Amicroe) RAM, but the problem still persists.
-
Thanks Rafael,
I knew someone would pick up on that.
No, I definitely do not have both cards in the same system, during testing, the BM card was replaced by the AJA card. The BM drivers were removed first.And yes, regular directory maintenance is being performed. The problem is occurring on a virgin Mac Pro, with fresh drives. Whereas a 3 year old G5 with a 3 year old directory, is having no problems at all with the same project accessing the same media on the same drives.
I should also add that this is the most random issue I’ve had with FCP in 8 years of daily use. I’ve tried endless variations to try to pin down the problem, but the only constants are XDCAM, Mac Pro and 10.5. Mac Pro won’t use 10.4, so can’t test if that is the problem.
It is not caused by any specific media files, and the crashes cannot be reproduced by repeating actions. -
Hi Jason,
Glad to see we are not the only ones.
Also working on an XDCAM project, also on a Mac Pro.
Also experiencing random crashes, up to ten a day, frequently just when the timeline is redrawing. Fast timeline scrolling is dangerous, but also crashing at just about every other possible time as well, (rendering, exporting, ETT, etc)This is using FCP 6.0.4. Tried 6.0.3, but it made no difference, tried swapping RAM, tried swapping drives, tried swapping the BM card for an AJA, tried pulling all the PCI cards out and disconnecting from network, tried pretty much everything I could think of in my 10 years of troubleshooting these machines but FCP keeps crashing. (note, the system does not crash, just FCP)
The only thing we’ve done to reduce the crashing is to turn the timeline display settings to ‘name’ only, and not ‘name and thumbnail’.
specs: Mac Pro Octo 2.8, 8GB RAM, 10.5.4, QT 7.5, FCP 6.0.4, BM Intensity (and also AJA LHe)
All the while the G5 which is working on the same project, using the same media over gigabit is working just fine, stable as ever, working on exactly the same project. Running 10.4.11, QT 7.5, FCP 6.0.4.
The same thing is also happening on a Mac Pro working on a different XDCAM project being produced by the same company at a different location.
-
We’re experiencing the same problem on two different Mac Pro Quad Cores, one with an LHe, one with a KONA 3. Assembling and inserting to Digibeta is rock solid, but HDCAM is a different story. It is almost impossible to do inserts without duplicating the first frame.
This is with 10.4.11, QT 7.5, FCP 6.0.3, Prores 422 and AJA v5.1
The LHe card has been taken from a G5 Quad that did not have the same problem over it’s several years of service. But it was never updated beyond AJA v4.0.