Dependencies and updates
Screph is installed as one product, but different tasks require different runtime components. The Dependencies tab shows their actual state, source and disk use—with no hidden installation or silent fallback.
1. The Dependencies tab
Open the main settings window and select Dependencies. The summary shows how many components are ready, missing, broken or disabled. The table displays the selected and detected global paths, estimated size and possible disk savings.
- Probe again — re-check executables, imports, paths and managed assets.
- Install/repair locally — prepare selected components in the managed ScrephData directory and run a post-install smoke check.
- Remove locally — remove only runtime-owned paths after checking shared install groups.
- Use detected global — switch only components whose global probe succeeded.
2. Components being checked
| ID | Purpose | Needed when |
|---|
python.automation | Managed Python 3.12 | generated Python workflows are executed. |
script.runtime | Automation script environment | Automation Runtime is used. |
cv.runtime | OpenCV/CV | classic CV operations and screen matching are needed. |
ocr.runtime | Tesseract OCR | text is read or detected. |
video.runtime | FFmpeg | supported video operations and frame-accurate cuts are needed. |
voice.local | Vosk/PyAudio | local speech recognition is selected. |
ml.runtime | PyTorch/vision/transformers | YOLO, SAM, OmniParser or other model-backed methods are used. |
codegen.runtime | Codegen/OpenHands | Screph Code is used. |
Model weights and the runtime itself are separate. A successful ml.runtime probe does not guarantee that particular YOLO/SAM/OmniParser weights are already downloaded and compatible with the selected method. Storage, active selection and SHA status are covered in CV models and local weights.
3. Runtime sources
local — a managed installation under ScrephData; the default and most reproducible option.global — an existing system installation after a successful probe.custom — an explicit path selected in advanced mode.install_global — an advanced policy option, but not yet a working system-install command. The current installer builds install targets only for local; this source probes an existing global runtime just like global. Do not select it expecting installation into PATH or a system directory.skip — do not install or use the component; its related capability remains unavailable.
If the selected source is missing or broken, Screph reports a component error. It does not silently borrow another Python, Tesseract or provider from PATH. Install/repair locally skips all non-local sources; with install_global it reports that no local dependencies are selected.
4. ML runtime and signed pack
ml.runtime is the largest block. It includes separate packages: PyTorch, TorchVision, Ultralytics, timm, Transformers and Hugging Face Hub. You can disable the block or unneeded root packages; the installer verifies dependency closure for the selected subset.
Network installation uses a publication manifest and a signed archive. Before extraction, Screph validates component/channel, URLs and sidecars, SHA256, the detached CMS/PKCS#7 signature, trusted chain or pinned signer thumbprint, lock and SBOM. An offline pack can be selected from disk and passes the same payload validation.
Two ML layers in the wizard. The QtIFW com.screph.boteye.runtime.ml component is an optional application payload and is not selected by default. The dependency page reads that initial choice and enables a separate managed ml.runtime workflow under ScrephData: its default policy offers a verified network download of about 334 MB and warns about up to 6.5 GB installed, or accepts a local pack. The two layers work together for the selected ML workflow; Classic CV remains available without them.
Publication preflight downloads only the small manifest. The large archive is downloaded by a separate action; a cancelled or failed download does not become the active runtime pack.
5. Updating the product
Application updates and runtime-dependency installation are related but separate processes. Screph checks its Qt Installer Framework repository and can offer updates for individual product components, including the main UI and Pro Agent. The existing installation's maintenance tool performs the update.
What runs automatically. In an installed build with an available maintenance tool, Automatically check for updates on startup is enabled by default. The first check is scheduled about four seconds after launch and then limited to a 24-hour interval. Only Updates.xml (up to 5 MB) is fetched from the configured repository; its User-Agent contains Screph/<version> update-check. Projects, frames and settings are not sent. Disable the toggle in General settings.
A failure also starts the interval. The current startup controller records last_auto_check_at before interpreting the result: a successful check, network failure and malformed XML all defer the next automatic attempt for the configured interval (24 hours by default). Toggling the checkbox off and on does not reset this timestamp. Open update manager starts controlled shutdown and the separate maintenance tool; it does not repeat the lightweight check inside the running Screph process.
The current Alpha channel needs verification. Source metadata says channel=dev, while the configured repository URL and website publisher use the stable path; the fresh local repository was built under .build/updates/windows/dev. This mismatch does not alter the installed product by itself, but a compatible automatic update for the current artifact cannot be treated as verified until channel/URL are aligned and the release publication checklist passes. Version, channel and repository fields in Settings remain read-only diagnostics.
- Save the current project and unfinished changes in Screph Code.
- Stop recording and verify that settings were saved.
- Confirm the update. Screph attempts to safely close Selector and the separate Pro Agent process.
- Complete the update in the maintenance tool, then probe dependencies again.
After successful preparation, Screph schedules the separate maintenance tool about two seconds later and exits the main process. Screph does not add an explicit runas to this launch; Windows or the installer may request elevation depending on the directory and operation. If an active window, recording or unsaved state cannot be closed safely, the update stops with a clear message.
Complete Windows/UAC update boundary →
6. Refreshing embedded help
This is separate from QtIFW and the product-update toggle. An installed build already includes a bundled snapshot of six core HTML pages, so that part of the help remains available offline. When gui.docs is available, about 1.2 seconds after startup Screph may request a fresh set from screph.com/documentation/. The local cache is replaced only after all six pages succeed; on failure, the previous valid set remains. Requests use the ScrephDocs/1.0 User-Agent and contain no project, frames, settings or account data.
The current implementation has no separate toggle and its guard allows another attempt one hour after the previous one. It is therefore not covered by the app update check's 24-hour limit. A remote set is applied only when every page declares a cache version at least as new as the local one; an unmarked or older deployment cannot downgrade the bundled snapshot. Links from embedded help to guides outside the local set open the complete website and require network access.
7. Reading failures
- Missing: the selected source lacks a required executable, import or asset.
- Broken: the path exists but probe or smoke failed; use repair or select another explicit source.
- Skipped: the component was disabled by user policy; this is not an installation error.
- Pack downloaded, not selected: the archive is in managed cache but is not yet selected as the active offline pack.
