Affinity Photo destroys file during saving process

[Rolbrecht]

Hello,

I am working on large files (40’000 px x 6’800 px, 5.8 GB) and during the safe process an error message is created and the file can’t be saved. Actually, the file is destroyed and not only the last working session is lost but all work of the days before!! And this happened now the third time!!

Details:

- Computer: CPU: R9 3900X,  RAM: 64 GB,   C:\: fast SSD 500 GB,  D:\: HDD 1 TB,  Graphic: RTX2060S
- AP: version 1.8.5.783
- File location on D:\
- Windows 10, 2004

During the save process AP writes first to D:\, then to C:\ and again to D:\. During the last write process something seems to go wrong. The error message "Failed to load ..." occurs.

After trying to load the file that is now on D:\, AP asks to open a recovery file, but fails to do so -> message 3.

Any advice? 

[LunaticS0UL]

Just spitballing: this could happen if you're using FAT, which has a maximum file size of 4gb. The file starts to save, but can only save the first 4gb, so the file gets chopped off at 4gb. Is it possible the file starts off under this limit, then grows after you make some edits? Otherwise Affinity shouldn't even let you save it to begin with... In my mind these symptoms point to a hard drive issue.

[Garden-User]

Hello,

Is is possible that you run out of Storage on your Working drive C? 

Another Option is maybe that the HDD is too slow and so Affinity Photo must wait to long. (Even when you have the File it will take at least 58 Seconds to Load the complete File from a HDD).

I have blown up our picture to 30.000 px x 20.000 and it is "only" 800 MB big... even our Largest file (2,5 GB PSB-File -> 900 MB Affinity Photo) is only going to 2,7 GB Filesize and this is with a lots of changes. This all works perfectly. But the Big File needed over 3 Minutes to Save and this is on an SSD. 

Maybe @LunaticS0UL is right and the HDD is Formated as FAT32 so the largest possible File can only be 4 GB and everything above will be destroyed. Because I assume that Affinity Photo can´t say how big the file will be, the file will be reported damaged if it trys to save. 

[Dan C]

Hi @Rolbrecht,

Sorry to hear you're having trouble!

On 11/7/2020 at 4:07 PM, Rolbrecht said:

During the save process AP writes first to D:\, then to C:\ and again to D:\.

This certainly isn't something I've heard of happening before, and would seem to be an indication of a system specific issue.

Can you please confirm the below, from the above 2 posts:

• Are you using FAT32 on your D:\ drive?
• How much free space is remaining, on both your D & C drives?
• What happens if you try to save to the C drive, rather than the D drive?

Many thanks in advance

[Rolbrecht]

5 hours ago, Dan C said:

Hi @Rolbrecht,

Sorry to hear you're having trouble!

This certainly isn't something I've heard of happening before, and would seem to be an indication of a system specific issue.

Can you please confirm the below, from the above 2 posts:

• Are you using FAT32 on your D:\ drive?
• How much free space is remaining, on both your D & C drives?
• What happens if you try to save to the C drive, rather than the D drive?

Many thanks in advance

Thanks for responding.

- I am using only NTFS (GPT) on all disks.
- Free space on C:\ is 320 GB. I also replaced D:\ with an SSD with 200 GB free space (both SSDs use NVMe protocoll).

When only using SSDs I experienced a freeze of AP during saving (I used "Save as..."). I had to kill it. However, the file was saved correctly.

I also reduced the number of Undo Limit to 30.

I have the suspicion it has something to do with the "Cycle Feature" of the history. So I try to avoid it, what is not easy.
Since then (today) the save process went through, meaning, I use only save as.

[Garden-User]

14 hours ago, Rolbrecht said:

When only using SSDs I experienced a freeze of AP during saving (I used "Save as..."). I had to kill it. However, the file was saved correctly.

Hello again,

