I’m using Topaz 1.2.0. I’ve observed an error – I don’t know when it started, but I know that it wasn’t present in multiple earlier versions (2.x and 3.x for certain).
Repro:
1). Output image files (8-bit PNG in my case, though I don’t know if that matters)
2). Run out of storage
Expected Behavior: Upscale fails with an error message. Completed images (0000.png –> XXXXX.png) are left unchanged. Upscale can be restarted at the frame it failed on once more drive space is available.
Actual Behavior: All output images deleted. System claims that this error can be recovered, but clicking “Recover error” only produces another error. The files are not in the Recycle Bin; they are gone and the drive space has been preemptively reclaimed.
It is not always possible to predict how much capacity one will need, especially with long video. In previous versions of Topaz, running out of storage space presented no intrinsic problem. Here, it cost me 16 hours on a project. And since I still don’t know how much storage is required – I didn’t see the render fail – I have to blindly delete and hope I hit the target right this time.
I do not know if this is a bug or intentional behavior, but please revert to the earlier method of handling an out-of-disk error. I understand that any video file will fail to render when it runs out of drive space, but there is no reason image output should be treated the same way. The quality of 542321.png is not altered if 542322.png fails to write.
Joel, can you send the logs to the support team, so we can get them to devs for review into why the behavior happened this way? help@topazlabs.com
To gather logs, please select Help > Logging > Get Logs for Support and attach the zip file to your reply.
Here is a video to help with the steps of how to collect the logs.
Update, just got your support ticket, I will still need the logs to look into this.
Absolutely, and thank you for looking into it.
I ran the workload twice – once v. early in the morning on March 9 and then again some hours later when I realized it had failed. I didn’t actually realize it was a disk storage issue that had caused the problem – I should’ve – but the fact that I had ~1.2TB of SSD space left when I checked in the morning led me to think that a different problem had hamstrung the app. I’d left a lot of tasks running simultaneously – Topaz was just one – so that didn’t seem impossible.
I rebooted in-between the early AM workload failure and the more recent failure this afternoon. Whatever caused the problem, it happened again after after reset, when TVAI was the only GPU-using application running.
While I didn’t see where the render quit, I did check and confirm that it was writing images to disk before I left it alone to do its work. At the time, TVAI had rendered a few thousand frames and everything was normal. I looked at several images just to check the progress.
If it turns out that this is a weird bug specific to my system, great! Well, great provided anyone can tell me how to fix it. 
logsForSupport.zip (3.5 MB)
