Jeff Schaap
Forum Replies Created
-
If you pretend my #’s are backslashes then this is what I did:
mv “/Volumes/maxxraid1/Media_Encoder_Watch/Output/#$g.mov” “/Volumes/maxxraid1/CatDV_Previews#$p/”
and unfortunately, it returned exit status 1, so, thanks for the idea but that didn’t solve it.
-
That looks exactly the same as the command line I had posted that I already tried. Or am I am missing something?
-
I just drag them from a CatDV window directly into a Premiere (CC) bin. Works great!
-
Rolf,
Thank you for the information. We tracked it down to being a problem with a translation between SMB and AFP network protocols. We switched our PC workstation to talk to our RAID over the NFS protocol and this, for the most part, resolved the issue. Access time is slightly delayed but it is liveable for now.
We are searching two different locations for proxies so the next release will improve our speed as you mentioned. However, it seems our real problem is trying to integrate a PC into a system that was really designed for Macs and AFP.
Thanks,
Jeff -
Same problem for me… 3 years later! My situation and the unwanted effect is exactly as you described. Ever solve it?
Jeff
-
Hey All,
Thanks for your input and thoughts, they are much appreciated. I work with Eli and am one of the “daily drivers” (editor) on our systems. We ran some tests this morning and it looks like whether we are working locally or across the RAID we are reaching hardware limitations- but RAM is not one of them.
On the Z820 I put the same 20 second .DPX clip on two different timelines. One clip is located locally on a Western Digital Blue 7200 RPM drive (on a SAS/SATA controller). The other clip is a copy of the first and is located on our RAID. We have a 1GB connection to that and as mentioned before we are using NFS and not SMB (long story).
What we saw is that when we rendered the local .DPX clip all the cores showed activity (albeit low activity) and the disk I/O topped out. The RAM hovered around 4GB of usage. The render time was 54 seconds.
When we rendered the clip from the RAID all the actual cores showed activity but the hyper-threaded cores showed no activity at all. The network connection was topping out but the RAM usage again was only around 4 GB. So, this tells me that hyper-threading probably isn’t turning on because the system can’t get quick enough access to the files… It seems that adding more RAM to the system wouldn’t have any effect at all. If I am wrong, can someone explain why?
Here is the kicker… when I render this same .DPX from our RAID, on our Mac Pro station, that is only dual Quad Xeons (HALF the cores) and 16 GB RAM, the render finishes in 53 seconds! This makes me suspect that we are hitting a network bandwidith limitation. The only difference between the MAC and PC is that the MAC is running CS6 and the PC is running CC.
Argh. I welcome your thoughts.
Jeff
-
Look like WorkerNode 4.0.1d. The files I was testing are 30 FPS althought others (that I have not tested) are 60 FPS.
-
Whoo hoo! I just solved this problem (for our workflow anyhow).
First, I downloaded the Xuggle library from here: https://www.squarebox.co.uk/download/Xuggle-4.0.1065.pkg
as referenced in the CatDV online manual. Then I went into CatDV and set the following preferences:
Preferences > Import >
Under Importing media check Quicktime and Xuggle
Under Importing media dropdown select Prefer Xuggle
Under known media types UNCHECK the option “Enable MPEG parser…
That last step was the key. My guess is that by doing that it forces CatDV to import the MTS files with Xuggle. Xuggle correctly reads the length of the clips! Now CatDV plays the full length of the proxy instead of only half the clip.
I had avoided Xuggle because we tried it once for MTS playback and frankly it was awful. But by just using it to import the MTS files and read the proper length and letting it play proxies it works great.
-
I know this post is old but I will reply anyway. We are experiencing almost the exact same behavior in our workflow with AVCHD .MTS files from a Sony FS100 and our Sony VG10’s.
When we import .MTS clips I have a workernode script that has ClipWrap rewrap the MTS files in MOVs and positions them in the proper proxy path. CatDV finds the proxies and plays them just fine.
However, when importing the MTS files CATDV incorrectly “reads” the end of the clip and truncates it by half. The proxies also only play half of the length of the clip even though when played from Finder I can see that the proxy file IS the full length of the original clip. WEIRD.
-
Lee,
I’d be very interested to hear how it actually works for you in a real life setting. We are having all sorts of grief and have tried to get it working for about two years. At times it worked flawlessly on small groups of clips but falls apart on large, real world jobs.
Along the way, I’ll mention that you can actually see what files have or have not been archived by doing a query on the “archive details” and/or “archive summary” fields. These fields are blank before the clip is written to LTO and then have data in them after it has happened (what tape it went too, etc.). That is a quick way we’ve used to pull up what is or isn’t archived. But, maybe this wouldn’t suit your particular needs…
Thanks,
Jeff