Serious bug, DR makes source footage corrupt

Get answers to your questions about color grading, editing and finishing with DaVinci Resolve.
  • Author
  • Message
Offline

schepers

  • Posts: 45
  • Joined: Thu Mar 07, 2019 8:42 am
  • Real Name: Robert Schepers

Serious bug, DR makes source footage corrupt

PostWed Jan 27, 2021 12:19 pm

Hi,

- I just had exported my finished Movie and uploaded it to Vimeo for my client.

- I did the final quality check there was 1 frame that was corrupt. I took a look, also in DaVinci this one frame is corrupt.

- I’ve checked my earlier exports and here the frame is not corrupt.

- I’ve checked the source footage, also corrupt.

- I’ve checked the backup footage, everything is OK.

- Replaced the source with the backup file. Everything is OK.

What the hell is going on here?
Working on the newest version Resolve, footage is BMPCC 6K BRAW
Hope to get an answer ASAP.

BR,
Robert
Offline

Jim Simon

  • Posts: 16443
  • Joined: Fri Dec 23, 2016 1:47 am

Re: Serious bug, DR makes source footage corrupt

PostWed Jan 27, 2021 2:07 pm

As a general rule, terms like "latest", "current", "newest", etc. are meaningless

It's best to list out the specific version number when asking for help.
Offline

schepers

  • Posts: 45
  • Joined: Thu Mar 07, 2019 8:42 am
  • Real Name: Robert Schepers

Re: Serious bug, DR makes source footage corrupt

PostThu Jan 28, 2021 9:40 am

You can contact me directly about this if you want to fix this problem. I’m not asking for help.

Mail@robertschepers.com
Offline

Jim Simon

  • Posts: 16443
  • Joined: Fri Dec 23, 2016 1:47 am

Re: Serious bug, DR makes source footage corrupt

PostThu Jan 28, 2021 3:49 pm

Well, your conclusion is very likely in error, so...'help' was kind of implied.
Offline

schepers

  • Posts: 45
  • Joined: Thu Mar 07, 2019 8:42 am
  • Real Name: Robert Schepers

Re: Serious bug, DR makes source footage corrupt

PostMon Feb 22, 2021 5:45 pm

Again the same problem in a file. See attachment

System specs:

OSX: MacOS Cataluna / 10.15.6
iMac (Retina 5K, 27-inch, 2019)
3,6 GHz 8-Core Intel Core i9
72 GB 2667 MHz DDR4
Radeon Pro Vega 48 8 GB


Davinci version:
17.0B BUILD 7
Attachments
Schermafbeelding 2021-02-22 om 18.43.22.png
Schermafbeelding 2021-02-22 om 18.43.22.png (259.11 KiB) Viewed 1683 times
Offline

schepers

  • Posts: 45
  • Joined: Thu Mar 07, 2019 8:42 am
  • Real Name: Robert Schepers

Re: Serious bug, DR makes source footage corrupt

PostMon Feb 22, 2021 5:45 pm

Jim Simon wrote:Well, your conclusion is very likely in error, so...'help' was kind of implied.

??
Offline

Uli Plank

  • Posts: 10161
  • Joined: Fri Feb 08, 2013 2:48 am
  • Location: Germany and Indonesia

Re: Serious bug, DR makes source footage corrupt

PostTue Feb 23, 2021 2:33 am

