[Steve Modica]

Not sure what happened here. I can think of a couple possibilities.

1. You had an external drive you were capturing to, but it was not mounted. Later, you mounted it. When you did that, it “laid over top” of the original directory, this hiding your videos. I’ve seen that plenty of times.

2. You captured to something that is no longer mounted.

3. You captured to the wrong directory and that directory is not indexed via spotlight.

Steve

Steve Modica
CTO, Small Tree Communications

[Steve Modica]

[Dave Raven] “Right now, I actually just need access to the clips as I pull bites from transcripts and double-check the clips for accurate time code. Is there no configuration that would allow me to occasionally open files from a server, one-at-a-time, without the painful latency variability on an ISP?”

Hi Dave
I don’t know of a solution like you’re describing short of a leased line. That’s really expensive. Even if you had 50Mb connections on both sides, you can’t guarantee what lives in the middle. Moving between ISPs can introduce lots of odd connections. (Small Tree has two offices and we play with this sort of thing a lot for our phones. At one point, we had packets going to Colorado because of the weird connection between comcast and centurylink).

Shipping drives is not so bad. Obviously we ship a lot of RAID drives (with configured RAID volumes) and they turn up just fine.

Steve

Steve Modica
CTO, Small Tree Communications

[Steve Modica]

I don’t think there’s a solution if your intent is to edit over the network from some remote server. The latency using an ISP is way to variable.

I think your best bet is to figure out a way to move the footage via something like dropbox so you can edit locally and move things back and forth. You might want to spring for a 50Mb/sec internet connection.

Steve

Steve Modica
CTO, Small Tree Communications

[Steve Modica]

You should pull up the console app and look at the kernel log. I imagine the ethernet driver is unloading for some reason with an error.

Steve Modica
CTO, Small Tree Communications

[Steve Modica]

[Tarek Soliman] “Do you have another factors should be taken inconsideration for correct design, ? Please advise”

With latency factors, the primary issue is the storage and the configuration of the server. If you give one of our sales guys a call, they can walk through the specific requirements with you and come up with storage that can meet those requirements.

Steve

Steve Modica
CTO, Small Tree Communications

[Steve Modica]

I just tried this on 10.7 with Safari 5.1.2 viewing this page and did not have this problem. (Just so there’s another data point)

Steve

Steve Modica
CTO, Small Tree Communications

[Steve Modica]

A quick look at the Aja calculator says it’s about 125MB/sec. That’s too much for gigabit, so you’ll need 10Gb to each client. You need to pull 1.25GB/sec total.

The main problem is that each MB of data you pull over the wire needs to make it to the clients in roughly 8msec (and this includes the latency over the wire and any preprocessing that has to go on within the app like a filter).

So consider the difference between pulling 10 of those streams (needing 8msec/MB) and 50 Pro Res Streams (each requiring 45msec/MB). You could be dropping frames all over the place in the first case, but more than capable of handling the second case. It’s a huge difference and it’s a very common question for us.

Steve

Steve Modica
CTO, Small Tree Communications

[Steve Modica]

Your mileage may vary, but my testing has always shown that with a RAID setup, you need at least 8 spindles to do Pro Res HQ over a network. I’ve never tried RAID 0 since we wouldn’t recommend people do that.

Steve

Steve Modica
CTO, Small Tree Communications

[Steve Modica]

This. All filesystems need to use a best fit algorithm to try and fill holes left over from deleted files. FCP creates and deletes lots of files. Over time, you get these small spaces that the OS can’t fill efficiently. As the large hole at the end starts to get small, the OS is forced to use more of the tiny holes elsewhere in the filesystem.

Since your NAS is small, a simple solution would be to get another one just like it, and copy everything over. Then the new one won’t be fragmented and you can wipe the old one. Just don’t let them fill up. That’s a recipe for fragmentation.

Steve

Steve Modica
CTO, Small Tree Communications

[Steve Modica]

sounds like it’s fragmented to me. If you let storage get past 80-85% full, then the OS has trouble writing new files in contiguous chunks. When the chunks get small enough, the files can no longer be read efficiently. This would explain the older files working correctly.
Steve

Steve Modica
CTO, Small Tree Communications