Zac Gaetano
c30a6163c8
Some checks failed
CI / build-and-test (push) Failing after 26s
When a process spawns and NDI Find returns zero sources at cold start, the finder can stay stuck on zero forever even when other processes can see Teams' broadcasts. Observed today: a user's PID launched at 12:50, ran for 9+ minutes showing 0 sources, while a parallel PID launched at 12:59 immediately discovered 2 sources. Same exe, same install, same Teams meeting, same medium-integrity SAFER token. The first process's finder simply got into a bad state at construction (suspected: NIC-bind race against mDNS responder readiness, or a SAFER-token quirk in the NDI runtime's IPC layer). The fix: auto-rebuild the finder when (a) we've never seen a source and 5s have passed since startup, or (b) the source set has been empty for 15s after previously containing entries. Both paths back off (>=5s and >=10s between rebuilds respectively) so we don't churn during legitimate empty periods. Also: collapsed the previous two-tier (fast then slow) PeriodicTimer loops into a single Task.Delay loop with a dynamic interval. Same behavior (200ms for first 3s, then operator-configured pollInterval), less code, easier to thread the self-healing logic through. The finder is still disposed in a try/finally so cancellation paths don't leak. 246/246 tests still passing. The Discovery tests use PollOnce directly so RunAsync changes don't affect them. |
||
|---|---|---|
| .. | ||
| TeamsISO.App | ||
| TeamsISO.Console | ||
| TeamsISO.Engine | ||
| TeamsISO.Engine.NdiInterop | ||
| tests | ||
| .gitkeep | ||