Alpha Testing BirdNET-Lite from a user perspective

[CaiusX]

Hi @mcguirepr89, @DD4WH, @Christoph-Lauer and other alpha testers

Here are some comments on my experience running the BirdNET-Lite alpha for 5 days - can probably be a source of a couple of new discussion threads, but let me log all here.

Firstly, the System is FANTASTIC @mcguirepr89, pretty much foolproof installation and getting up and running. Reboots, script automation etc haven't been problematic at all. Any comments are not criticism but hopefully can be used for improvement.

1. SD-Card Size and Memory Management. My initial long term test was on a 32GB card, which toppled over after about 2.5 days with disk full. Am currently running on a 64GB card for 2.5 full days and have about 27GB free space. I'm not sure what's going to happen after 3 days, hopefully the script cleans up the "Processed" folder (20GB at this stage). Whilst these files are useful as a record, the actual identification recordings are much smaller (~3GB) and can be kept as a long(er) term record. A system for checking remaining disk space and prompting file deletion/archiving options when space is low would be useful.

2. Web Interface. Instructions given in https://github.com/mcguirepr89/BirdNET-system/discussions/29#discussion-3599470 are good on the Pi-side, but takes a bit of a learning curve on the router and ISP side, since this will be different for each user there's no way that a full set of instructions can be given. Following those provided, with a fair bit of trial and error and help from friends, gets it working. In my case the biggest stumbling block was on my router - needing a fixed IP for the Pi and "port triggering" set for ports 80 and 443 as well as "port forwarding".

3. I tried to get two BirdNET-Lite systems running on the same LAN (one for long term testing and one to test updated daily git distributions), I couldn't get "birdnetA" and "birdnetB" systems working together so reverted to a long term test without daily alpha updates. I think having two systems running on the same LAN is a special case and not worth pursuing.

Instructions on how to do a daily Git update without losing long-term data will be useful.

4. In the absence of any database gurus responding to mcguirepr89/BirdNET-system#30 , I hacked together some code in the attached analyze.py to write recognitions to a ";" delimited txt file which can be read into a database/analytical/programming system of choice (Python Pandas, R, PowerBI, Tableaux, Excel, Visicalc.....) . A real Python coder can no doubt improve and extend on this.

The fields I am recording at this stage are
Date; Time; Sci_Name; Com_Name; Confidence; Lat; Lon; Cutoff; Week; Sens; Overlap

Pulling this into PowerBI (pbix file attached which is set up for the BirdDB.txt) I have been fiddling with various dashboards -

analyze_BirdDB_PowerBI.zip

Birdnet_analysis_b.pdf

Besides the African Penguin problem I previously reported and deleted from the Whitelist, another obvious "false positive" is "Bearded Woodpecker" which should be Com_Name - "Rain falling on Weber Braai" Sci_Name - "Raindroppus_barbeque".

5. I'm still developing a "workflow" to get a handle on the efficacy and application of the system and improve the outputs within the constraints of the currently trained model.

• Look at spectrographs in Audacity on the Pi, compare to Xeno-Canto & e-Bird sonograms
• Decide if the AI is "right" most of the time for a particular specie - keep on Whitelist
• Eliminate obvious false positives from Whitelist
• Determine which species I can hear frequently but aren't being logged proportionately (Southern Boubou and Crested Barbet), and follow mcguirepr89/BirdNET-system#26 keenly. My Boya M3 microphone S/N, sensitivity and frequency responses are clearly is inadequate, but is a cost effective, compact, mobile, long cord solution at this stage.
• Look at the best "confidence" cutoff to get most true positives/eliminate false positives.
• Following this will look at changing sensitivity setting, overlap etc.

6. I'm going to a nature reserve this weekend in a different part of the country, hopefully I have followed https://github.com/mcguirepr89/BirdNET-system/discussions/16#discussioncomment-1374036 sufficiently to augment my database with a new location/species in a headless Pi environment without SD card getting full!!

I trust this meandering post from a "user" perspective has been useful and sparks some ideas, discussion and development paths. I look forward to sharing my birdsounds and analyses in the future and helping with testing, contributing to the Wiki and generating ideas.

Best
African Penguin

[ghost]

Hello African Penguin, confirm the 20...30GB wave file storage, I think it is a kind of ringbuffer which deletes every 2 days. As far I can see is the migration of the extractor to db not so easy. I designed a new index.html.

