Cintel sudden slow down and crash in Resolve

Greetings,

I've been running a BM Cintel scanner for years, and have recently been having issues where it will slow down a scan rate, first to 18fps, then 14fps/13fps > 9fps > sometimes 2-3fps and will then crash Resolve completely. This is running 35mm - so using the full gamut of Resolve. I usually run at 18fps and can happily sail through a couple of 2,000' reels, then this will happen continually. Rebooting Resolve will get scanner running for maybe 4-5minutes but same crash again. Shutting down the whole system will also get scanner up again, but it will end up crashing after 10min. I think it's a problem in Resolve not Cintel. I've got plenty of grunt with 2 x 8GB GPU (AMD RX Vega 64 + onboard AMD 580X). I checked on Activity Monitor and the GPUs are only at 8%/21% load during scan - which doesn't seem right. The CPU is higher. Activity Monitor says max bandwidth of GPUs is 15.75GB/sec. I've tried changing Resolve prefs around so only one or other GPU is used (instead of auto which selects both with the 580X for main displays) - no change. Have tried with auto choice options on and off - same. Plenty of space on the RAID drive it's capturing to. Am I missing anything?

Look I'll probably boot up in the morning and it'll be fine, but it's pretty frustrating when it happens, and capturing large reels in small amounts is not ideal.

Thanks for any advice.

Ray

[Peter Chamberlain]

Check system drive for available space?
And try disabling the 580 completely, have monitors into the Vega.

Next step is crash logs, as per FAQ details.

Thanks Peter, response much appreciated.
System is on a 500GB SSD, with around 50GB free space.
When I had this happen again - scan rate suddenly dropping - I stopped the scan, saved, then used Clean my mac to clear the system. It ran well after that for half hour. So possibly something between Resolve and OS X system not clearing cache or system files quickly enough?
I'll run without the 580 and report back if still issues with crash logs.
Thanks!

Ray

Further update. I selected only the Vega 64 for GPU in Resolve prefs, however the "Main Display GPU" tag was showing next to the 580 GPU (not the Vega 64) even though it was unchecked. Both GPUs are identified as 'discreet'. After 14mins scan time it dropped from 18fps to 13fps, then crashed soon after. I didn't create a diagnostic log immediately after this - I did just now but it's recent. I do see a ResolveDebug txt file in LogArchive folder that corresponds with the time of crash which I will attach.

Another issue possibly related - immediately after finishing scan I started Sc Detect Cuts in Timeline from the scan file - within a minute the Mac Pro fans revved up to full and Resolve appears frozen (eventually SBOD), as is Activity Monitor and actions in the Finder. This is the first time I've used Sc Detect Cuts (I usually do this from Media folder which was working fine yesterday) and it's the first time the Mac Pro has ever behaved like this (not even a year old). Force Quit did not work, and Finder completely unresponsive. Eventually had to force quit the MP. The fans rev up and freeze now happens in both Sc Cut detect modes.

The two attached txt crash log files are: ResolveDebug_C2.txt (after the Cintel crash) and ResolveDebug_1.txt after the Sc Detect Cuts freeze. (NOTE would not let me attach a txt file, and when I tried to attach the .zip folder, it returned this page to empty and did not attach - not sure how to fix that!).

Many thanks!!

Ray

Try upload txt files compressed to .zip
The two attached txt crash log files are: ResolveDebug_C2.txt (after the Cintel crash) and ResolveDebug_1.txt after the Sc Detect Cuts freeze.

Many thanks!!

Ray

[James Little]

Hi Ray,

you might like to try the SDK example 'CaptureImage'. You can do GPU free captures. Mac Pros share the PCIe bus between Thunderbolt and GPU, so you might be getting bottlenecking issues.

Regards

Hi James,

Thanks for that suggestion, I've downloaded the Decklink SDK 12.0 folder - I'll check re what needs to be installed - let me know if any specific instructions for using with the Mac Pro and the Cintel? I couldn't find the example for CaptureImage but will dig into the folders a bit more. I've got some 35mm materials coming in over the next few weeks so can trial with them.

All the best,

Ray

[Gavin Lucas]

Hi Ray,

Your problem is disk / network write access speed, we have a dynamic scanning feature, whereby the Scanner transport speed will step down, if it detects write speed issues.

It will step down incrementally to the minimum for the capture mode (6fps with Audio), and if unable to write OK at the slowest speed, will bail out and pop a splash screen up in Resolve advising user, to negate missing frames etc..
RESOLVE should not crash under these circumstances, unless your network traffic is causing secondary issues.

Manual Page 38
"Once scanning, if DaVinci Resolve detects that your storage bandwidth is too low to capture at the selected speed, the scan speed will automatically adjust to ensure the capture is successful. If you are using the optional Audio and KeyKode Reader accessory, the audio sample rate will also be adjusted to maintain your chosen audio quality."

To Reset -
***Fix storage speed issue...***
Re-queue event.
Reset transport speed
Re-capture event.

[James Little]

Hi Ray,

Cintel has it's own SDK. Please look there. It's very useful and can provide all the same quality and functionality as Resolve.

Cheers

Thanks Gavin, James,

Responses much appreciated! Thanks re the Cintel SDK - I've downloaded that - I might need some advice on using it (presume it's used outside of Resolve? Through the Cintel app?) but the CaptureImage setup sounds like it's worth a try.

I'm usually scanning negs only and no sound, so I'll check and see if there's any auto settings around Audio or KeyReader that might've kicked in after the update from DR 16 to 17. Otherwise there should be no write access speed issues in the system - CPU and GPU is high spec and there weren't these issues in earlier 35mm scans. Other culprits could be the TB 2 interface between scanner and RAID drive? The RAID hdd drives themselves? I ran a BM speed test and the raids are doing around 550/500MBs read/write, which has been adequate in the past.

Thanks,

Ray