Hi everyone,

I recently bought an OBSBOT Tiny 3 and really liked the camera, but as a Linux user I missed having a proper control app similar to OBSBOT Center.

So I built one and wanted to share it with the community:

GitHub: https://github.com/vampyren/obsbot4linux

It is called OBSBOT4Linux. It is an unofficial, community-built Linux control app for OBSBOT cameras, currently tested on my OBSBOT Tiny 3.

https://preview.redd.it/rb3gmemosuah1.png?width=1315&format=png&auto=webp&s=d37f4f89add5138b752fdfd75cb13dcc002e0d29

What it can do right now:

- Wake / Sleep / Center
- PTZ control with joystick-style hold-to-move and precise step nudges
- Zoom and FOV control
- AI tracking
- Face autofocus
- Gesture control toggle (has SDK limitation, it works but you do not see the nice detection inside the preview)
- Presets with save / recall / startup preset
- Image tuning: brightness, contrast, saturation, sharpness
- External preview through ffplay with selectable preview resolution
- Activity log showing the actual SDK return code for commands
- AppImage release for easier testing on Linux

It is built with Qt 6 / QML and uses the OBSBOT SDK. I have validated it on a real Tiny 3 running firmware 6.6.9.1.

A few important notes:

- This is not official and I am not affiliated with OBSBOT.
- Tiny 3 is the only model I have personally tested so far.
- Some controls are intentionally disabled if the SDK / camera does not clearly support them.
- Embedded in-app preview is planned next; right now preview opens externally.

- Feedback and testing on other OBSBOT models would be very welcome.

I attached a screenshot of the current UI. If anyone wants to try it, report bugs, request features, or contribute, feel free to open an issue or PR on GitHub.

Hope this helps other Linux users.

Hi everyone,

I recently bought an OBSBOT Tiny 3 and really liked the camera, but as a Linux user I missed having a proper control app similar to OBSBOT Center.

So I built one and wanted to share it with the community:

GitHub: https://github.com/vampyren/obsbot4linux

It is called OBSBOT4Linux. It is an unofficial, community-built Linux control app for OBSBOT cameras, currently tested on my OBSBOT Tiny 3.

https://preview.redd.it/rb3gmemosuah1.png?width=1315&format=png&auto=webp&s=d37f4f89add5138b752fdfd75cb13dcc002e0d29

What it can do right now:

- Wake / Sleep / Center
- PTZ control with joystick-style hold-to-move and precise step nudges
- Zoom and FOV control
- AI tracking
- Face autofocus
- Gesture control toggle (has SDK limitation, it works but you do not see the nice detection inside the preview)
- Presets with save / recall / startup preset
- Image tuning: brightness, contrast, saturation, sharpness
- External preview through ffplay with selectable preview resolution
- Activity log showing the actual SDK return code for commands
- AppImage release for easier testing on Linux

It is built with Qt 6 / QML and uses the OBSBOT SDK. I have validated it on a real Tiny 3 running firmware 6.6.9.1.

A few important notes:

- This is not official and I am not affiliated with OBSBOT.
- Tiny 3 is the only model I have personally tested so far.
- Some controls are intentionally disabled if the SDK / camera does not clearly support them.
- Embedded in-app preview is planned next; right now preview opens externally.

- Feedback and testing on other OBSBOT models would be very welcome.

I attached a screenshot of the current UI. If anyone wants to try it, report bugs, request features, or contribute, feel free to open an issue or PR on GitHub.

Hope this helps other Linux users.

Hi all, looking for opinions before I RMA the wrong part.

Hardware:

- Motherboard: ASUS ProArt X870E-Creator WiFi

- CPU: AMD Ryzen 9 9950X3D

- RAM: 2 × 48 GB Kingston Server Premier ECC UDIMM DDR5-5600

- PSU: be quiet! Dark Power 14

- Cooler: Noctua NH-D15 G2

- GPU: none installed during troubleshooting, using motherboard/iGPU output

- Storage tested: Samsung 990 Pro, Kingston KC3000

- Current BIOS: 2306

What happened:

The system originally reached BIOS fine on BIOS 1601. I updated BIOS, then started getting no display and the motherboard debug/Q-LED stuck on red CPU LED. I used ASUS BIOS FlashBack from the rear I/O.

At first, one USB stick seemed problematic: FlashBack LED went solid green / did not behave correctly. I changed USB stick, formatted FAT32, used BIOSRenamer, and flashed again. FlashBack then behaved correctly and took longer.

After that, the board successfully reached BIOS on BIOS 2306 with one DIMM in A2. BIOS detected:

- Ryzen 9 9950X3D