[CaiusX]

@mcguirepr89 - best move this thread to the Birding-Pi repo; sorry, didn't see it before now.

[mcguirepr89]

I'm bummed -- I wrote you a long response yesterday and I don't see it here -- so I guess it never actually was made as a comment. I'll respond better today once I see what else didn't go through from yesterday

[mcguirepr89]

@CaiusX This is a re-do of the response I thought I gave you yesterday, but don't see anywhere:

First of all, thank you so much for all of your testing and wonderful contributions -- I boast of where the project is listening anytime anyone gives me the chance, and I love having South Africa on the map!

1. SD-Card Size and Memory Management. . . .

The way disk space is managed now through the cleanup.sh crontab is not as robust nor as sophisticated as it should be. Currently, every day at 1AM, the cleanup.sh is run which will remove all files over 2 days old found in the "Processed" directory. I am going to be rebuilding the cleanup.sh script to have the sophistication and robustness that it needs with the new script.
The new script will:

1. Automatically detect SD card size (to support any size over 16GB)
2. Determine whether to remove "Processed" data based on remaining available disk space
3. Run at 1AM as usual, but also upon each reboot so devices not monitoring overnight still receive disk space management
4. Never keep empty .csv results
5. Display a "Low Disk Space Warning" on http://birdingpi.local whenever available disk space dips below 15%

2. Web Interface.

I wanted to discuss your experience on the ISP/DNS/Router side of things to see what your thoughts might be for publicly available installations. I know you've had to do a bit of homework on subdomains and DNS records, as well as Router port settings and DHCP leasing and reservations -- with all that in mind, I wanted to see what you think is the most elegant solution for reaching all web interfaces. I'l likely email you separately with some nitty-gritty that could contain a bit of sensitive information (which is why I do not wish to post it openly here).

3. I tried to get two BirdNET-Lite systems running on the same LAN (one for long term testing and one to test updated daily git distributions), I couldn't get "birdnetA" and "birdnetB" systems working together so reverted to a long term test without daily alpha updates. I think having two systems running on the same LAN is a special case and not worth pursuing.

I would say that it is not worth it. It is possible, but complicated. The short explanation is that both devices want to play the exact same roles on the LAN (i.e., be the device with hostname "raspberrypi", announce Avahi web services called "http://birdingpi.local" "http://birdlog.local" "http://extractionlog.local" and "http://birdstats.local"). Setting up DHCP reservations for each device to have their own IP address solves one slice of the pi (pun!), but resolving the avahi services would require abandoning them altogether, changing them completely, or a combination of those plus editing the Caddyfile to point to IP addresses instead of Avahi aliases.
All in all, the testing results you provide from long term observation is incredibly valuable. If the itch to test the newer versions gets to be too much, you can just take the long-term tester offline (if it's not too much hassle) as it will still operate offline without any issues (you just won't be able to access it until you bring back online).

4. Database . . .

I was in the library yesterday using some internet when I saw this. Without realizing what I was doing, I said several profanities of excitement at louder than full volume . . . in the library . . . because this is great! I had the same idea as you, elaborating the results.csv for loading into a DB. Your results are sooooooooooo exciting!! If we don't find any DB gurus to take the helm on that, I know enough about DB management and now have the internet and can continue to learn, so I know it is only an eventuality for this to be an integral part of how this system works.

Besides the African Penguin problem I previously reported and deleted from the Whitelist, another obvious "false positive" is "Bearded Woodpecker" which should be Com_Name - "Rain falling on Weber Braai" Sci_Name - "Raindroppus_barbeque".

😆 🤣 🌧️ 🍔

5. . . .

There is a new feature of the project now that incorporates a Spectogram view of the audio file that the system is currently analyzing. I plan to have spectrogram views also available for all extracted data. I hope this will be helpful for you in making observations across platforms.

6. I'm going to a nature reserve this weekend in a different part of the country, hopefully I have followed Suggestions and feedback from a biologist BirdNET-system#16 (comment) sufficiently to augment my database with a new location/species in a headless Pi environment without SD card getting full!!

Awesome!!! May I ask which nature reserve? I recently learned that the system is listening in the Donau-Auen east of Vienna, Austria this weekend as well :)

Lastly, according to the detection data, I have finally been properly identified as . . .
Your friend,
The Trumpeter Swan 🦢