run_coroutine_threadsafe is designed for scheduling coroutines from a
different thread onto the event loop. Since readLoop is already running
as an async function on the event loop, using create_task is the correct
and more efficient approach.
This removes unnecessary thread-safe queue overhead for every RPC message.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
* replace tool to use `ffmpeg` and bump v0.0.8
* format code
* wip
* wip: update components
* wip: remove websocket for cameras since they are not supported
* wip: allow changing between different login methods
It will prefer logging in with `Tuya (Smart Life) App` if there was no previous `userId`. Else, it will fall back to `Tuya Developer Account`.
* wip: fetch rtsp from Tuya Sharing SDK
* wip
* feat: add support for light accessory in camera
* fix: resolve indicator not updating
* wip: prevent setting motion if device has no motion detection
* improve mqtt reconnect, also update status
* bump version
* update commit
* bump to beta 3
* quick fix
* changelog
* fixchangelog
* bump version
* fix: resolve mqtt connection issues
* chore: bump version
* fix: use correct property for checking connection state
* chore: update changelog
* chore: bump version
* fix: ensure timeout is actually correct and bound corretly
* chore: update changelog
* bump version
* fix: fix setTimeout undefined function
* chore: update changelog
* fix: fix issue with camera not found
---------
Co-authored-by: ErrorErrorError <16653389+ErrorErrorError@users.noreply.github.com>
Co-authored-by: Erik Bautista Santibanez <erikbautista15@gmail.com>
Some Dahua/Amcrest NVRs (e.g., AMDV7208M) respond with HTTP/1.0 instead of
HTTP/1.1. The event listener was only checking for 'HTTP/1.1 200 OK',
causing it to throw 'expected boundary' errors and crash when receiving
HTTP/1.0 responses.
This fix adds support for both HTTP versions.
Fixes motion detection not working on older Dahua OEM NVRs.
Scrypted could restart the OpenVINO plugin on startup in offline/firewalled setups because CLIPProcessor.from_pretrained("openai/clip-vit-base-patch32") triggers HuggingFace Hub network checks/retries that exceed the plugin startup watchdog.
Update predict/clip.py to:
- Load the CLIP processor from the local HF cache first (local_files_only=True) so startup is fast/offline-safe.
- Refresh the processor cache online asynchronously in a background thread (asyncio.to_thread) so update checks don’t block startup.
- Add simple log prints to indicate cache load vs refresh success/failure.
