Help paths for evaluation, setup, and troubleshooting.
Start with compatibility, FAQ answers, ScopeDock 1.1.1 architecture selection, RTSP guidance, or contact depending on where you are in the workflow.
Help should feel operational, not buried.
Compatibility, FAQ, guides, and feedback now sit together as one product support path.
Support is part of the product experience
Support is where you should confirm the next move when product and download pages do not fully answer your question. In most cases, the fastest path is compatibility first, FAQ second, blog guides third, and contact last.
Use contact when the documented path does not match your actual device behavior, when a camera source is not detected, when RTSP or ONVIF setup fails after the basic checks, or when you need to describe a workflow that is not covered yet. Support is intentionally easy to reach because people need confidence and direction before and after download, not just promotion.
Support content should stay close to the physical camera, cable, protocol, and local file workflow.
Support should connect the setup question to the real device on the desk.
A more concrete support visual helps readers understand that compatibility, permissions, RTSP setup, and file handling are operational questions.
Start with the device path
USB, RTSP, and ONVIF questions are easier to answer when users can map the exact source type before sending feedback.
Separate help from analytics
Structured feedback belongs in the support flow. Anonymous analytics remains separate and does not store support messages.
Support in four quick answers
These blocks help you choose the right next step without guessing.
Start here if
You need to confirm fit, solve setup issues, or understand product boundaries.
Support is treated as a core page, not a footer-only afterthought.
Fastest help path
Check compatibility, then scan the FAQ, then read a guide if needed.
The page now mirrors how real users evaluate and troubleshoot ScopeDock.
Feedback boundary
Contact and support messages are handled separately from basic site activity measurement.
This keeps product feedback and support requests clear and easy to follow up.
Current language scope
English first, with localized support-ready structure reserved for later.
The support architecture is already prepared for future high-value translations.
Choose the fastest help path
Start with the quickest help path first, then move into contact when you need a reply or device-specific compatibility review.
Compatibility and known limits
Confirm platform support, Apple Silicon and Intel direct-download paths, the unchanged App Store path, protocols, storage assumptions, and current limits before deeper debugging.
FAQ for ScopeDock basics
Get direct answers to common questions about uploads, supported cameras, RTSP, source count, and file locations.
Guides and onboarding posts
Use the blog for setup walkthroughs, workflow explanations, and product updates that may answer edge questions faster.
USB camera does not open
Start here when a USB microscope, endoscope, otoscope-style camera, or inspection camera does not appear or the preview stays blank.
RTSP URL, auth, or timeout issue
Start here when a stream URL fails, credentials are rejected, the network path is unclear, or the connection times out.
Contact and feedback
Send bug reports, feature requests, compatibility questions, or business inquiries through the contact form after you have checked the matching setup path. Include source type and symptoms, not private credentials.
Start here before writing in
The best support page helps users choose the right help lane first, then escalate cleanly when needed.
Step 1
Re-check compatibility
Confirm platform scope, protocol coverage, and known limits before assuming the product should match every camera path.
Step 2
Identify the source type
Decide whether you are troubleshooting USB UVC, RTSP preview or recording, ONVIF discovery, or local file and capture behavior.
Step 3
Review permissions and storage
Camera permissions, local storage, and network reachability are common root causes in early evaluation workflows.
Step 4
Choose the feedback type before sending
Use compatibility issue for device detection or protocol behavior, setup issue for permission or first-preview blockers, and feature request when the current workflow works but needs a new capability.
Step 5
Escalate with context
If the guides do not resolve the issue, use Contact and include camera type, protocol, Mac model or chip, macOS version, ScopeDock version, expected behavior, and actual behavior. Do not send passwords, private LAN details, or full RTSP URLs.
Support priorities
This page focuses on fast orientation, next steps, and the most common setup questions.
Clear troubleshooting entry points
Users should quickly know whether to re-check compatibility, read a guide, or send feedback.
Privacy boundary stays clear
Contact and support messages stay separate from basic site usage measurement.
Multi-language ready structure
English support is available now, with room to add high-value translated help pages later.
Common troubleshooting lanes
Use the lane that matches the failure first. If the documented path still does not match your device, send compatibility feedback with symptoms and source type, not private credentials.
USB camera does not open
Confirm the device is attached directly or through a reliable adapter, appears to macOS as a USB UVC camera, and is not locked by another app. If the vendor requires a private driver-only app, ScopeDock compatibility may be limited.
Camera permission blocks preview
Check macOS camera permission for ScopeDock, then quit and reopen the app before testing one source again. Permission problems are setup issues, not proof that every similar device is unsupported.
RTSP URL, authentication, or timeout fails
Confirm the full RTSP URL format, username and password if required, local network reachability from the Mac, and whether the device actually exposes a standard RTSP stream. Do not send full private URLs or passwords in feedback.
ONVIF discovery does not find the camera
ONVIF discovery depends on device support and local network visibility. If discovery fails, manual RTSP can still be the correct path when you already know the stream URL.
Snapshots, recordings, or local files feel unclear
Check local storage assumptions, file handling expectations, and whether the workflow needs more product guidance rather than protocol debugging.
Platform expectation mismatch
Confirm whether the question is really about current platform availability, especially if you need Windows or Linux.
Compatibility feedback
Send feedback when a USB microscope, endoscope, RTSP camera, or ONVIF device behaves differently from the documented path after these checks. Include source type, Mac model or chip, macOS version, ScopeDock version, expected behavior, and actual behavior; remove private credentials and internal addresses.
Feature request
Use Contact when the current path works but you need a different capture, layout, onboarding, or device workflow. Keep it separate from bug reports so follow-up stays clearer.
Use the real product UI in support
These screenshots make the support page feel more operational by showing the real setup, history, and network-source surfaces.
Capture and history screenshot
This support screenshot gives file, recording, and history questions a real product anchor instead of a temporary mock.
RTSP and ONVIF troubleshooting screenshot
This screen helps the support page explain network-camera setup and troubleshooting with the real interface.
Source setup screenshot
This setup view makes support content more practical by showing how devices and sources actually get added.
Guides that solve common setup questions
These posts should sit close to support because they answer the most common evaluation and onboarding questions.
ScopeDock 1.1.1 adds Apple Silicon and Intel direct downloads
ScopeDock 1.1.1 provides separate direct-download builds for Apple Silicon and Intel Macs while keeping the 1.1 series RTSP preview, snapshot, and recording improvements.
How ONVIF discovery differs from manual RTSP in ScopeDock
ONVIF discovery and manual RTSP solve different setup problems. ONVIF can make camera onboarding lighter, while RTSP is the direct path when you already know the stream endpoint.
How to troubleshoot camera permissions on macOS for ScopeDock
If a camera is not showing up in ScopeDock on macOS, the first checks are usually permissions, source type, and whether the device behaves like a standard local camera path.
ScopeDock essentials
Support starts by clearing up the most common questions before users have to write in.
Does ScopeDock upload my video by default?
No default cloud upload flow is part of the product positioning. ScopeDock is presented as a local-first tool. It does not automatically upload videos, images, full RTSP URLs, LAN IP addresses, or media paths, and the website keeps feedback separate from anonymous usage measurement.
What cameras are supported?
The current site explains support around USB UVC devices, improved RTSP manual input, and ONVIF discovery workflows. Exact compatibility can still vary by device implementation, especially for network cameras.
Does ScopeDock support RTSP?
Yes. ScopeDock 1.1.1 continues to include the 1.1 series RTSP preview and recording improvements, including continuous video stream preview, preview resolution and frame rate choices after connection, improved RTSP recording save behavior, better thumbnails, and clearer connection, authentication, and timeout error messages. Network camera compatibility can still vary by device implementation.
How many sources can I connect at once?
The website currently describes ScopeDock as supporting up to four sources in a lightweight multi-source layout. That limit is part of keeping the product focused on practical inspection work rather than dense surveillance-style grids.
Is ScopeDock available on Windows?
Not yet. ScopeDock is currently available on macOS, and Windows availability will be published when it is ready.
Still blocked?
Tell us what camera, protocol, Mac architecture, or workflow you are trying to use. Remove passwords, full private RTSP URLs, LAN IP addresses, and sensitive media paths before sending.