Workflow behaviour changed - might I need old versions of packages?

[sannatitus]

Hello Bonsai group! Can someone double check my workflow, or provide a zip of an old Bonsai version with old versions of base packages (like Vision Design)? Does anyone know if old package versions are stored somewhere (like how Bonsai has a repo of old releases).

I have been running a workflow reliably for a couple years, but recently it's 'behaviour' changed. It's possible this change was from a Bonsai update, as this workflow was created when Bonsai was on version <2.6.3. However, I have tried to re-download old Bonsai versions and this did not solve the issue (maybe because packages are version 2.8?).

This workflow is intended to record from 9-19:00 daily. At the moment, it starts at midnight and essentially records all day. Another issue which arose at the same time is that I have to set videowriter at 1/2 acquisition FPS in order to write correctly. I'm able to circumnavigate this by acquiring in 60FPS and writing in 30FPS via Bonsai, but this might be related to the workflow issues. I've attached screenshots of my workflow (tank-writer group node) with relevant group nodes expanded (wait until next day, 9 (winter time), and video writer).

Nothing has changed in this workflow since it 'broke'. Did the function of DistinctUntilChanged node etc. change in recent updates? Am I missing something that's changed recently? Thanks for your help!

[banchan86]

Hi! That is indeed odd, there is a way to use old package versions, but my feeling is that its not the issue. If you attach your workflow as a zip as outlined in #864 I could check it out.

[sannatitus]

Thank you @banchan86 ! Here is a zip of my bonsai and layout files. I am using a Logitech Brio 4K Webcam for both camera acquisitions. Let me know if there's any other info I can provide! I can also give a zip of my current bonsai environment, but I've tried a couple different versions without success.
tank+tub_daily_winter.zip

[banchan86]

Hi @sannatitus

So several points here:

• The VideoWriter and CsvWriter subscriptions aren't connected to the timing logic workflow (in fact when I run the workflow, the video and csv files are already being written despite setting the time range outside when it should have been recording). This might have worked in an earlier version of Bonsai, but I don't think it's the correct behaviour for the GroupWorkflow node. You can ungroup the videowriter node and see that those branches are separate. I uploaded a version that only turns on those subscriptions (SubscribeWhen) when the timing logic workflow issues a notification through the Source1 'WorkflowInput` operator. This might the simplest fix that works, and it works with the short videos that I tested, but I haven't tested the daily looping. I only modified tub-winter, make sure to check and modify the time and filename variables as I changed them for testing (#2084_amended.bonsai.)

• There might be a simpler way of building the workflow, as the workflow above seems a little complicated and suboptimal at parts (the video and time stream is bundled together and subscribed repeatedly, and the stream is timestamped multiple times). Since it seems that you record for a fixed amount of time, would something like this work? The SelectMany node will trigger a recording session for the duration specified in WindowTrigger. I took this workflow from old discussions post which I am not linking to just for SEO reasons :P (#2084_timeofday_filtering_trigger.bonsai)

• The FPS video speed is a separate issue, and I don't see anything in the workflow that should affect it (nor should it affect the timing logic). When you say you are acquiring at 60FPS, do you mean that you are setting the FPS for the Logitech Brio Camera as 60FPS in the Logitech Capture software? Unfortunately, whether or not it propagates to Bonsai is not guaranteed, as there are different video APIs and not all manufacturers respect those APIs. More than likely the video acquisition when CameraCapture is turned on is actually at 30FPS not 60FPS, and so setting the video writer to 30FPS "solves" that issue because that is the actual video frame rate. You can check the timestamps.csv and count the frames (there should be 30 frames for every "second", if it's really 60fps your video would be playing at half speed and be twice as long).

Let me know if that clears up the issue!

#2084.zip

edit: Forgot to add that this was all tested with the latest Bonsai release v2.8.5 and packages
edit2: If you find something that works for you and you want to avoid the same problem in the future, consider setting up a local bonsai environment for that experiment. Technically, that article provides the information that you need to test old package versions if you want to go down that route :P

[sannatitus]

The 'simpler approach' workflow within banchan86's zip solved my issue! #2084.zip

[sannatitus]

Hi @banchan86 , thank you so much for your incredible advice! I modified your #2084.zip to this workflow (groupworkflow-fix-Jan25.zip) and it has fixed the recording window to be correct from 9-19! However, interestingly, the filenames are still at T00_00_00 despite correctly initialising at the set time of 9:00. The timestamps in Bonsai have always been reliable for me, so this is strange! Is it perhaps because of the repeated subscriptions and timestamps?

I agree the workflow can be more straightforward, but I am surprised it 'broke' this much as one of the Bonsai developers helped me create this workflow together some years ago. Would you have a zip of the simpler approach, or can point me to the original time filtering discussion? I can't seem to find it :/ I have attempted to put together something like the photo, but am not quite positive on the contents of each group node. Perhaps you can tell me what's missing from this attempt (groupworkflow-simpler-Jan25.bonsai.zip).

RE FPS - We can ignore this for now, but yes, I meant I'm setting the Logitech Brio Camera at 60FPS in the Logitech Capture software which must not be propagating to Bonsai. I figured it would function similarly as other SDKs (e.g., Pylon, SpinView), but it makes sense they likely have different APIs! When Bonsai videowriter is set to 30FPS, the associated .csvs reveal the 'tank' camera actually acquires at 30FPS (tank2025-01-10T00_00_00 - 30FPS.csv) but the 'tub' camera is 28FPS (tub2025-01-10T00_00_00 - 28FPS.csv). However, I suspect this FPS discrepancy stems from having an AMD threadripper motherboard and multi-core, multi-processor CPU, which are known to cause video acquisition issues with Bonsai.

Ultimately, if you could give advice how to correct the timestamp (likely from repeated subscriptions?) that would be highly appreciated!

[banchan86]

1. Unfortunately, I couldn't reproduce the T00_00_00 bug, so not sure what is going on there, does it happen all the time? the repeated subscriptions shouldn't be affecting the csvwriter, I see that its set to not overwrite so if anything it should be creating different files, but on my computer it does produce timestamp files with the right time. I'm afraid I can't really help with the timestamp problem here, but try the other workflow.

2. The simpler approach is included in the 2084.zip as #2084_timeofday_filtering_trigger, I downloaded the file and verified it's there. The original discussion can be found here - https://groups.google.com/g/bonsai-users/c/SAl0N-2gc6U/m/TI3GOT8UAgAJ.

3. It might be worth trying to track down the FPS issue, since even losing 1 or 2FPS builds up over time. Is the lighting different between the cameras? Sometimes adding more light can help those webcams meet their FPS targets. It's strange that it primarily only affects 1 camera, as I would think that a PC hardware issue would affect both.

[sannatitus]

Hey @banchan86 ! Thank you :) It is fixed!! Here's a more detailed response, point by point in case it's helpful to anyone in the future:

1. With the first workflow fixing attempt, the timestamp was always correct on the very first intitiation of the workflow, but every video thereafter was T00_00_00. A real-time in-frame clock confirms acquisition actually starts at the correct time of 9am. Both the csv and video file have a T00_00_00 suffix, but the first line in the csv also confirms acquisition starting at 09_00_00 (here is the first cell of tank2025-01-15T00_00_00.csv, for example: 2025-01-15T09:00:00.0527104+00:00). However, doing the 'simpler approach' has fixed the problem!

2. Sorry, didn't see the second workflow in there; I tried it for the last week and it's been flawless. Thank you so much!

3. Yes it's a strange behaviour indeed, but it's an issue I've had across multiple AMD desktops with different cameras. Even employing more reliable equipment than a Logitech webcam, such as FLIR and Basler drivers, different cameras are affected at different times when multiple are connected. I was advised by the Bonsai developer team that when acquiring video data, it is always best to have a single core, single processor CPU (such as intel) and AMD threadrippers (multi core, multi processor CPUs and their motherboards) specifically often cause issues.

[banchan86]

Glad it worked for you!