Blackmagic Forum

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

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.

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

Mail@robertschepers.com

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

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

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

??

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).

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.

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 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.

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.

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.

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

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

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

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

Hello ?? Looo?? Loo??


Feel like I'm talking in an echo pit

Downloading the clip now...

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 )

The file came down as audio only for me.

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

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.

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.

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.

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.

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.

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.

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

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

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?

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

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?

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.

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.

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.

schepers wrote:Which file?

A027_03071154_C010.mov

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

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
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.

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
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

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

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

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.

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

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

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.

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

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
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 ?

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.

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

Noerde wrote:

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

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

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.

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
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.

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.