Conversation
… and collection IDs
…on project creation
…l device data - picamera2_backend: add reset_camera() to evict broken cache entries, add apply_controls() for live parameter updates without full capture - service: capture_preview_frame() retries once after reset_camera() on any backend error (fixes intermittent preview disconnect bug) - cameras API: extend DeviceInfo with lens_position, awb_gains, has_aperture_control; add collection_id to CaptureRequest and DualCaptureRequest; populate calibration data from registry in /devices; pass collection_id when creating new Record rows
- Add GET/POST /cameras/focus/{camera_index} endpoints (FocusRequest/FocusResponse)
- Add get_focus() and set_focus() to capture/service.py
- set_focus() clamps to 0–10 dioptres, switches to manual AF mode (AfMode=0)
- get_focus() reads LensPosition from Picamera2 metadata
- Depends on apply_controls() from Phase 1 backend work
Records have a check constraint that prevents both project_id and collection_id being set simultaneously. The capture endpoints were looking up the project by name and setting project_id even when collection_id was also provided, causing every capture from the live-preview page to fail silently. Fix: use project_id only when no collection_id is present; when a collection is provided, its project association is implicit.
Images captured within a collection are now saved to: PROJECTS_ROOT/<project_name>/<collection_name>/images/main/ Previously all images for a project shared the same PROJECTS_ROOT/<project_name>/images/main/ directory, making it impossible to distinguish which collection each image belonged to at the filesystem level. - capture_image(), single_capture_image(), dual_capture_image() in service.py accept a new optional collection_name parameter; when set the path includes the sanitized collection name as a subdir - Both capture API endpoints now look up the collection name from the DB and pass it down when collection_id is provided - project_init() no longer pre-creates images/main|temp|trash dirs; capture_image() already creates these on demand per collection
Previously only the DB row was removed, leaving the image tree on disk. - delete_project(): after commit, removes PROJECTS_ROOT/<name>/ with shutil.rmtree; tries both the raw project name and the sanitized (secure_project_filename) variant to handle historic inconsistencies - delete_collection(): same approach for the collection subdirectory under its parent project (project/collection/) - Errors during rmtree are logged as warnings and do not fail the HTTP response (DB deletion already succeeded)
… and update paths in capture_service
Previously capture_preview_frame() used tempfile.mkstemp() to create a
new uniquely-named file per poll cycle. When the process was killed
(e.g. systemd restart) the finally-block cleanup was skipped, leaving
files behind. With an operator polling every few seconds this produced
hundreds of stale preview_c*.jpg files in /tmp.
Changes:
- Use a fixed per-camera path /tmp/dtk_preview_c{n}.jpg instead of
mkstemp; overwrites the same file on every poll cycle so at most one
file per camera ever exists
- Add a threading.Lock per camera so concurrent polling requests from
multiple browser tabs serialise writes to the shared path
- Simplify the retry loop (no need to re-create the temp file)
- Add flush_preview_tmp() to delete any dtk_preview_c*.jpg files that
survived a crash
- Add DELETE /cameras/preview/tmp endpoint so an admin/operator can
trigger the flush from the settings page
…via stdlib The module-level Picamera2.set_logging(Picamera2.BEBUG, ...) calls caused two separate problems: 1. 'BEBUG' is a typo for 'DEBUG' — AttributeError on import, making all camera detection fail 2. set_logging() is deprecated in this picamera2 version; the 'output' kwarg expects a stream, not a file path, causing a non-fatal AttributeError on every import even after fixing the typo Fix: remove set_logging() from calibration.py and camera_registry.py entirely. Instead, attach the existing RotatingFileHandler from subprocess_logger to the 'picamera2' stdlib logger in service.py. This routes picamera2's internal debug output into the same capture_service.log without using the deprecated API.
… hang
When the frontend live-preview polls capture_image() at ~80fps while a
full capture is also calling capture_image() on the same Picamera2
instance, picamera2's internal job queue enters an infinite spin loop
('Execute job' repeating endlessly) because two callers are racing on
capture_request() without any mutual exclusion.
Fix: add a threading.Lock per camera index in Picamera2Backend.
capture_image() now acquires this lock before touching the Picamera2
instance. Preview polling and full captures are serialised per camera:
- an in-flight full capture (AF + denoise warmup + save) blocks
subsequent preview frames until it finishes
- a running preview frame blocks a capture trigger until that frame
completes (~50ms), then the capture proceeds cleanly
Implementation:
- Add self._camera_locks dict + self._locks_mutex in __init__
- Add _get_camera_lock(camera_index) helper
- Split capture_image() into a public thin wrapper (acquires lock) and
_capture_image_locked() (the former implementation)
setup_rotating_logger() checks whether a RotatingFileHandler for the same file path is already attached before adding a new one. Without this guard, uvicorn's auto-reloader reimports service.py while the logger singleton (global, cached by name) still has its existing handler, resulting in every log line being written twice.
…s management endpoints
Enhance project management and live preview functionality
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This pull request introduces several significant enhancements and new features across the authentication, camera control, and database schema layers of the application. The most important changes include the addition of system logging, new endpoints and controls for camera devices, and several database migrations to support new features like project membership, extended project metadata, and improved record tracking.
Authentication and System Logging:
/setup/statusendpoint to detect whether the system requires initial setup (i.e., no users exist yet), and updated the registration logic to restrict new user creation to admins after the first user is registered.Camera API Enhancements:
collection_id, ensuring images are stored in the correct project/collection directory.Database Schema Migrations:
System and Access Logging:
system_logstable to store logs of system events, supporting structured auditing of actions such as user creation and authentication events. [1] [2]Project and Membership Management:
project_memberstable to manage user membership and roles within projects, supporting collaborative workflows.Project Metadata:
fondo,serie,signatura) to theprojectstable to support richer archival metadata.Record Management:
recordstable withstatus,sequence, andrejection_notecolumns to better track record state and ordering.Summary of Most Important Changes:
Authentication & System Logging
/setup/statusendpoint to detect if system needs initial user setup.Camera API Enhancements
collection_id. [1] [2] [3]Database Migrations
system_logstable for structured event logging. [1] [2]project_memberstable for project membership and roles.projectswithfondo,serie, andsignaturametadata fields.status,sequence, andrejection_notefields torecordstable.