"First or default" throws exception on build startup

[schlonzo]

hi all,

I have a problem that throws an exception when I run my build.
I finally found the culprit, but I really don’t understand what is going wrong here.

turns out it is the path going into the DIR node.
when I feed the path directly into the node everything works.

if I grab the same path from my path spread, and use “first or default”
I get the following error on startup: startupError.zip (166 Bytes)

I can reproduce this error. I just build each version three or more times.
I tried this with stable as well as latest previews! same behaviour.

the video transcoding region does not get executed (in the second case), and consequently datatypes are not generated from my assets. later on the “bw.video” throws the exception because there is no video datatype available.

what is going on here? imo this should not be able to cause an error!

the paths are identical

The patch, containing the paths, is evaluated from the beginning,
just the region below is executed later at some point.

I also tried setting a pad into the patch, because I thought maybe it is connected to the experimental synchronizer. same outcome

[bjoern]

My guess is that FirstOrDefault doesn’t return a valid path in the first frame. Have you tried to S+H the output with OnOpen to check it?
And ofc you could also use a GetSlice instead.

[Elias]

The attached zip file contains an empty txt file. And any chance you can provide a patch showing the problem?

[schlonzo]

checked with s+h, running in the editor, “FirstOrDefault” outputs the correct path in the first frame. I also tried writing the path to .txt onOpen, which works in the editor as well as in the build.

I tried using “FirstOrDefault”, “GetSlice” and “Decons” to feed the path into the dir. When running the build, the synchronizer does not execute. In-Editor all versions do work. The moment I change back to the single path input the build works as expected.

I tried isolating the problem in a simple patch, but I can’t reproduce it. test.zip (9.9 KB)
so I guess it can not the filepath after all?

but then again, it is still reproducable. changing back and forth between single path and getslice makes this synchronizer run or not. I have multiple, which work nearly identical, and the video synchronizer breaks, depending on the path input.

[Elias]

Hmm, sorry, but I can’t quite follow. What are all those file writers for? Are they important? My wild guess would be that something is off with them - at least file IO operations are the most common trouble makers.

[schlonzo]

Sorry for the confusion. I tried simplifying the problem, but there are no file writers in my particular use case. I use them, because my executor and ffmpeg do write something to disk.

I patched it this way because I figured the problem could involve the (experimental) synchronizer and a spread, which is directly connected to it as well as other parts of the patch. nodes inside the synchronizer are executed on (synchronizer?) create, and I figured it might have something to do with my problem.

Thing is, when I reproduce this error, all files are already converted and nothing is written to disk.

[catweasel]

Does the first or default not need a valid default specified?

[digitalwannabe]

Don’t know if this helps - I’ve had a similar case a few weeks ago where the Dir node would not update after refresh when reading the path from a Pad, but it would update when reading from an IOBox. I couldn’t reproduce this on another machine though, so didn’t follow up…

edit: here the recordings folder is created on startup, so it’s empty first. Before I’ve recorded this gif I have put a file in there and hit refresh. Why I have to click Refresh three times after I switch to the pad until it shows no file - no idea, but it’s been consistent on this 1 machine.