Temporary folder is never cleaned up

[makkura]

Describe the bug
The temporary and logs folder never get cleaned out, slowly consuming the drive where wav2bar is installed.

To Reproduce
Run a number of renders.
Check the temporary folder and logs folder.

Expected behavior
Temporary files are cleared after each render.
Oldest logs get removed if they grow too large.

Additional Info
My system showed over 100gb of usage in the wav2bar temp folder and 2.3 around logs.
A friend showed over 60gb of usage in the wav2bar temp folders.

Windows:

• temp folder is under the wav2bar folder in /tmp (eg: c:\wav2bar\tmp)
• log folder is under the wav2bar folder in /logs (eg: c:\wav2bar\logs)

Mac/OSX:
I ran the build commands to get wav2bar running:

• temp folder: ~/wav2bar/out/Wav2Bar-darwin-arm64/Wav2Bar.app/Contents/Resources/app/temp/
• logs folder: ~/wav2bar/out/Wav2Bar-darwin-arm64/Wav2Bar.app/Contents/Resources/app/logs

I cleaned out the temp/renders folder via: find . -delete (while prompt is in the renders folder)
I used find instead of rm due to an "argument list too long" error using rm.
I cleaned out the logs/ folder via: rm * (while prompt is in the logs folder)

[Picorims]

Thanks for the report.

Regarding the logs, it is intended behavior, though this could be a settings for sure (I never faced gigabytes of it, hence it didn't come to mind).

Regarding the render directory, it should clean up by itself either on shut down or start up of the app. Does the logs shows errors or warnings related to the temp directory?

It could also be that the code doesn't handle MacOS there, as I have no way to test and build on that platform...

Though I am aware of the insane memory usage, that's one of the reasons for a rewrite, to change the architecture to try to avoid such crazy numbers.

[makkura]

Some limited feedback after a render on OSX.

I get a small error during shutdown:

[2024-06-06T13:20:00.824] [INFO] main_renderer - The window will be closed.
[2024-06-06T13:20:00.825] [ERROR] main_renderer - Uncaught TypeError: Cannot read properties of null (reading 'export_mode')
source: file:https:///Users/makkura/wav2bar/out/Wav2Bar-darwin-arm64/Wav2Bar.app/Contents/Resources/app/js/index.js
 line: 1504
[2024-06-06T13:20:00.844] [INFO] main - closing main renderer... 

After shut down, my render folder was 82GB. So part of the issue is just a large operational space.
After starting wav2bar again, the render folder was cleaned up.

Will also test doing 2 renders without closing the program and checking folder size.
I only noticed this due to running out of space on my mac so could be an issue with rendering without closing between or just a larger render than others.

No update on Windows as of yet. My friend is rendering on windows so I have to get that info second hand.

[makkura]

Confirmed with my friend that windows acts the same way.
Cleans up renders/ on Start up.
Does not clean up on shutdown or when a render starts/stops.

So quite noticable on smaller harddrives.

[Picorims]

Thanks for the additional information. I hate this behavior too. I'll see if I can eventually plan a patch beyond the rewrite to clean it up more regularly, but due to how the render works, it has to write all frames on disk. So this specific issue can't be fixed easily without a rewrite.

Though, regarding the double render, it should overwrite existing render files instead of adding additional files. It might just not clean up all of them if, for instance, the previous render was longer.

Lastly, you might want to enable jpeg export, from what I remember it is both faster and lighter on the disk.

[makkura]

Reconfirmed with my friend on the Windows results and I misread what data he was dropping to me.
His is overwriting the files as you describe as his space usage is usually 60 ~ 80 gb after a given run.

I'm not sure if OSX is working this way or not at this time.
I have been trying to more along rendering this as a priority over perfect data collection for the issue.
I did hit a render large enough that, by itself, it used all of my remaining storage space. So that may have been the issue instead of back to back renders not reusing temp images properly.

Overall, I think the resolution for the storage issue is to clean up after each successful render.
This would make sure a bunch of temp space isn't in use after you're done with the application.
On a failed render, having the files available could be helpful.
Most of these issues hang the program so I'd hold off on adding a clean up on failure option until there's more error handling (eg: the rewrite).

As we have work arounds to handle things right now, I really wanted this discussion to be there for you to think of during the rewrite and for anyone else encountering the problem to see the discussion on it to understand what their options are.