Increase ffmpeg thread queue size in recording script

[alexbelgium]

Tentative fix Non-monotonous DTS in output stream alexbelgium/hassio-addons#2273

[alexbelgium]

Confirmed working, it was probably too stringent

[Nachtzuster]

Interesting, I wonder if it is specifically container deployments that need the -thread_queue_size parameter.

This is removing the -xerror (there to avoid hangs) too, I'd prefer putting in just the -thread_queue_size parameter.

[Nachtzuster]

@alexbelgium also slightly confused with the version numbering: the reports says version 2025.11.09 is affected, but looking at this repo's history - the one-ffmpeg-instance-per-stream change came in on 2025-11-15. Are we sure 2025.11.09 has that change?

[alexbelgium]

Hi, well my numbering is suboptimal : 2025.11 is year and month, but the last number is sequential from 1 to enable multiple builds when I try something… build 2025.11.09 was built on 12 novembre, but even then it was built from my own birdnet fork and not yours. My fork is a perfect clone of yours, where I dynamically merge all open non draft PR in my addon image. It allows to have a full clone of your code while adding mine on a clean manner. However this means that I must sync my repo to have your latest code. In this instance. Even though you pushed the birdnet-recording.sh changes on 12 November also it didn’t go incorporated in my own 2025.11.09 build made on 12 nov…

I will try to readd the xerror and ask my user to confirm ! I think it’s mostly due to shaky rtsp streams that need some permissiveness on the system to avoid being stopped

[alexbelgium]

After checking, it is the xerror that causes the failure for the rtsp streams. I’ll readd it except if you prefer that I just add it dynamically in my addon

[Nachtzuster]

After checking, it is the xerror that causes the failure for the rtsp streams. I’ll readd it except if you prefer that I just add it dynamically in my addon

if -xerror is what is needed, then lets add that. edit: if removing -xerror is what is needed, then lets do that
I believe thread_queue_size was added when support for multiple streams was added, so probalbly not helping now.

[Nachtzuster]

Thinking more about it, thread_queue_size is pretty unlikely to help here: as I understand, ffmpeg puts out a warning (sugesting adding this parameter), when it is about to overrun the queue, but I do not see that in the logs in the issue.