I have never ever experienced Resolve damaging a source file (sometimes it's own database, yes).
BUT copying from your camera media with the Finder (or Explorer for Windows) is not 100% safe!
Better use the clone tool in DR or a professional tool like Shotput Pro. These are slower, but much safer.

Generally, if something like this happens:
Does it always happen on the same frame? That might be a hidden source glitch.
Or on different frames? Then it might be a GPU problem. Since drivers are updated automatically (I suppose you are using Catalina), it could be a hardware problem. An iMac can get very hot when rendering, and that can provoke such problems.
Get TG Pro to watch the heat and try to throttle the rendering if it get's very hot (Under Deliver -> File -> Render Speed).
Don't approach Resolve with your expectations from other NLEs! They are all different.
Resolve Studio 17.2 and Fusion Studio 17, macOS 10.15.7
iMac 2017 Radeon Pro 580 8 GB VRAM, 32 GB RAM
2018 Mac mini 16 GB RAM, eGFX Breakway RX 580 MacOS 10.15.7
Offline

schepers

  • Posts: 45
  • Joined: Thu Mar 07, 2019 8:42 am
  • Real Name: Robert Schepers

Re: Serious bug, DR makes source footage corrupt

PostTue Feb 23, 2021 8:18 am

Uli Plank wrote:I have never ever experienced Resolve damaging a source file (sometimes it's own database, yes).
BUT copying from your camera media with the Finder (or Explorer for Windows) is not 100% safe!
Better use the clone tool in DR or a professional tool like Shotput Pro. These are slower, but much safer.

Generally, if something like this happens:
Does it always happen on the same frame? That might be a hidden source glitch.
Or on different frames? Then it might be a GPU problem. Since drivers are updated automatically (I suppose you are using Catalina), it could be a hardware problem. An iMac can get very hot when rendering, and that can provoke such problems.
Get TG Pro to watch the heat and try to throttle the rendering if it get's very hot (Under Deliver -> File -> Render Speed).


Thanks, I will try TG Pro. I use Shotput Pro to copy, so that isn't the problem. In the DaVinci Resolve manual they also recommend this iMac setup. So they can't blame me that this is a hardware problem.

Also it is not when export a version. It destroys the source footage. When I copy my backup file to the working folder and reboot Resolve the glitches are gone. So the glitch is baked in the source file.

To give an answer if it is on the same frame. No, the glitches are at random frames. Had 3 glitches in a 2 minute clip.
Offline

Uli Plank

  • Posts: 10161
  • Joined: Fri Feb 08, 2013 2:48 am
  • Location: Germany and Indonesia

Re: Serious bug, DR makes source footage corrupt

PostTue Feb 23, 2021 8:25 am

Can you post one of those clips for download to test?

BTW, BM is neither telling you that the "Trashcan" Mac Pro is having massive thermal problems with its GPUs.
Don't approach Resolve with your expectations from other NLEs! They are all different.
Resolve Studio 17.2 and Fusion Studio 17, macOS 10.15.7
iMac 2017 Radeon Pro 580 8 GB VRAM, 32 GB RAM
2018 Mac mini 16 GB RAM, eGFX Breakway RX 580 MacOS 10.15.7
Offline

Italo Grossi

  • Posts: 29
  • Joined: Sun Feb 14, 2021 8:10 pm
  • Real Name: Italo Grossi

Re: Serious bug, DR makes source footage corrupt

PostTue Feb 23, 2021 9:01 am

I don't have a solution but just sharing my experience.
From the hundreds of projects edited so far never had any correuption in the source file.
I have had issues where the exported project had some corrupted frames.
DRS 17.0
Speed Editor
Atem Mini Pro ISO | Software 8.6

iMac 21,5' (late 2012) macOS Catalina 10.15.7
3,1 Ghz QuadCore i7
NVIDIA GeForce 650M 512 Mb
16GB

MacBook Air 13' (mid 2013) macOS Big Sur 11.2.1
1,3Ghz DualCore i5
Intel HD Graphics 5000 1536MB
4GB
Offline

Peter Chamberlain

Blackmagic Design

  • Posts: 10010
  • Joined: Wed Aug 22, 2012 7:08 am

Re: Serious bug, DR makes source footage corrupt

PostTue Feb 23, 2021 9:49 am

I'm not familiar with any process in Resolve that modifies the source, with one exception on older versions of the software.

this looks like a GPU processing error in a render. I'm assuming you are not overwriting the source clip.
DaVinci Resolve Product Manager
Offline

schepers

  • Posts: 45
  • Joined: Thu Mar 07, 2019 8:42 am
  • Real Name: Robert Schepers

Re: Serious bug, DR makes source footage corrupt

PostTue Feb 23, 2021 10:01 am

Peter Chamberlain wrote:I'm not familiar with any process in Resolve that modifies the source, with one exception on older versions of the software.

this looks like a GPU processing error in a render. I'm assuming you are not overwriting the source clip.


No, I am not rewriting the source clip.
Offline

schepers

  • Posts: 45
  • Joined: Thu Mar 07, 2019 8:42 am
  • Real Name: Robert Schepers

Re: Serious bug, DR makes source footage corrupt

PostTue Feb 23, 2021 10:05 am

Uli Plank wrote:Can you post one of those clips for download to test?

BTW, BM is neither telling you that the "Trashcan" Mac Pro is having massive thermal problems with its GPUs.


I've deleted this corrupt clip. When I have this problem again I will post the source file.

BR,
Robert
Offline

schepers

  • Posts: 45
  • Joined: Thu Mar 07, 2019 8:42 am
  • Real Name: Robert Schepers

Re: Serious bug, DR makes source footage corrupt

PostWed Mar 03, 2021 5:45 pm

Again the same problem. Blackmagic can you help me?

See attachment.

Here is the link to the source file:
timecode 13:25:20:13

https://drive.google.com/file/d/1GkhjzC ... sp=sharing
Attachments
Schermafbeelding 2021-03-03 om 18.42.29.jpg
Schermafbeelding 2021-03-03 om 18.42.29.jpg (375.44 KiB) Viewed 1491 times
Offline

schepers

  • Posts: 45
  • Joined: Thu Mar 07, 2019 8:42 am
  • Real Name: Robert Schepers

Re: Serious bug, DR makes source footage corrupt

PostMon Mar 08, 2021 2:32 pm

I don't get any response. Also no response on mail contact.

@Blackmagic, can you please help me????
Offline

schepers

  • Posts: 45
  • Joined: Thu Mar 07, 2019 8:42 am
  • Real Name: Robert Schepers

Re: Serious bug, DR makes source footage corrupt

PostMon Mar 15, 2021 8:30 am

Hello ?? Looo?? Loo??


Feel like I'm talking in an echo pit
Offline

Jim Simon

  • Posts: 16443
  • Joined: Fri Dec 23, 2016 1:47 am

Re: Serious bug, DR makes source footage corrupt

PostMon Mar 15, 2021 4:32 pm

Downloading the clip now...
Offline

Mads Johansen

  • Posts: 217
  • Joined: Mon Dec 19, 2016 10:51 am

Re: Serious bug, DR makes source footage corrupt

PostMon Mar 15, 2021 6:05 pm

On windows 10, Version 17.1 studio I get the same blue spot.

Are you 100% sure the file on the camera is exactly the same as the one on your drive? SHA hash etc? (to compare, I get SHA1: 958e8628a907e3175a8bb46515fb669c46bd748b )
Last edited by Mads Johansen on Mon Mar 15, 2021 6:09 pm, edited 1 time in total.
Davinci Resolve 17.2 Build11, Windows 10, Nvidia 1060 6GB
Offline

Jim Simon

  • Posts: 16443
  • Joined: Fri Dec 23, 2016 1:47 am

Re: Serious bug, DR makes source footage corrupt

PostMon Mar 15, 2021 6:07 pm

The file came down as audio only for me.

Given the name of the file, is this the original file from the camera?
Offline

Andrew Kolakowski

  • Posts: 7391
  • Joined: Tue Sep 11, 2012 10:20 am
  • Location: Poland

Re: Serious bug, DR makes source footage corrupt

PostMon Mar 15, 2021 7:27 pm

schepers wrote:Again the same problem in a file. See attachment

System specs:

OSX: MacOS Cataluna / 10.15.6
iMac (Retina 5K, 27-inch, 2019)
3,6 GHz 8-Core Intel Core i9
72 GB 2667 MHz DDR4
Radeon Pro Vega 48 8 GB


Davinci version:
17.0B BUILD 7


Resolve itself can't break any source as it never writes back to files which it reads.
It can be a bug in Resolve processing engine, but due to actual nature of the dropouts it's unlikely.
Those type of artefacts are typically disk, RAM or GPU related.
Either eg. driver problem, overheating or part simply dying.

If you said problem wasn't there, then it was, but archive is fine then it means your disk is corrupting files (maybe dying). Stop using it, replace all used masters with ones from archive and render again.
Last edited by Andrew Kolakowski on Mon Mar 15, 2021 7:51 pm, edited 1 time in total.
Offline

Andrew Kolakowski

  • Posts: 7391
  • Joined: Tue Sep 11, 2012 10:20 am
  • Location: Poland

Re: Serious bug, DR makes source footage corrupt

PostMon Mar 15, 2021 7:45 pm

In your sample file I see at last 3 issues not just the one which you mentioned. This source is most likely corrupted.

As suggested. You run MD5 or other checksum on your sources (archive and one used in Resolve) and compare them. They most likely will be different, so files are different. Then you need to rule out drive, so follow my earlier advice.
Offline

Uli Plank

  • Posts: 10161
  • Joined: Fri Feb 08, 2013 2:48 am
  • Location: Germany and Indonesia

Re: Serious bug, DR makes source footage corrupt

PostTue Mar 16, 2021 2:40 am

You need to rule out RAM too. I've seen such errors in BRAW footage once, and it was a faulty RAM in that machine.
After all, even when copying from camera media to your computer, it sits in RAM temporarily.
Don't approach Resolve with your expectations from other NLEs! They are all different.
Resolve Studio 17.2 and Fusion Studio 17, macOS 10.15.7
iMac 2017 Radeon Pro 580 8 GB VRAM, 32 GB RAM
2018 Mac mini 16 GB RAM, eGFX Breakway RX 580 MacOS 10.15.7
Offline

schepers

  • Posts: 45
  • Joined: Thu Mar 07, 2019 8:42 am
  • Real Name: Robert Schepers

Re: Serious bug, DR makes source footage corrupt

PostTue Mar 16, 2021 8:01 am

Mads Johansen wrote:On windows 10, Version 17.1 studio I get the same blue spot.

Are you 100% sure the file on the camera is exactly the same as the one on your drive? SHA hash etc? (to compare, I get SHA1: 958e8628a907e3175a8bb46515fb669c46bd748b )


Yes it is exactly the same filename and file. I added "corrupt" at the end of the file name, maybe that's why you see a difference.

Jim Simon wrote:The file came down as audio only for me.

Given the name of the file, is this the original file from the camera?


Yes, it is the original file from the camera. I added "corrupt" in the filename.

Andrew Kolakowski wrote:
schepers wrote:Again the same problem in a file. See attachment

System specs:

OSX: MacOS Cataluna / 10.15.6
iMac (Retina 5K, 27-inch, 2019)
3,6 GHz 8-Core Intel Core i9
72 GB 2667 MHz DDR4
Radeon Pro Vega 48 8 GB


Davinci version:
17.0B BUILD 7


Resolve itself can't break any source as it never writes back to files which it reads.
It can be a bug in Resolve processing engine, but due to actual nature of the dropouts it's unlikely.
Those type of artefacts are typically disk, RAM or GPU related.
Either eg. driver problem, overheating or part simply dying.

If you said problem wasn't there, then it was, but archive is fine then it means your disk is corrupting files (maybe dying). Stop using it, replace all used masters with ones from archive and render again.


My system is one year old now, and it was the fullest spec iMac at this time. My system disk is the Apple built in original SSD drive. My working drive is a G-Speed G-raid 20TB thunderbolt.

____


Also, I never had any problems before the Resolve 17 version.
Offline

Andrew Kolakowski

  • Posts: 7391
  • Joined: Tue Sep 11, 2012 10:20 am
  • Location: Poland

Re: Serious bug, DR makes source footage corrupt

PostTue Mar 16, 2021 8:30 am

It can be 1 day old. When it comes to random failures it doesn’t matter.
Whatever disk you are using for storing assets which are used in Resolve try with fresh masters copied on some different one.

If it’s external drive you have another corruption point which is your connection between machine and drive. Have you updated OSX recently?

You can waste weeks fighting with it. You have to start from easy to test bits like drive, connection etc.

If you had errors during exports then it could be Resolve.
If you say source gets corrupted as well it’s unlikely to be Resolve.
Try coping fresh files and locking them for write. Then Resolve has 0 chance to corrupt them.
Try copying fresh file and playing it in BRAW player and then checking if file is corrupted. Then you will know it’s not Resolve.

BM won’t help you as it’s not their problem and they hold no liability even if it was Resolve corrupting files ( which is about impossible).

Not sure if you use this forum a lot but there was never a case like this. Any corruption case was always down to host machine issue.
Offline

Jim Simon

  • Posts: 16443
  • Joined: Fri Dec 23, 2016 1:47 am

Re: Serious bug, DR makes source footage corrupt

PostTue Mar 16, 2021 6:10 pm

schepers wrote:Yes, it is the original file from the camera. I added "corrupt" in the filename.
OK.

Don't know why the image is missing then.
Offline

schepers

  • Posts: 45
  • Joined: Thu Mar 07, 2019 8:42 am
  • Real Name: Robert Schepers

Re: Serious bug, DR makes source footage corrupt

PostMon Mar 29, 2021 11:41 am

When editing I had two times glitches in different files. They come randomly when editing. I don't have made any export.

Here is a link where you can download the corrupted source file, also with all log information.

https://drive.google.com/drive/folders/ ... sp=sharing

BR,
Robert
Offline

Jim Simon

  • Posts: 16443
  • Joined: Fri Dec 23, 2016 1:47 am

Re: Serious bug, DR makes source footage corrupt

PostMon Mar 29, 2021 4:32 pm

Once again that clip is coming down for me as audio only. Both Resolve and PotPlayer report no video in that file.
Offline

schepers

  • Posts: 45
  • Joined: Thu Mar 07, 2019 8:42 am
  • Real Name: Robert Schepers

Re: Serious bug, DR makes source footage corrupt

PostMon Mar 29, 2021 5:16 pm

Jim Simon wrote:Once again that clip is coming down for me as audio only. Both Resolve and PotPlayer report no video in that file.

Then you are doing something wrong. Which file?
Offline

Tom Early

  • Posts: 1978
  • Joined: Wed Jul 17, 2013 11:01 am

Re: Serious bug, DR makes source footage corrupt

PostMon Mar 29, 2021 5:54 pm

I can get video and audio just fine. As for the glitches, it's not going to be Resolve doing this.
MBP2016, MacOS 11.2.3, 2.9 GHz Intel Core i7, 16 GB 2133 MHz LPDDR3,
Radeon Pro 460 4096 MB, Resolve Studio 16.2.8/17.1.1
Output: UltraStudio 4K Mini, Desktop Video 12.0
2nd GUI: 1920x1080, mostly using Dual Screen mode, Full Screen Timeline turned ON
Offline

schepers

  • Posts: 45
  • Joined: Thu Mar 07, 2019 8:42 am
  • Real Name: Robert Schepers

Re: Serious bug, DR makes source footage corrupt

PostMon Mar 29, 2021 6:28 pm

Tom Early wrote:I can get video and audio just fine. As for the glitches, it's not going to be Resolve doing this.


Thanks for the reaction Tom. So what could be the problem then?
Offline

Mads Johansen

  • Posts: 217
  • Joined: Mon Dec 19, 2016 10:51 am

Re: Serious bug, DR makes source footage corrupt

PostMon Mar 29, 2021 8:20 pm

schepers wrote:
Tom Early wrote:I can get video and audio just fine. As for the glitches, it's not going to be Resolve doing this.


Thanks for the reaction Tom. So what could be the problem then?

I suspect a hardware error. All the samples you have shared come from the same camera (8fb12e44c-e565-4a7c-a859-580431334e5c) and SD/CFast card, right?
Step 0: Update firmware. I noticed you ran firmware 6.9.6, while 7.2.1 is out: https://www.blackmagicdesign.com/suppor ... c%20OS%20X OR https://www.blackmagicdesign.com/suppor ... 5f/Windows

So step 1 is to change hardware:
Step 1.1: The SD/CFast card, to rule out cards.
1.2: Then change to a different camera with same cards, to rule out camera
1.3: new camera with new cards, to rule out that specific combination

It's super annoying with these intermittent errors, as they are difficult to pin down.
Davinci Resolve 17.2 Build11, Windows 10, Nvidia 1060 6GB
Offline

Andrew Kolakowski

  • Posts: 7391
  • Joined: Tue Sep 11, 2012 10:20 am
  • Location: Poland

Re: Serious bug, DR makes source footage corrupt

PostMon Mar 29, 2021 8:52 pm

Robert claims that problem is not on the original source.
Problem happens when he starts working in Resolve (then it's a copy of the source stored on some other drive).
He claims problem is not there and later appears. He thinks it's Resolve corrupting it which is about impossible. It's his drive corrupting files in my opinion.
Offline

Jeff Brass

  • Posts: 431
  • Joined: Wed Nov 26, 2014 7:46 am

Re: Serious bug, DR makes source footage corrupt

PostMon Mar 29, 2021 11:06 pm

Andrew Kolakowski wrote:Robert claims that problem is not on the original source.
Problem happens when he starts working in Resolve (then it's a copy of the source stored on some other drive).
He claims problem is not there and later appears. He thinks it's Resolve corrupting it which is about impossible. It's his drive corrupting files in my opinion.


I agree that is sounds like a HDD/SSD problem. If the corruption appears later on , after the files is copied from camera card to computer drive, then it kinda points to a hardware fault.
Win10 Pro x64 | i7 5930k|64GB RAM |GTX 1080 8gb | Mini Monitor | DR Studio 16.2
Offline

Jim Simon

  • Posts: 16443
  • Joined: Fri Dec 23, 2016 1:47 am

Re: Serious bug, DR makes source footage corrupt

PostMon Mar 29, 2021 11:08 pm

schepers wrote:Which file?

A027_03071154_C010.mov
Offline

Mads Johansen

  • Posts: 217
  • Joined: Mon Dec 19, 2016 10:51 am

Re: Serious bug, DR makes source footage corrupt

PostTue Mar 30, 2021 7:36 am

Let's for a moment assume Robert is correct. How do we prove Resolve is changing the file?
Definitions: A hash: https://en.wikipedia.org/wiki/Cryptogra ... h_function

Step 1: Make a hash of the file on the source drive (in the camera if possible). That is our benchmark, eg we know that the file is perfect.
Step 2: Make a hash on the drive before resolve has opened the file (To test that its not the transfer that causes problems)
Step 3: Make a hash after resolve has opened the file (To test that it's resolve that has changed the file)

IF step 3 gives a different hash then Resolve changed the file.
IF step 1,2 and 3 gives the same hash, then resolve did NOT change the file. This means that the corruption is in the camera or card.

Here are the hashes from the files I downloaded from google drive with the corruption inside. If you get different values (UPPER versus lower case doesn't matter), then we have a transfer problem.
A027_03071154_C010.braw: SHA1: f7e9e82251c36a2e8448a32b4582b749faa4e030
A027_03071631_C077.braw: SHA1: 20598f497d98442e4fa10454c526311768cf512c
Davinci Resolve 17.2 Build11, Windows 10, Nvidia 1060 6GB
Offline

Andrew Kolakowski

  • Posts: 7391
  • Joined: Tue Sep 11, 2012 10:20 am
  • Location: Poland

Re: Serious bug, DR makes source footage corrupt

PostTue Mar 30, 2021 9:05 am

Problem is that if this is your drive failing then you may think it's Resolve corrupting it (and if you work on file in Resolve which forces drive to do activity then it will happen ), not drive :D
Solution (and proof) is crazy simple- use different drive and finish project this way!

And as pointed - checksums is good "measure" of corruption. Corruption can happen at any point, although today even internet is quite reliable. If you use good tools and hosts then it's about as reliable as local disks these days.

Besides- author of the post is not writing anymore, so case closed.
Offline

schepers

  • Posts: 45
  • Joined: Thu Mar 07, 2019 8:42 am
  • Real Name: Robert Schepers

Re: Serious bug, DR makes source footage corrupt

PostTue Mar 30, 2021 10:55 am

Andrew Kolakowski wrote:Problem is that if this is your drive failing then you may think it's Resolve corrupting it (and if you work on file in Resolve which forces drive to do activity then it will happen ), not drive :D
Solution (and proof) is crazy simple- use different drive and finish project this way!

And as pointed - checksums is good "measure" of corruption. Corruption can happen at any point, although today even internet is quite reliable. If you use good tools and hosts then it's about as reliable as local disks these days.

Besides- author of the post is not writing anymore, so case closed.


Why you say that I don't writing anymore and case closed? Please take those words back. I constantly communicate trough the forum and have direct contact with Blackmagic over e-mail.

I also send opened a support ticket at the disk factory. I hope to hear back from them soon.

It could be the disk, but I don't have any other problems with the disk. No crashes at all. The disk is a professional grade G-Raid Thunderbolt 3 20 TB and is about two years old now. Also not heavy used.

Please be nice and don't judge people.

BR, Robert
Offline

schepers

  • Posts: 45
  • Joined: Thu Mar 07, 2019 8:42 am
  • Real Name: Robert Schepers

Re: Serious bug, DR makes source footage corrupt

PostTue Mar 30, 2021 11:02 am

Mads Johansen wrote:Let's for a moment assume Robert is correct. How do we prove Resolve is changing the file?
Definitions: A hash: https://en.wikipedia.org/wiki/Cryptogra ... h_function

Step 1: Make a hash of the file on the source drive (in the camera if possible). That is our benchmark, eg we know that the file is perfect.
Step 2: Make a hash on the drive before resolve has opened the file (To test that its not the transfer that causes problems)
Step 3: Make a hash after resolve has opened the file (To test that it's resolve that has changed the file)

IF step 3 gives a different hash then Resolve changed the file.
IF step 1,2 and 3 gives the same hash, then resolve did NOT change the file. This means that the corruption is in the camera or card.

Here are the hashes from the files I downloaded from google drive with the corruption inside. If you get different values (UPPER versus lower case doesn't matter), then we have a transfer problem.
A027_03071154_C010.braw: SHA1: f7e9e82251c36a2e8448a32b4582b749faa4e030
A027_03071631_C077.braw: SHA1: 20598f497d98442e4fa10454c526311768cf512c


Thanks for your reaction. I'm not very technical to do this kind of things. Do you need the same file that isn't corrupt?


BR, Robert
Offline

schepers

  • Posts: 45
  • Joined: Thu Mar 07, 2019 8:42 am
  • Real Name: Robert Schepers

Re: Serious bug, DR makes source footage corrupt

PostTue Mar 30, 2021 11:11 am

Jim Simon wrote:
schepers wrote:Which file?

A027_03071154_C010.mov

Please use this link:

https://drive.google.com/drive/folders/ ... sp=sharing

BR, Robert
Offline

Mads Johansen

  • Posts: 217
  • Joined: Mon Dec 19, 2016 10:51 am

Re: Serious bug, DR makes source footage corrupt

PostTue Mar 30, 2021 12:12 pm

schepers wrote:
Mads Johansen wrote:Let's for a moment assume Robert is correct. How do we prove Resolve is changing the file?
Definitions: A hash: https://en.wikipedia.org/wiki/Cryptogra ... h_function

Step 1: Make a hash of the file on the source drive (in the camera if possible). That is our benchmark, eg we know that the file is perfect.
Step 2: Make a hash on the drive before resolve has opened the file (To test that its not the transfer that causes problems)
Step 3: Make a hash after resolve has opened the file (To test that it's resolve that has changed the file)

IF step 3 gives a different hash then Resolve changed the file.
IF step 1,2 and 3 gives the same hash, then resolve did NOT change the file. This means that the corruption is in the camera or card.

Here are the hashes from the files I downloaded from google drive with the corruption inside. If you get different values (UPPER versus lower case doesn't matter), then we have a transfer problem.
A027_03071154_C010.braw: SHA1: f7e9e82251c36a2e8448a32b4582b749faa4e030
A027_03071631_C077.braw: SHA1: 20598f497d98442e4fa10454c526311768cf512c


Thanks for your reaction. I'm not very technical to do this kind of things. Do you need the same file that isn't corrupt?

BR, Robert


I do not need anything. I am telling you what steps you need to do to narrow down where the corruption happens.
If you are not comfortable doing those steps, I suggest finding someone with tech skills to do them.
Davinci Resolve 17.2 Build11, Windows 10, Nvidia 1060 6GB
Offline

Noerde

  • Posts: 2
  • Joined: Tue Mar 30, 2021 12:37 pm
  • Real Name: Panu Artimo

Re: Serious bug, DR makes source footage corrupt

PostTue Mar 30, 2021 12:43 pm



Have you verified the files are really identical on both the sd card and the drive you use, you can do it from the command line with:
Code: Select all
shasum -a 1 filename.mov
Offline

Jim Simon

  • Posts: 16443
  • Joined: Fri Dec 23, 2016 1:47 am

Re: Serious bug, DR makes source footage corrupt

PostTue Mar 30, 2021 2:13 pm

schepers wrote:Please use this link:
I did. Something is going wrong in the download process. This time I noticed that the file has the .braw extension, but Firefox insists on downloading it as an .mov file.

Curious.
Offline
User avatar

Mark Foster

  • Posts: 848
  • Joined: Tue Oct 27, 2015 10:59 am
  • Location: austria - no kangaroos +g*

Re: Serious bug, DR makes source footage corrupt

PostTue Mar 30, 2021 3:45 pm

ok, see the problem

look as write speed problem, or defective medium
do not use SD card for the 6k !
CFast2.0 card are very cheap now

recommended brand and type of cards:
https://www.blackmagicdesign.com/support/faq/59026

Screenshot 2021-03-30 at 17.28.03.jpg
Screenshot 2021-03-30 at 17.28.03.jpg (293.37 KiB) Viewed 805 times
cMP 5.1 2x3,46/96GB/2x2TB 860pro/4x4TB HGST/SSD7101A 4x2TB 970evoplus/HP1344/BMD4k/Radeon VII
macOS 11.2.3

BMPCC4k (7.3)+ MB speedbooster ultra 0.71 (3.60)
resolve 17.2
Offline

Andrew Kolakowski

  • Posts: 7391
  • Joined: Tue Sep 11, 2012 10:20 am
  • Location: Poland

Re: Serious bug, DR makes source footage corrupt

PostTue Mar 30, 2021 8:34 pm

schepers wrote:
Andrew Kolakowski wrote:Problem is that if this is your drive failing then you may think it's Resolve corrupting it (and if you work on file in Resolve which forces drive to do activity then it will happen ), not drive :D
Solution (and proof) is crazy simple- use different drive and finish project this way!

And as pointed - checksums is good "measure" of corruption. Corruption can happen at any point, although today even internet is quite reliable. If you use good tools and hosts then it's about as reliable as local disks these days.

Besides- author of the post is not writing anymore, so case closed.


Why you say that I don't writing anymore and case closed? Please take those words back. I constantly communicate trough the forum and have direct contact with Blackmagic over e-mail.

I also send opened a support ticket at the disk factory. I hope to hear back from them soon.

It could be the disk, but I don't have any other problems with the disk. No crashes at all. The disk is a professional grade G-Raid Thunderbolt 3 20 TB and is about two years old now. Also not heavy used.

Please be nice and don't judge people.

BR, Robert


You didn't for long time so I assumed case closed.

Class of the drive is irrelevant here. Any drive can fail at ANY moment, so fact it's new, not used much etc. is about meaningless when it comes to those failures (failures in first few months of usage are probably more often than later unless drive is very old). I'm looking after storage around 500TB. Had few drives dead over last few years, but in some boxes none. It's a total lottery.

Have you tried copying original source to new drive and exporting project from there?

Have you tried copying new file to your maybe faulty drive, then keep playing this file many times in eg. BRAW Player (so disk has activity) and then checking if corruption is there (so not touching Resolve)?

Have you tried simply locking file for write and then working in Resolve with it (if Resolve has no write access to the file it can't corrupt it)?

Your first file clearly had corruptions, actually more than your reported. You have to be methodological in this case.
Take source file, make 100% sure that it has no problems. Generate checksum for it. Any further copy etc needs that checksum to be verified straight after copy. Then play with file (so there is a lot disk activity) and verify checksum again. Do the same with Resolve. Verify. If problem is there after Resolve step then do the same with new drive. If Resolve causes corruption then it should happen again.
You have many points of failure -drive, TB3 connection, cable, etc.(or even OSX issue with particular TB3 device).
Without proper approach you will be just wasting your time. It's your choice :)

People keep pointing you to recording issues, without reading your description of the problem. According to you your main source is fine, so no idea why everyone suggest recording issue, causing unnecessary confusion ? :)
Last edited by Andrew Kolakowski on Tue Mar 30, 2021 8:46 pm, edited 2 times in total.
Offline

Andrew Kolakowski

  • Posts: 7391
  • Joined: Tue Sep 11, 2012 10:20 am
  • Location: Poland

Re: Serious bug, DR makes source footage corrupt

PostTue Mar 30, 2021 8:41 pm

schepers wrote:
Mads Johansen wrote:Let's for a moment assume Robert is correct. How do we prove Resolve is changing the file?
Definitions: A hash: https://en.wikipedia.org/wiki/Cryptogra ... h_function

Step 1: Make a hash of the file on the source drive (in the camera if possible). That is our benchmark, eg we know that the file is perfect.
Step 2: Make a hash on the drive before resolve has opened the file (To test that its not the transfer that causes problems)
Step 3: Make a hash after resolve has opened the file (To test that it's resolve that has changed the file)

IF step 3 gives a different hash then Resolve changed the file.
IF step 1,2 and 3 gives the same hash, then resolve did NOT change the file. This means that the corruption is in the camera or card.

Here are the hashes from the files I downloaded from google drive with the corruption inside. If you get different values (UPPER versus lower case doesn't matter), then we have a transfer problem.
A027_03071154_C010.braw: SHA1: f7e9e82251c36a2e8448a32b4582b749faa4e030
A027_03071631_C077.braw: SHA1: 20598f497d98442e4fa10454c526311768cf512c


Thanks for your reaction. I'm not very technical to do this kind of things. Do you need the same file that isn't corrupt?


BR, Robert



It's easy.
All what you need is app which generates checksum. First from google:
https://www.electronjs.org/apps/checksum-validator

then you just run it on main source, after any copy process or when file stays (best to play it) on disk for some time. If there is corruption then you will get different checksum value compared to the one for main source. No need to keep checking source with eye which is not 100% precise way.
Offline

schepers

  • Posts: 45
  • Joined: Thu Mar 07, 2019 8:42 am
  • Real Name: Robert Schepers

Re: Serious bug, DR makes source footage corrupt

PostWed Mar 31, 2021 5:41 pm

Mark Foster wrote:ok, see the problem

look as write speed problem, or defective medium
do not use SD card for the 6k !
CFast2.0 card are very cheap now

recommended brand and type of cards:
https://www.blackmagicdesign.com/support/faq/59026

Screenshot 2021-03-30 at 17.28.03.jpg


Thanks, I use C-fast from Angelbird
Offline

schepers

  • Posts: 45
  • Joined: Thu Mar 07, 2019 8:42 am
  • Real Name: Robert Schepers

Re: Serious bug, DR makes source footage corrupt

PostWed Mar 31, 2021 5:43 pm

Noerde wrote:


Have you verified the files are really identical on both the sd card and the drive you use, you can do it from the command line with:
Code: Select all
shasum -a 1 filename.mov


The recording in the camera is good. Also when copied to harddrive everything is OK. Also the backup on my google drive is OK. When editing, some files randomly get glitches. I will try this tip, Thanks
Last edited by schepers on Wed Mar 31, 2021 5:44 pm, edited 1 time in total.
Offline

schepers

  • Posts: 45
  • Joined: Thu Mar 07, 2019 8:42 am
  • Real Name: Robert Schepers

Re: Serious bug, DR makes source footage corrupt

PostWed Mar 31, 2021 5:43 pm

Andrew Kolakowski wrote:
schepers wrote:
Mads Johansen wrote:Let's for a moment assume Robert is correct. How do we prove Resolve is changing the file?
Definitions: A hash: https://en.wikipedia.org/wiki/Cryptogra ... h_function

Step 1: Make a hash of the file on the source drive (in the camera if possible). That is our benchmark, eg we know that the file is perfect.
Step 2: Make a hash on the drive before resolve has opened the file (To test that its not the transfer that causes problems)
Step 3: Make a hash after resolve has opened the file (To test that it's resolve that has changed the file)

IF step 3 gives a different hash then Resolve changed the file.
IF step 1,2 and 3 gives the same hash, then resolve did NOT change the file. This means that the corruption is in the camera or card.

Here are the hashes from the files I downloaded from google drive with the corruption inside. If you get different values (UPPER versus lower case doesn't matter), then we have a transfer problem.
A027_03071154_C010.braw: SHA1: f7e9e82251c36a2e8448a32b4582b749faa4e030
A027_03071631_C077.braw: SHA1: 20598f497d98442e4fa10454c526311768cf512c


Thanks for your reaction. I'm not very technical to do this kind of things. Do you need the same file that isn't corrupt?


BR, Robert



It's easy.
All what you need is app which generates checksum. First from google:
https://www.electronjs.org/apps/checksum-validator

then you just run it on main source, after any copy process or when file stays (best to play it) on disk for some time. If there is corruption then you will get different checksum value compared to the one for main source. No need to keep checking source with eye which is not 100% precise way.


Thanks for the tip, I will dive in to this. :D
Offline

schepers

  • Posts: 45
  • Joined: Thu Mar 07, 2019 8:42 am
  • Real Name: Robert Schepers

Re: Serious bug, DR makes source footage corrupt

PostWed Mar 31, 2021 5:47 pm

Andrew Kolakowski wrote:
schepers wrote:
Andrew Kolakowski wrote:Problem is that if this is your drive failing then you may think it's Resolve corrupting it (and if you work on file in Resolve which forces drive to do activity then it will happen ), not drive :D
Solution (and proof) is crazy simple- use different drive and finish project this way!

And as pointed - checksums is good "measure" of corruption. Corruption can happen at any point, although today even internet is quite reliable. If you use good tools and hosts then it's about as reliable as local disks these days.

Besides- author of the post is not writing anymore, so case closed.


Why you say that I don't writing anymore and case closed? Please take those words back. I constantly communicate trough the forum and have direct contact with Blackmagic over e-mail.

I also send opened a support ticket at the disk factory. I hope to hear back from them soon.

It could be the disk, but I don't have any other problems with the disk. No crashes at all. The disk is a professional grade G-Raid Thunderbolt 3 20 TB and is about two years old now. Also not heavy used.

Please be nice and don't judge people.

BR, Robert


You didn't for long time so I assumed case closed.

Class of the drive is irrelevant here. Any drive can fail at ANY moment, so fact it's new, not used much etc. is about meaningless when it comes to those failures (failures in first few months of usage are probably more often than later unless drive is very old). I'm looking after storage around 500TB. Had few drives dead over last few years, but in some boxes none. It's a total lottery.

Have you tried copying original source to new drive and exporting project from there?

Have you tried copying new file to your maybe faulty drive, then keep playing this file many times in eg. BRAW Player (so disk has activity) and then checking if corruption is there (so not touching Resolve)?

Have you tried simply locking file for write and then working in Resolve with it (if Resolve has no write access to the file it can't corrupt it)?

Your first file clearly had corruptions, actually more than your reported. You have to be methodological in this case.
Take source file, make 100% sure that it has no problems. Generate checksum for it. Any further copy etc needs that checksum to be verified straight after copy. Then play with file (so there is a lot disk activity) and verify checksum again. Do the same with Resolve. Verify. If problem is there after Resolve step then do the same with new drive. If Resolve causes corruption then it should happen again.
You have many points of failure -drive, TB3 connection, cable, etc.(or even OSX issue with particular TB3 device).
Without proper approach you will be just wasting your time. It's your choice :)

People keep pointing you to recording issues, without reading your description of the problem. According to you your main source is fine, so no idea why everyone suggest recording issue, causing unnecessary confusion ? :)


Thanks for the tips Andrew, I will take it a try. 8-)
Offline

schepers

  • Posts: 45
  • Joined: Thu Mar 07, 2019 8:42 am
  • Real Name: Robert Schepers

Re: Serious bug, DR makes source footage corrupt

PostWed Mar 31, 2021 5:49 pm

Mark Foster wrote:ok, see the problem

look as write speed problem, or defective medium
do not use SD card for the 6k !
CFast2.0 card are very cheap now

recommended brand and type of cards:
https://www.blackmagicdesign.com/support/faq/59026

Screenshot 2021-03-30 at 17.28.03.jpg


Dit you made this screenshot? The glitch is on another place than at my system. Thats strange.
Next

Return to DaVinci Resolve

Who is online

Users browsing this forum: Baidu [Spider], Google [Bot], Google Feedfetcher, Majestic-12 [Bot], wd60xxx, wireless112, Wouter Bouwens and 99 guests