This "Freeze" is normal. Since AP is not reporting back to Windows that it does something, Windows thinks it froze. You can check in the Task-Manager if there is CPU / SSD Activity from the AP Programm. This happens very often when any Programm works very hard (This happend to us in many Programs). 

But it is good to know, that the System now works fine. 

[fde101]

23 hours ago, Dan C said:

This certainly isn't something I've heard of happening before, and would seem to be an indication of a system specific issue.

Is it possible that there is enough memory pressure that the underlying OS is writing to the swap file on C:?

[Rolbrecht]

Now it happened again.

I did a Save as... The file was saved at least correctly but then AP partially froze. No activity on any drive anymore. After several minutes I closed AP and couldn't relaunched it again. I had to restart the PC. 

See the attached movie file that shows the partial freeze.

[AlainP]

Why does it seem than rendering is not over yet. Just a small square part in the middle looks OK, all the rest is still blurred like if rendering had not finished his job. Maybe you try to save while renderring is still going on. Or it could be the quality of the video file.

[Dan C]

21 hours ago, Rolbrecht said:

- I am using only NTFS (GPT) on all disks.
- Free space on C:\ is 320 GB. I also replaced D:\ with an SSD with 200 GB free space (both SSDs use NVMe protocoll). 

Thanks for confirming that

Am I correct in assuming these are internal drives, and not externally connected via USB or similar?

Is your D:/ drive a sync/backup drive, or is this setup as a 'regular' disk?

What happens if you try to save to the C drive, rather than the D drive?

12 minutes ago, AlainP said:

Why does it seem than rendering is not over yet. Just a small square part in the middle looks OK, all the rest is still blurred like if rendering had not finished his job

I agree, there certainly seems to be a rendering issue with the document, and this is very possibly tied to the saving issue.

What RAM usage is shown in Task Manager, both when panning/editing the document, and when trying to save it?

On 11/7/2020 at 4:07 PM, Rolbrecht said:

During the save process AP writes first to D:\, then to C:\ and again to D:\.

Is this what you've found being reported in Task Manager? I can't see any reference to this in your screenshots/videos, so I'd like to double check!

[Rolbrecht]

1 hour ago, Dan C said:

Thanks for confirming that

Am I correct in assuming these are internal drives, and not externally connected via USB or similar?

Is your D:/ drive a sync/backup drive, or is this setup as a 'regular' disk?

What happens if you try to save to the C drive, rather than the D drive?

I agree, there certainly seems to be a rendering issue with the document, and this is very possibly tied to the saving issue.

What RAM usage is shown in Task Manager, both when panning/editing the document, and when trying to save it?

Is this what you've found being reported in Task Manager? I can't see any reference to this in your screenshots/videos, so I'd like to double check!

@Alain:  During the save process my screen showed the sharp part of the image (zoomed in). After the save process (no data written on any disk) AP was partially frozen. However I could zoom out, revealing the blurred part of the picture. I don't see that there is a rendering issue.

@Dan: 
- All disk are internally. Actually, now I am using two SSDs (C:\ and V:\), both on the mainboard via M.2 slots.
- I moved the Panno_03.afphoto file from D:\ to V:\.  D:\ is idle.  (In that constellation the partial freeze occurred) I don't dare to use the Save command and just always use Save as..
- I didn't try to store the Panno_03.afphoto on C:\.  C:\ is reserved for programms only. Do you want me to try it anyway?

[Rolbrecht]

During testing certain AP behavior I found the following:

When editing the file Panno_03.afphoto for a certain time, AP stopps updating the Histogram or the Scopes or the Layer icons. A save will revive AP.

I added several layer to the picture and could save the file successfully. It gained a size of 11 GB.  After that I deleted the additional layers and did some Levels / Curves editing. 
Then I saved the file again and it was truncated (damaged, as I stated at the beginning). The attached video shows the process.
Interestingly, the HDD was accessed a short period of time as well. I don't understand that because the Panno_03.afphoto is only on V:\.

