[saving scene] Strange behaviour

vascoaredji

Greetings,

 

I observed and experienced a very strange behaviour since a while: when saving, the writing of the file -- the creation and the fill in -- is normal in terms of time to complete.

BUT, at the end of the saving process, when the pop-up window has closed I got "things" put both in RAM and VRAM (same amount and curves) -- I do not use CUDA -- that takes minutes and "three cycles" to complete. My system memory goes from 20% for example to 80% then I fall to 20%, this goes three times and then it stops. Like I was proceeding on rendering. The whole cycles takes between two to five minutes depending, seemly, to the scene complexity. I never saw such behaviour before.

I have no screenshots as Windows has no way to record/print screen natively. I will switch to windows and try again with my mobile recharged.

 

vascoaredji

These are the different pictures taken AFTER the dialog box concerning the "save as..." procedure has poped off.

 

vascoaredji

System

vascoaredji

Pictures -- the timestamps have been messed up, so you can't have a clue on the time it took to fall back to a functionnal DAZ studio 4.16.

During this "strange behaviour" the DAZ is NOT responsive you can not even kill the process or have to reboot Win10 because the whole system is frozen.

(Edited by mod to remove language)

PerttiA

Where are you saving to?

Yoyr ethernet activity at the same time looks suspicious.

vascoaredji

They are saved on a different partition on a different hard disk (SSD)... the Scenes folder is a symbolik link.

I did not see the point concerning the ethernet activity... I usualy work offline...

I have a clue: it happens mostly when my scene contains a generated terrain (UltraScenery)... I took early versions of a scene without the terrain and this behaviour won't trigger.

I use this terrain as a Scene Subset on lot of Scenes and I observed the behaviour is the same when "saving as" or simply "saving" --> the DAZ UI is not usable until waiting for minutes (sometimes 5 minutes).

 

vascoaredji

I confirm: when removing the "terrain", the behaviour can not be reproduced.

Question is: even generating a new terrain (considering the subset was corrupted) the behaviour could be reproduced.

It is linked to the terrain... how can I still use this environment without losing comfort (waiting for minutes is not comfortable as the save procedure has been done) ?

 

PerttiA

How big is your save file?

Usually the savefile only contains links to the assets and the size is from a few megabytes to few tens of megabytes, if it gets bigger, it is saving assets within the file and that does take time.

With the ethernet activity, I just wanted to make sure that you haven't used OneDrive for storing assets and/or saving to it, surprisingly many seem to do it.

vascoaredji

I would never use any clouds for saving files lol ^^ At worse an NFS in the local network but it isn't the case here ^^

Workaround: optimizing drive plus defrag, for saving just turn off the preview of the "terrain", now I got 20seconds of "lag" (with no memory burst) instead of several minutes.

The Scene file size is 39 Mb :{