- 1 × 48 GB Kingston DIMM in A2

- DDR5 running at 5200 MHz

- CPU temp looked normal, around 35°C

- AEMP disabled

I loaded optimized defaults and saved. It returned to BIOS successfully with one DIMM. Then I installed the second DIMM and it also reached BIOS. So at that point the board/CPU/RAM seemed alive.

Then the issue came back after M.2 work:

I installed M.2 drives. The Kingston KC3000 seemed physically awkward/thick in one slot, so I moved it to another slot and installed a Samsung 990 Pro in the original slot. After this, the system again got stuck on the red CPU Q-LED and would not reach BIOS.

I then removed the KC3000. Still red CPU Q-LED.

Removed all M.2 drives. Still red CPU Q-LED.

No GPU installed. Still red.

Tried one RAM stick in A2. Still red.

Tried the other RAM stick in A2. Still red.

Tried one stick in B2. Still red.

Reseated/checked 24-pin ATX and both CPU EPS/P8 cables. PSU manual shows CPU1/CPU2 P4/P8 should be on the two P8 connectors, and those go to the two top-left CPU power connectors on the motherboard. Cabling appears correct and the system had previously reached BIOS with the same power cabling.

Tried full power drain, Clear CMOS, and reflashing BIOS 2306 again with one DIMM and no M.2 drives. Still red.

Important diagnostic:

With no RAM installed at all, the board stays on yellow/DRAM LED when powered on. So the board/CPU seem to initialize far enough to detect missing memory.

With RAM installed, it goes back to red CPU Q-LED / no BIOS.

That makes me suspect CPU/socket/memory-channel contact rather than a dead PSU or GPU/storage issue.

Physical inspection:

I removed the cooler and CPU. The AM5 motherboard socket looks mostly uniform to me; I do not immediately see obviously bent pins, but I know tiny AM5 socket damage can be hard to see.

The CPU underside has a few small dark dots/marks near the lower-right pad area. I tried cleaning gently with isopropyl alcohol and they did not come off. I am not sure if these are harmless contact marks, damaged/burned pads, or something else.

I have photos of:

- CPU pad side showing the dark marks

- AM5 socket

- Board setup/debug LEDs

Question:

Based on the behavior:

- No RAM = yellow DRAM LED

- Any RAM in A2/B2 = red CPU Q-LED

- CPU/board previously reached BIOS and detected the 9950X3D correctly

- Problem returned after physical M.2 installation work

- CPU pads have small dark marks that do not clean off

- Socket looks visually okay to me

Would you suspect:

1. CPU pad/contact damage?

2. Motherboard AM5 socket issue even if pins look okay?

3. Motherboard memory-channel issue?

4. Cooler/socket pressure/contact issue?

5. Something else?

Trying to decide whether this is more likely CPU RMA or motherboard RMA. Any opinions from people with AM5 socket/contact or ECC UDIMM experience would be appreciated.

Hi all,

I have just purchased the OBSBOT Tiny 3 Streaming Combo package a few days back.

Today i got email about firmware update for both the camera and the mic.

I'm aware the linux is not fully supported (seen many videos people get everything to work more or less using OBS etc). I'm just wondering if there is a secret way to update the firmware in linux?

I can use my wife's windows laptop to update but just wanted to ask the community if there is a native linux way of doing this?

Personally i moved fully to linux since now CachyOS let me play all my games using Steam and KDE is mature enough to work even much better then windows. For me there is no going back :)

I just love CachyOS. It works so fast and now i feel i won my pc :) no spyware, forced popup update and update that break the computer hehe

Hi guys,

I thought i share what i found so far to be the best alternative for my new proxmox server.

I looked at sooo many motherboards like ASUS Pro WS B850M-ACE SE which has both ECC and IPMI support but lacks 4x m2 and more modern usb-c port support. AND i started with micro-ATX and a more compact case like Jonsbo Z20 but reallzied if i want more m2 and a more long term server i need to move to ATX. So i landed on this setup:

Part	Selected

Case	Fractal Meshify 3

Motherboard	ASUS ProArt X870E-Creator WiFi

CPU	AMD Ryzen 9 9950X3D

PSU	be quiet! Dark Power 14 1200W

RAM direction	Kingston KSM56E46BD8KM-48HM 48GB (1x48GB) 5600 MT/s CL46 ECC 1.1V

Cooler direction	Noctua NH-D15 G2 chromax.black

GPU direction	ASUS Dual RTX 5060 Ti 16GB

This motherboard is among the few that has true ECC and more lanes then the more expansive cards from asus. Plus dual LAN ports.

Many components are overkill but i got decent price and the lower alternative was not that much cheaper so this will work both as "gaming" and proxmox server i guess.

