Signal chain question - BM ultra studio mini recorder - data transfer speed?

[Marcus Friedlander]

Hello everyone,

I have a question about the BM mini recorder. How much data can that box push per second?

The reason I ask is, I'm running a workflow that is recording from a DVX-200, running into an Atomos recorder, then out to the mini recorder, then into a Mac laptop running Black Magic'a capture software, and then ultimately writing to a G-raid. However the BM program is crashing more than I would like, and it's causing issues because we are shooting a live event (luckily we have the Atomos as a backup)

I'm trying to nail down the exact cause of the instability, and I think it may have to do with dropped frames. My hypothesis is that there is a bottleneck somewhere in the signal chain, but I can't figure out the exact cause of the crashes.

My current theory is that there is something funky going on with the mini recorder, but it's happening so sporadically that it's hard to pin down. So I decided to check out the specs to see if there was a chance that it could be the bottleneck, but couldnt find a solid number in the manual.

Does anyone know if the mini recorder could potentially be causing this? Or if you have any other suggestions on things I can try or test, please let me know! Thanks!

 

[Marcus Friedlander]

A thought just popped into my head, the G-raid is a spinning drive. Could the fact that it's not an SSD, mean that at some point, the drive won't be able to keep up with the recording?

 

[Craig Parkes]

Run the Black Magic Speed test application on the G-RAID - almost certainly it will be having issues with continuous write over a long period of time. Especially if the drive is not a large completely fresh RAID0 with plenty of overhead in terms of your recording format. The more you have recorded to the G-RAID, the more likely a crash. Most capture software will allow you to select a maximum individual file size limit for live capture. Designed to get around Fat32 limitations this can sometimes be helpful for also avoiding losing an entire recording on crash.

Also it's important to make sure the G-RAID is formatted to the most stable and fast disk format that will work with the operating system (In this case probably HFS non journaled) and to make sure you don't have any other apps running that might try and access the disk.

Also there ensuring that the Macbook Pro has no power saving features on - these could theoretically idle the drive that is being recorded to.

 

[Marcus Friedlander]

Awesome! Thank you so much for your thorough reply.

Unfortunately, we have wrapped for the weekend and our gear is currently in transit to our next city, so I won't be able to run these tests for a couple of days. But as soon as I get my hands on it, I'll try out your tests!

P.S. After the video has been captured, it is sent through a network to a windows 7 server for further processing and delivery to client. Which means that the person sitting at the server WILL occasionally have to access the G-raid (through the network) to make fixes in the event the videographer mislabels the files (and with 500 different performances in a weekend, it's an inevitability.) You mentioned that we should limit the other apps that have access to the G-Raid, does that also apply to the server accessing the raid?

I have yet to notice an obviously direct correlation between when the server tech fixes something and when we get crashes, but I'll definetely look more carefully next weekend. And maybe I'll try and force a crash that way and see if that sheds some more light on the situation?

Once again, thank you very much for taking the time to reply! Appreciate it!