V4 should tell you when it starts creating ~temp files

since it seems to know something is going wrong there.
It’s time then to restart then + create some sort of fallback version.

well it does tell you if you have TTY renderer open but yeah, why not tell you properly devs?

I wads persuaded that a temp file was a backup of your previous save ?

i’m not sure a temp file has ever opened up for me. Supposedly you can rename it and it’s were you were but like I say - never had any success with it.

I always have temp file when saving resaving :-)

@karistouf. surely you mean a file with ~.xml on the end? not ~tempX.v4p . If you’re getting ~tempX.v4p always when you save then you got major issues

where X = sequential number

tell you what, let’s just not have temp files in the first place

i like temp files - they keep you on ya toes - keeps things exciting - seat of ya pants stuff patching in vvvv

would maybe be exciting if you realised while it was happening. more depressing when you find out afterwards

it tells you in the TTY - you just have to keep an eye on it whenever you save a patch. I guess you could take the string output from the TTY and if it equalled…hmmmm… can’t remember was it says… something like ‘there seems to be a problem saving’, then pop up a renderer with a big warning sign.

Hi xdnitro and thanks about precision

Tty renderer: writting in it is not girly. For my part i notice something goes wrong when a same message is printed in loop.
It would be great to have color types per return:

No pb > printed in gray
Loading something > printed in white
Trouble with saving > in yellow
Trouble in vvvv > in red or orange

This would ease monitoring tty from the corner of the eye, not scrutating it in paranoid mode ;-)

We have a weird issue on our clients pcs that seems to be related to this thread.

The hosts are shut down by an external service, called RemoteClient via network from another machine. Every now and then, vvvv seems to crash while Windows is shutting down. It creates a …~tempX.v4p file with a size of zero and the original patch is gone.

It seems to me that vvvv tries to rename the patch and is interputet by the shutdown process.

This happened on two or three hosts with vvvv beta33.7 and beta34.1

We had to build a workaround, automatically performing a git revert on every startup.

But we were wondering what causes the problem in the first place. Why would vvvv rename a patch and is there a way from stopping it?

Any ideas?


Hi, such case happens when u have large amount data stored inside patch somewhere, basically huge spread get written to one of the ioboxes or pins reflecting it in your patch xml, making it unusable after… Many times it also result’s temp files when data get’s corrupted on the way. I doesn’t have anything to do with vvvv renaming patch or shutdown… Mostlikely you have something in that producing such results directly in the patch… Other option that vvvv on that instance is crashed or mem corrupted…

your fastest debug option is to run TTY Renderer on thous clients and see when it start spamming…

@bps what i don’t understand in your scenario is that you’re saying: vvvv is being shut down. at what point is then a file saved? because if you don’t tell it t,o vvvv would not save a patch on its own when it is shut down.

thanks for the replies!

unfortunately we did not log the tty to a file, but when it happens again we’ll be able to have a look.

also, we could not reproduce the problem so far. it just happens like once in week.

the application is running on pcs at a clients exhibition and they are shutdown via network by this software “remoteClient”. the client theoretically has remote access to the pcs to save something, but in this case it is unlikely that this happend.
we’ve looked up the windows eventlog and found, that the shutdown process has been initiated by the programm “remoteClient” and the temp file was created at exactly that time. that’s why we believe in a connection between these events.
unfortunately we have no clue at what time the original patch file dissapeared, but it seemed likely that it’s the moment the temp-files has been created. but maybe it is already gone before?!

so you’re saying there is no way vvvv would do something like renaming or deleting it’s own patches (which would totally make sense)?

i’m still trying to figure out what else could have made the original patch disappear. maybe we gotta install a tool for monitoring the file system…

Set the v4p to read only, is a solution I’ve used for installations.
Recently I’ve had this happen too, vvvv fails to quit cleanly, I force quit, and the v4p has disappeared, but the xml works ok. Again not all the time…

maybe using Self (vvvv) to disable query for save could help out

@sunep: cool feature! i didn’t know thats possible. however - the node works only for the current patch, doesn’t it? i could not find a way to make the option work globally for all patches.

@catweasel: we’ve been thinking about that as well. somehow we haven’t managed to. vvvv kept overwriting the read-only option in all my attempts. i actually like the solution to automatically perform a git revert on startup. that allows you to do quick bugfixes, without first removing the read-only option, but still stops anyone from messing up your code.

i see the problem with temp files but only when you actually save a file. i don’t see how temp files would be created when you only quit/kill vvvv without saving.

if there is anyway we can reproduce this please let us know.

We didn’t manage to reproduce it. It only happens on that specific machines, in that specific setup, apparently only after the application has been used for a certain time. Even trying to reproduce it on these machines by adding an automatic restart every few minutes couldn’t make it happen…

We’re gonna stick with git-revert method then.