SteamOS + emulation can take advantage of the GPU and the nice CPU :D

Your thoughts?

Hi!

I’m honestly exhausted from reporting this bug to Proton Mail support.

I’ve had this issue for maybe two years+, and it still happens: when I search messages from a sender and select Inbox as the search location, Proton Mail still returns results from other places like Archive, Trash/Deleted, and possibly other folders.

In the screenshot, I searched for noreply@steampowered.com, selected Inbox, but the results are clearly mixed. Some messages are not actually in the Inbox.

This matters because when I fall behind on email, I often want to filter mail from one sender and process only the items that are still sitting in my Inbox. That is the whole point of selecting Inbox as the scope. I do not want archived or deleted messages mixed into that view.

The expected behavior should be simple:

When Inbox is selected, show only messages currently in the Inbox.

The actual behavior:

Inbox is selected, but search still returns messages from other folders.

I would also really like the option to combine this with Unread, but that does not seem to be available in this search flow either. So having the Inbox filter work correctly becomes even more important.

I’ve sent Proton Mail multiple bug reports about this, but nothing seems to change. This feels like a basic and important email workflow, not some edge case.

Is anyone else seeing the same problem? Maybe if enough users report it publicly, Proton will finally prioritize fixing it.

https://preview.redd.it/c969u7fjvm7h1.png?width=943&format=png&auto=webp&s=9e4edbdfd15187ba2fbc1e6a93965f72e67928c2

Hi,

I recently ran into a fairly painful edge case while using Hermes Agent with Mnemosyne as the memory provider, and I wanted to document it in case it helps other users or maintainers.

Short version: updating Hermes can rebuild/clear the Hermes Python venv, and if Mnemosyne is installed as an external in-venv memory provider, the provider can become unavailable even though Hermes config still says the memory provider is mnemosyne. In our case, there was also a provider alias mismatch: Mnemosyne’s installer created a plugin path named hermes-mnemosyne, while Hermes’ configured provider lookup for memory.provider: mnemosyne expected an exact plugin path named mnemosyne.

That combination means an end user can update Hermes, restart, and suddenly their configured memory provider may not load. The user then has to know enough about Hermes’ venv, plugin paths, provider loading, systemd/gateway lifecycle, and Mnemosyne’s installer behavior to repair it safely.

What broke / why it was fragile

The core issues were:

• Hermes update can rebuild the active venv.
• Mnemosyne lived as an additional package/provider inside that venv.
• There did not appear to be a built-in declarative mechanism for Hermes to remember and reinstall this external provider dependency after a venv rebuild.
• Hermes config could still say memory.provider: mnemosyne, but the actual import/plugin could be missing.
• Mnemosyne’s installer created plugins/hermes-mnemosyne.
• Hermes’ configured provider lookup expected plugins/mnemosyne for provider name mnemosyne.
• Running Hermes gateway/dashboard processes may already have imported state before a repair, so package repair and process reload need to be treated as separate safety steps.

What we built locally to make it reliable

We ended up creating a local Mnemosyne lifecycle layer around Hermes:

• A pinned lifecycle config with known-good versions:
  • mnemosyne-memory==3.3.0
  • sqlite-vec==0.1.9
  • fastembed==0.8.0
• A read-only health check script for the active Hermes venv/provider state.
• A zero-restart repair path that:
  • checks whether the provider is definitely broken;
  • reinstalls the pinned package set into the active Hermes venv only when needed;
  • runs the Mnemosyne installer;
  • guarantees the exact provider alias Hermes expects: plugins/mnemosyne;
  • verifies the provider can actually be loaded afterward;
  • does not mutate memory content;
  • does not run sleep/consolidation;
  • does not query/edit SQLite directly.
• An explicit-version-only upgrade helper, so there is no “auto-upgrade to latest” behavior.
• A separate opt-in repair-and-reload mode for the gateway, gated very conservatively:
  • only acts on definitely broken states;
  • fails closed on uncertain/check-error states;
  • repairs first;
  • verifies healthy;
  • restarts only hermes-gateway.service;
  • verifies the gateway is active;
  • re-checks provider health after restart;
  • never restarts the dashboard.
• A best-effort systemd gateway pre-start guard using the zero-restart repair path.
• A daily heartbeat/backstop using the gated repair-and-reload path.
• Sandbox tests and a controlled alias-break proof to make sure the repair path fixed the exact failure without touching memory content.

This works locally, but it is a lot of custom lifecycle machinery for something an end user should not have to understand.

What I think Hermes should ideally handle

From the Hermes side, a robust solution would probably include:

