we’ve got pretty complex system for vjing and beta22 introduced pretty weird behavior with it ::
topmost patches at some point cannot be saved anymore (despite ‘save’ signal is catched by vvvv - underlying patches are saved normally, but not the most complex top ones); some patches lose half of internal links when opened.
i didn’t manage yet to find out specific conditions leading to that, but rollback to beta21 solves this.
regarding filestream2 (vvvvery long awaited) - it works in simpler patches, but hangs 4v in more complex ones. it’s not resolution problem as mentioned here already (all the footage is pal 720x576), but we do use lots of getslice texture nodes, which i guess might be the reason.
hope that this can be tracked and solved soon, cause we do need boygroup fix implemented in b22…
i am afraid we won’t be able to do anything about the weird behavior you mentioned as long as you can’t provide more detailed information. do you have a Renderer (TTY) open all the time? does it mention any troubles?
try to narrow the problem down by removing parts of your setup systematically until the problem is gone. then check the last part you removed before it was working…
that was my approach, but things were not that obvious. i’ve found most problematic part, recreated it, saved (successfully), but on the next restart it was the same again.
i’ll keep on testing, this is just to let you know at once that patching engine became kinda buggy
the new feature of spreading the filename of the xfile node is implementated in a way that the loaded xfiles are concatinated, which goes wrong with your xfile for still unknown reasons.
i could however fix the case where only one xfile (yours) is loaded.
for beta>22