Directly after the Save I could do a Save as.. successfully.

[Slammer]

Is there any information in the Windows event viewer? Don´t think this is an affinity error per-se and did I read correctly Win10, 2004? There seems to be a whole list of bugs reported with this version, perhaps try a rollback. 

[Dan C]

@Rolbrecht, my sincerest apologies for the delayed response here, I just wanted to inform you that we're still investigating this issue and I hope to have more steps/guidance to provide shortly.

Many thanks for your continued patience and understanding here

[Rolbrecht]

On 11/10/2020 at 7:48 PM, Slammer said:

Is there any information in the Windows event viewer? Don´t think this is an affinity error per-se and did I read correctly Win10, 2004? There seems to be a whole list of bugs reported with this version, perhaps try a rollback. 

Yes, I have Win 10, 2004 and had no issues with it. When I work on lower file sizes I never experienced save problems. In the meantime I finished the job and using only Save as... So I could go back to a successfully saved version and not losing all work. Currently, I rather tend to installing Win 10 20H2 instead of a rollback.

My impression is, that the way AP creates and manages its history could cause the problem. Is there a possibility to switch the "History Cycle Feature" off? With large files >= 1.5 GB the update of the histogram or the layer icons stops relatively fast after several editings without saving in-between. And after that, saving may become critical.

Thanks for your caring.

[Dan C]

I have had a response from our internal teams regarding this - it's not overly surprising that this isn't affecting smaller documents as you wont be hitting RAM limits as often as you are doing within this document.

When using Save As on this document (I appreciate you have since noted you managed to finish the job), what average file size was being created?

Your C drive is likely being used for RAM overflow, when trying to save such a large document, Affinity will load the doc into RAM, however if this hits it's limit then it will begin writing temporary files to the same drive as the installed app, in this case the C drive.

For this reason, we do expect to see drive activity on drives that might not be being 'directly' used, especially when doing something RAM intensive, such as saving.

In any case however, using File > Save should always work and not either crash the app or produce a corrupted file.

Do you know what your RAM limit is set to in Affinity Photo > Preferences > Performance? 

Can you please open %appdata%\Affinity\Photo\1.0\temp and let me know if there are any files within this folder?

[Rolbrecht]

On 11/23/2020 at 5:39 PM, Dan C said:

I have had a response from our internal teams regarding this - it's not overly surprising that this isn't affecting smaller documents as you wont be hitting RAM limits as often as you are doing within this document.

When using Save As on this document (I appreciate you have since noted you managed to finish the job), what average file size was being created?

Your C drive is likely being used for RAM overflow, when trying to save such a large document, Affinity will load the doc into RAM, however if this hits it's limit then it will begin writing temporary files to the same drive as the installed app, in this case the C drive.

For this reason, we do expect to see drive activity on drives that might not be being 'directly' used, especially when doing something RAM intensive, such as saving.

In any case however, using File > Save should always work and not either crash the app or produce a corrupted file.

Do you know what your RAM limit is set to in Affinity Photo > Preferences > Performance? 

Can you please open %appdata%\Affinity\Photo\1.0\temp and let me know if there are any files within this folder?

I am sorry, for not responding earlier. I was heavily working on none-Affinity related topics and missed your questions. Now my answers.

- When using save as the file size varied between 3.2 GB and 5.8 GB. Depending on the number of levels kept.
- I relaunched the .aphoto file added a Stamp (ctrl+alt+shft+e) and saved it. At the beginning the file size was 5.2 GB. After the save it is 6.7 GB. Picture ..._05 showes the %appdata%\Affinity\Photo\1.0\temp folder.
- Picture ..._04 shows the RAM limit.

Hint: I experience little problems, when I open a large file, make little changes and save it. The problem seem to occur after a lot of editing work (creating, deleting, merging,... layers) before saving. The first indication is, that the icons of the layers remain black.