1. Declarative external provider dependencies
   • If a user configures memory.provider: mnemosyne, Hermes should know which package(s), versions, and plugin paths are required.
   • Those dependencies should survive hermes update / venv rebuilds.
2. Post-update provider validation
   • After an update, Hermes should check whether the configured memory provider still imports and loads.
   • If not, it should either repair automatically from a trusted declarative source or print a very clear recovery command.
3. Provider/plugin name mapping
   • Hermes should not rely only on fragile exact directory names unless the provider contract guarantees them.
   • There should be metadata or an entrypoint saying: “this installed plugin satisfies provider name mnemosyne.”
4. Safe update hooks
   • Something like pre-update/post-update hooks for plugins/providers would help.
   • The update flow could say: “venv was rebuilt, reinstalling configured memory provider dependencies.”
5. Clear status output
   • hermes memory status or equivalent should distinguish:
     • configured provider;
     • installed package;
     • plugin path present;
     • provider import works;
     • provider load works;
     • running gateway may need restart.
6. Process reload guidance
   • Repairing packages in the venv is not the same as making already-running gateway/dashboard processes import them.
   • Hermes could expose a safe “repair provider, then reload affected processes” workflow.

What I think Mnemosyne should ideally handle

From the Mnemosyne side, the installer/provider package could make this easier by:

1. Creating the provider alias Hermes expects
   • If Hermes config uses memory.provider: mnemosyne, the installer should create or register plugins/mnemosyne, not only plugins/hermes-mnemosyne, unless Hermes has a proper alias/metadata system.
2. Providing a stable health-check/repair command
   • A command that can say:
     • package installed;
     • provider import works;
     • Hermes plugin path exists;
     • provider load works from Hermes’ perspective;
     • no memory mutation performed.
3. Documenting companion dependency pins
   • Mnemosyne depends on pieces like sqlite-vec and fastembed.
   • The compatible version matrix should be explicit so repair scripts do not have to guess.
4. Being strictly HERMES_HOME aware
   • Installer behavior should be safe for profiles/sandboxes and should not accidentally target the wrong Hermes home.

Shared contract that would solve this properly

The clean fix is probably a small formal contract between Hermes and memory providers:

• Provider package declares:
  • provider name(s);
  • required plugin alias;
  • install/repair entrypoint;
  • health-check entrypoint;
  • dependency pins or compatibility ranges.
• Hermes update process:
  • rebuilds venv;
  • reinstalls configured provider dependencies;
  • runs provider install/registration;
  • validates provider load;
  • tells the user if a running process needs restart.
• Integration tests cover:
  • venv cleared during update;
  • configured memory provider restored afterward;
  • provider alias missing;
  • provider package installed but plugin path missing;
  • gateway reload after provider repair;
  • failure/uncertain states do not trigger unsafe restart loops.

Why this matters

Persistent memory is one of the main reasons to use an agent like Hermes. If the configured memory provider silently breaks after an update, the user may lose continuity or spend hours debugging low-level environment details.

Our local workaround now makes this reliable for our setup, but the amount of work involved was far beyond what a normal end user should need to do. Ideally, Hermes and Mnemosyne would make the configured memory provider part of the supported lifecycle: update-safe, health-checked, repairable, and clearly reported.

Hi guys,

I just wanted to drop in and say that I really love Hermes. It’s incredibly stable and genuinely helpful. I recently set up my Obsidian vault so it can take notes for me and save my daily sessions, which finally makes the agent feel truly usable and personal.

I'm still trying to set up the Kanban board properly. I love the concept, but as it stands, it’s quite difficult to use due to the existing font and design. All the text is in all-caps, which makes it highly unreadable.

Why is all the text capitalized, and could we get the option to use different fonts? The theme selection is also very limited, and to be honest, most of them make the readability worse. The only one that is somewhat okay is Teal (Large), as it at least makes the menu items look acceptable.

I think if the WebUI was brought up to par with the rest of the product, a lot more people would jump on board. Without a proper UI, it’s just hard to use the system for many tasks in the Kanban view.

I really appreciate all the hard work that goes into this, and I apologize if this sounds like I'm complaining! I just want this awesome tool to get even better and reach a wider audience. I like the TUI and actually use it the most (along with Telegram), but for workflows like Kanban, a solid WebUI is a must-have.

I’ve seen several alternatives like Workbench, but since they are third-party, I don’t want to risk security issues or frequent breakage like I’ve experienced constantly with OpenClaw (which is also very awesome, by the way).

Thanks again for a great tool!

https://preview.redd.it/ja37kajloq0h1.png?width=1415&format=png&auto=webp&s=756d80e19d666577376823af85cede0fa6294b7d