The concurrently released MiBeeNvr v0.6.0 brought major features like timelapse, video transcoding, and ONVIF enhancements. Unit tests alone are far from enough — the full workflow must be tested against real camera hardware. To provide reliable test machines for this release, three camera projects were updated on the same day, June 5th — both to supply testing environments for the NVR and to solve some typical embedded development engineering problems along the way.
After running continuous recording for a few weeks, storage became the first bottleneck. A single 1080p camera writes tens of GB per day — with a 30-day retention policy, a 1TB drive is mostly consumed. Many community members reported the same issue, and during discussions, the ideas of timelapse and transcoding storage gained the most traction: most of the time the scene is static, and compressing it with timelapse requires only 5% of the space for the same duration.
Less than a week after v0.4.0, another 31 commits were pushed. v0.5.0 is a feature-dense release: full ONVIF protocol support (covering all five major services: Device/Media/PTZ/Imaging/Event), hardware transcoding (H.265 → H.264), and recorder reconnection optimizations. 127 files changed, +24,509 / -730 lines. See the full changelog at GitHub Release Notes.
If you haven’t seen the previous versions, check out MiBeeNvr Introduction and v0.4.0 Technical Post.
Full ONVIF Protocol Support v0.4.0 already had ONVIF device discovery and stream URL retrieval, but that was just the tip of the ONVIF iceberg. v0.5.0 completes the core services of ONVIF Profile S:
Coming from an operations background, later transitioning to development, the number of projects I maintain keeps growing. Various middleware, databases, monitoring components… each version upgrade is a manual labor: go to the official site to find the download link, compare version numbers, manually download to the internal network, then distribute to each machine. I used to write a bunch of Shell scripts to periodically pull the latest versions to the LAN — functional but not user-friendly: scripts scattered everywhere, adding new software required writing parsing logic by hand, and there was nothing to check when things went wrong.
After v0.3.1 shipped, I put in another 196 commits. v0.4.0 is a feature-dense release: audio recording pipeline, multi-layer health monitoring engine, HLS/LL-HLS playback stability optimization, and a major UI redesign. For the full changelog, see GitHub Release Notes.
The previous post covered v0.3.x’s multi-protocol streaming and Xiaomi camera support (v0.3.0 Tech Post). If you haven’t read the first post, start with MiBeeNvr Introduction.
Audio Recording: From Silent to Sound In the v0.3.x era, recorded MP4 files only had a video track. v0.4.0 introduces a complete audio capture and muxing pipeline, supporting AAC audio from RTSP cameras and G.711 audio from ONVIF/Xiaomi cameras.
Previously, MiBeeNvr’s MP4 files only had a video track — playback was silent. v0.4.0 fills this gap with audio recording. It also adds more practical camera health monitoring and auto-recovery.
Recordings Now Have Sound Each camera can independently enable audio recording:
yaml 1 2 3 4 5 6 cameras: - id: "front-door" name: "Front Door Camera" protocol: "rtsp" encoding: "h264" audio_enabled: true Supported audio formats:
#XQ|A lot of work went into the releases after v0.2.0. v0.3.x brings several major updates: native Xiaomi camera support, recording archiving, multi-protocol streaming architecture (WebRTC/HTTP-FLV/RTMP/SRT/LL-HLS), and a wave of security hardening. The architectural evolution from external dependencies to built-in implementation, from single protocol to full protocol support, was much more complex than I expected.
The previous post introduced v0.2.0’s 15 new features (v0.2.0 Update). If you haven’t read the first post, start with MiBeeNvr Introduction. v0.3.0 focuses on deep Xiaomi camera integration, and v0.3.1 builds on that with a complete multi-protocol streaming architecture. For the full changelog, see GitHub Release Notes.
Got Xiaomi cameras at home? Want to keep your recordings on your own storage instead of relying on the cloud?
As someone with several Xiaomi cameras at home, I always had one frustration: every time I wanted to check the footage from my doorbell camera, I had to log into Xiaomi Cloud, wait for ages while it loaded, and it would often just spin. Plus, cloud storage charges by the day — it adds up over the month. And if you swap cameras, all your old recordings are gone. Pretty frustrating.
One Month In It’s been nearly a month since the previous article Switched My Blog Theme: From Hugo NexT to Self-Written Zhi. During this month, the theme has been running stably without major issues. Replacing the NexT theme was the right decision — although there was some initial adjustment, the experience is now significantly better.
After a month of use, the theme’s stability has exceeded expectations. My initial concerns — whether pure Hugo Pipes without build tools could support complex requirements — were proven unfounded. Daily maintenance has become very simple; modifying a feature no longer requires digging through deeply nested SCSS files — one CSS file gets the job done.
The previous article introduced MiBeeNvr’s basic features and design philosophy. It’s only been a week since v0.1.0, and v0.2.0 follows right behind. This update is substantial — 15 new features, some I needed myself, others from community feedback.
This article covers three things: what’s new in v0.2.0, how to deploy from scratch, and some practical tips for real-world use.
v0.2.0 New Features Overview This update has a lot of content. Here’s a breakdown by category: