Feature request Realtime: WebUI only, but without Analysis (and Analysis only, without WebUI?)

[HWittingen]

Currently I've two BirdNET-Go Raspberries realtime listening and analyzing all they hear. One at each side of the house. Instead of both locally storing their data I've configured them to both use the same server based MySQL database. The audio and spectogram files too are stored in one shared network folder.
Optional I can take my Windows laptop (with a cross compiled Windows build of BirdNET-Go) somewhere and use it as a third bird listener using the same shared datastorage.

When I want to see the detection results I can turn to the webUI from either device. No surprise that all show the same combined detection results (execpt access to the device specific settings!).

How about not disturbing the 'listener' devices too much and centralize the web presentation of all collected data?

I tried to use BirdNET-Go on my Linux server for such, but next to the webserver activities it keeps also continuously analyzing.

So I was searching for and thinking about a simple switch to optional turn off the realtime analysis proces.

Is it my fantasy runnnning too far? Any different solutions? Or ....

[tphakala]

Sorry I may not understand your question perfectly, but I am thinking that wouldn't it work if you would have only one BirdNET-Go instance and other systems are just streaming audio over RTSP to this instance?

BirdNET-Go can receive multiple RTSP streams, and serving audio over RTSP is quite easy with help of ffmpeg and MediaMTX.

[HWittingen]

No doubts about your understanding. Hahaha.
Your answer is clearly giving the alternative that I asked for. But ....

Some disadvantages I feel about your proposed solution:

• Centralized analysis of multiple streams has a huge processor demand
• Multiple audio streams increase network traffic, decrease wifi stability
• All detections get stored in the database with the one and same source_node

My current set-up is focused on minimizing network traffic and distributing the heavy analysis work.

Next to that I could define/refine database queries that filter on source_node for detections in my front 'forest' or in closed backyard.

[tphakala]

Just to comment on your concerns

• "Centralized analysis of multiple streams has a huge processor demand" with RPI 5 class device this would not be a problem at all
• "Multiple audio streams increase network traffic, decrease wifi stability" RTSP audio streams use minimal network bandwidth, this is unlikely to cause any issues
• "All detections get stored in the database with the one and same source_node" there is an open feature request to tag each RTSP stream so that source of audio and detection is visible in UI, this is on my todo list (contributions would also be welcome)

[HWittingen]

Thank you for your comments. They illustrate that the world isn't b&w only. A balance needs to be found anyway.

• Processing power. Centralized or decentralized. Pretty much depend on what's availlable and at what cost
• Network traffic. Continuously multiple audio streams or only some database requests every few minutes
• Data design. Source_node comes close to be the attribute related to your open feature request, although nodes and streams are different

Those are all details and sub to the bigger picture. My primary question has all with upscaling from all-in-one single device to a larger world.

In such case it's all about the good-old client-server principles. Where to cut in the input, process and output chain. And where to place the connected essential datastorage?
I prefered (and still do) distributed input and processing combined with central data storage and output formatting and presentation. And honestly. The MySQL instead of Sqlite option in BirdNET-Go pushed me that way.

For me it would be helpful if a simple switch could help cutting the all-in-one BirdNET-Go program design to act different at both side of the cut without destroying the all-in-one basics.

But of course. It's your design and your decission. Just take my thoughts. Thanks for all, including the MySQL fix last week.

Wish you a Merry Christmas.

[jkrauska]

@HWittingen Another technical framing of your ask is to decouple the WRITE path (record/analyze/store) from the READ paths (present data, analyze patterns).

Imagine an extended family of bird lovers who all want to share/stream their own back yards possibly 1000s of miles away from each other. While being able to see eachother's detections. (add a social dimension) Independent writes would help solve this design.

It may be easiest to create a true "BirdNet" with a federation of BirdNet stations with independent sqllite nodes pushing data centrally to a single scaled up mysql node for shared viewing. Obviously "recording location" needs to become one of the metadata stored with every recording.

I think there's some awesome power behind your idea. I'd love to help see it become a reality.

Merry Christmas back at you.

--Joel

[tphakala]

Imagine an extended family of bird lovers who all want to share/stream their own back yards possibly 1000s of miles away from each other. While being able to see eachother's detections. (add a social dimension) Independent writes would help solve this design.

BirdWeather is for this https://app.birdweather.com/

[HWittingen]

@jkrauska You got the picture. Thanks for the support.
@tphakala My first thought is to agree. BirdNET-Go is for the nodes. BirdWeather is the world. And in between ...

Now imagine a Christmas Miracle. You're appointed as the technical lead of a bio-scientific research team in some Canadian Provincial Park. They have put BirdNET-Go nodes in every corner of the park. Data collection and combining is a real headache. And the per node Daily Summuary is nice but not enough satisfying.

The team wants a more aggregate presentation of the data. But they absolutely love the hourly count details.
Next to per day view, they want per week, per month, per season, or per whatever period.
And next to per node view, they want all nodes combined, or a multiple select combined (all lakeside nodes, all marshland nodes or a free choice).

For sure BirdWeather doesn't answer all imaginary questions when social starts moving to science.

[jkrauska]

this is snarky, but I feel like BirdWeather is mostly meant to sell PUCs. The mobile version of BirdWeather doesn't even show Pis.

In my opinion isolating write and read paths is good systems design.

[tphakala]

I am not against this idea, but I am quite overwhelmed with amount of work with already existing todo list so I was offering alternatives which could be used right now.

[HWittingen]

Thanks for the honest answer. I do really appriciate. And I agree that producing (wild) ideas in general goes much faster than creating (perfect) solutions.