Bike-fit camera not working? Permissions, preview and capture checks
Find the stage before changing settings: recover site camera permission in iPhone Safari or desktop Chrome, distinguish a missing preview from a local-model problem, and understand why usable video can still produce no accepted recording.
Published 25 October 2026 · OpenBikeFit
Find where it stopped.
- Site access
- Context + permission
- A permission choice is not a working picture.
- Camera stream
- Source + preview
- A picture is not proof that the model ran.
- Local model
- On-device processing
- A loaded model is not an accepted take.
- Capture evidence
- Current usable samples
- A technical pass is not a physical fit verdict.
A stage map, not live progress, an automatic test or an accuracy ladder. Nothing is requested, recorded or diagnosed by this diagram.
On this page
- 01Start with the message and the stage
- 02Open the intended HTTPS page
- 03Camera permission is blocked in iPhone Safari
- 04Check this site in desktop Chrome
- 05No camera found does not always mean absent hardware
- 06A camera-in-use message is not a diagnosis
- 07When the preview stays black or the test waits
- 08A picture can work while the local model cannot
- 09A ready preflight is not an accepted recording
- 10Why sparse sampling pauses pedal-cycle assessment
- 11When a stream or its dimensions change
- 12Before reloading, keep saved and unsaved work separate
- 13Make one bounded retry or take a no-camera route
- 14What to report if the problem remains
Only when you choose to test
Open the free device check
The existing readiness tool has its own deliberate camera action and access requirements. This reading link grants no permission and transfers no measurements or identifiers.
Open toolWhen a bike-fit camera does not open, start with what the page actually says. “Camera permission is blocked” and “No usable camera was found” are different observations. A visible preview followed by a processing failure is different again. Buying another phone, repeatedly pressing the same button or changing bicycle components does not identify which part of that chain failed.
This guide describes the current free OpenBikeFit camera tools. It is a recovery reader, not a device diagnostic service or a guarantee that a particular phone will work. Reading requests no camera permission, starts no test and creates no fit. Keep the failed page open while you find its message. The links from its help panels open this separate reader without passing measurements, record identifiers or the parent address fragment.
Start with the message and the stage
There are four useful stages: site access, camera stream, local model and capture evidence. Site access concerns the browser context and permission. The stream is the actual source and preview. The local model must load and run on the device. Capture then needs sufficiently usable observations under the recording protocol. A later stage cannot repair an earlier failure, and passing an earlier stage does not promise that every later stage will pass.
Use the message ledger below as a reading aid. Some browser exceptions share one friendly app label, so a row names a sensible next check rather than announcing a proven cause. Match the full message and the tool: the readiness test and Capture Director do not use identical wording. Do not substitute a remembered message from a different attempt. If the current screen says nothing specific, leave the cause unresolved instead of calling it permission denial or missing hardware.
Match the current message. These are reading branches, not automatic device diagnoses.
- Site accessCamera permission is blockedIn another camera workflow: Camera blocked
Access was refused or restricted. This is not proof that the device has no camera.
Read the per-site permission check →- Camera streamNo usable camera was foundIn another camera workflow: No camera found
No usable matching source was obtained. The grouped label does not distinguish absent hardware from unmet conditions.
Check the intended source and matching conditions →- Camera streamThe camera is busyIn another camera workflow: Camera in use
Opening the source failed. Another camera application is one possibility, not a proved cause.
Read the bounded source-access check →- Unresolved stageThe camera test could not finishIn another camera workflow: Couldn't start the camera
The generic message does not identify whether camera access, preview or local processing failed.
Identify the last visible status without guessing →- Local modelOn-device model blocked
The processing runtime did not start. A visible picture is not proof of a working pose model.
Read the local-processing boundary →- Preflight issuesThe camera works — improve the setup first
Camera access can work while other listed checks need attention. This is not an accepted recording.
Separate the device check from capture quality →- Capture evidenceCamera sampling too sparse
Pedal-cycle assessment is paused. Nominal camera fps does not replace observed samples.
Read observed timing and the fictional example →- Camera streamCamera stream stopped
This attempt stopped without handing a clip forward. An earlier completed clip is a separate record.
Check the source before a fresh attempt →- Capture evidenceCapture timing unavailable
The finishing attempt did not provide acceptable sample timing and handed no clip to analysis.
Keep the failed interval separate →- Capture evidenceVideo dimensions unavailable
The finishing attempt did not provide usable decoded dimensions. A nominal default is not a measured frame.
Wait for a usable source before starting again →
Open the intended HTTPS page
Check that the address is the actual OpenBikeFit website over HTTPS. If you opened an embedded page inside another service, open the intended tool directly in the browser instead of asking the surrounding page for broader access. Browser camera APIs depend on a secure, permitted context; an embedded frame can have a separate restriction. A page that never reaches a camera prompt is not, by itself, evidence that the camera is absent.
Never bypass a certificate warning to obtain a preview. Do not switch to an unsecured copy, turn off browser protections or install a permission-unlocking extension. If a managed browser or device policy prevents camera use, ask the responsible administrator about that policy. This guide cannot override it. The public fictional analysis and blank worksheet remain reading alternatives, not hidden routes around camera or interactive-tool acceptance.
Camera permission is blocked in iPhone Safari
On the OpenBikeFit page in Safari, open the Page Menu beside the address. Find Website Settings; some versions place it behind More. Check the camera choice for this website and choose Ask, or Allow if that is your deliberate preference. Return to the page, reload when you are ready, start the test yourself and respond to any camera prompt. The exact menu layout and translated labels can vary with the installed iOS release.
Make this a site-specific decision. You do not need to allow camera access for every website, and microphone access is not required by this workflow. You can keep the camera denied and read the public example instead. Changing a setting is not a test result: confirm what the next explicit attempt actually reports. If denial remains, do not keep tapping in the hope that the page can overrule Safari. The browser or device may still have another restriction that this screen cannot identify.
Check this site in desktop Chrome
Desktop Chrome has separate camera site exceptions and operating-system access. In Chrome settings, find Privacy and security, then Site settings and Camera. Review the entry for the intended site rather than changing the default for every website. If Chrome presents an operating-system permission instruction, follow the appropriate system setting for your computer. A work or school administrator may control these choices; the page cannot grant itself an exception.
After a deliberate correction, return to the tool and make one new explicit attempt. Keep the camera choice and the outcome separate: an allowed entry does not prove that a usable stream, local model or recording was obtained. These are desktop Chrome directions, not a promise that the same menus exist in Chrome on a phone, another browser or an embedded app. Use the current help for your browser when its interface differs, without removing security controls to force a result.
No camera found does not always mean absent hardware
The app can group “no matching media” and “requested conditions cannot be met” under a no-camera-style message. Those are not identical to a physical inspection showing that a device has no camera. A disconnected external camera, disabled source or unavailable matching configuration may need a different check. Read the actual tool message and confirm which camera is intended before drawing a conclusion about the phone or computer.
OpenBikeFit requests a preferred rear-camera view where supported, not proof of the exact physical lens or a guaranteed resolution. A requested value and a returned setting are different records. If the source cannot be made available through normal browser and device controls, leave the test unresolved and use a no-camera route. Do not spoof a stream, duplicate an old recording or treat a demonstration as a successful test of the missing device.
A camera-in-use message is not a diagnosis
The friendly messages “The camera is busy” and “Camera in use” suggest checking other camera or video-call applications. They do not prove which application owns the device, and the underlying browser failure can concern the operating system or page rather than another tab. Stop an unnecessary call or preview through its normal controls, then deliberately retry the intended camera tool. Do not stop unrelated work or kill system processes merely to make a label disappear.
If the same message returns after that check, record it as unresolved. Restarting an application is a separate choice, not an automatic repair performed by this reader. A successful subsequent opening supports that attempt only; it does not establish the cause of the earlier failure or certify that the source will stay available throughout a recording. Keep any already completed take separate from the failed attempt instead of treating the two as one uninterrupted capture.
When the preview stays black or the test waits
First distinguish a browser permission choice still waiting for your response from a test that actually ended with an error. A permission request can remain unanswered. The readiness tool also waits for usable decoded video before sampling. A dark rectangle alone does not tell you which situation applies: read the current status, any browser prompt and the final message. A page screenshot cannot verify a hidden stream or a working sensor.
Do not use repeated button presses as a recovery method. In the recorded or live workflow, use its visible Cancel or Stop control if you no longer want that attempt; an already open browser prompt may need to be dismissed separately. Stopping an attempt does not recall an earlier completed clip. If you choose to reload, first consider unsaved work as described below. The no-camera example can be read while the reason remains unknown, without representing its generated movement as your measurement.
A picture can work while the local model cannot
A camera preview and pose processing are different capabilities. Readiness initializes the on-device runtime after obtaining video; the recording workflows also need that runtime before they can provide their technical output. A visible picture therefore does not establish that the pose model loaded. Conversely, a model that was never attempted because camera access failed should not be described as a confirmed model failure.
An “On-device model blocked” message points to local processing, not an instruction to upload footage elsewhere. Check the current browser, connection and the specific message, then make a deliberate fresh attempt when appropriate. Do not disable browser security rules or add an untrusted script to make the model run. The application has no automatic cloud-video fallback here. If processing remains unavailable, keep the result unavailable; a manually invented angle or a copied screenshot cannot replace the missing observation.
A ready preflight is not an accepted recording
The device preflight asks whether this browser can obtain camera access, use temporary local storage and initialize its local processing. It also reports sampled scene conditions. Capture Director asks further questions about the current recording: whole rider and bicycle, side-view tracking, camera stability, light and usable pedal cycles. The bicycle check includes a deliberate human observation because the pose model does not inspect the wheels. Do not check it merely to make a countdown begin.
Read an action-needed preflight as its individual issues, not as an absent camera or a complete pass. Good camera access cannot fill in missing framing, and a supported device does not establish an appropriate physical view. Follow the separate camera-setup guide for that protocol. A technically accepted recording is still a projected movement estimate with limitations, not approval of fit, hardware installation, comfort, riding suitability or a health outcome.
Why sparse sampling pauses pedal-cycle assessment
A camera can advertise one frame rate while the complete processing path delivers fewer usable pose samples. The app uses the observed timestamps, not only the advertised value. Consider a fictional label of 30 fps beside sixteen detections whose first timestamp is 0 ms and last timestamp is 15000 ms. There are fifteen intervals over fifteen seconds: observed density is 1 sample/s, not 30. No real person or video was measured for this arithmetic.
Current capture checks require at least 12 observed samples/s and no gap above 250 ms, with finite, nonnegative, strictly increasing timestamps. These are engineering gates, not validated angle-accuracy thresholds. A long stall can fail even if the average rate looks adequate. “Camera sampling too sparse” pauses pedal-cycle assessment rather than producing a cadence from insufficient evidence. Better light or fewer competing apps may help, but is not a guaranteed cure. Do not retime, interpolate or duplicate frames to pretend that the missing observations occurred.
When a stream or its dimensions change
“Camera stream stopped” means that the current attempt stopped without handing its clip to analysis. Check the connection and source before starting a fresh attempt. Reconnecting a device is not evidence that the interrupted interval became continuous again. Existing completed clips are not recalled by this warning, and a new source must not silently stand in for the source of an earlier take. Preserve the distinction between a stopped attempt and a separately completed result.
A change in decoded video dimensions also changes the coordinate system used by live geometry. The live workflow resets its affected checks and whole-bike confirmation instead of combining incompatible windows. Recheck the actual view rather than assuming that turning the phone preserves the earlier framing. Messages about unavailable timing or video dimensions likewise mean no clip was handed forward from that failed finish. They are not instructions to substitute a nominal frame size or a convenient default rate.
Before reloading, keep saved and unsaved work separate
Reloading is sometimes part of permission recovery, but it is not a neutral action for every open workflow. A failed readiness test is not a saved fit. Another page can contain a tab-only working copy, an unconfirmed save or a recovery message that needs its own controls. Read that notice first and keep an original private backup when the existing workflow calls for one. Do not assume that a successful camera opening confirms that any fit or recording was saved.
Do not clear website data, delete local records or reset all browser settings as a routine camera fix. Such actions can remove material unrelated to the camera permission. This static reader performs none of them. The readiness page already has a small temporary storage probe that cleans up after its check; that does not make the whole application a no-storage system. Existing saved-data and recovery tools retain their own review and confirmation boundaries, independently of the camera test.
Make one bounded retry or take a no-camera route
Choose a next attempt only after you have identified the stage and made a relevant correction. Start the existing test yourself, observe its current outcome and stop if it is still unresolved. This guide does not run a background test, change a setting or retry automatically. A new tab can cause browser scheduling or capture behavior to change; stop an active capture deliberately before leaving it to read help rather than expecting uninterrupted recording in the background.
If the camera path is unavailable, read the public fictional analysis to understand the output, use the body-input calculator for its separate model estimates, or read the blank bicycle worksheet for a physical record. Those are different tasks, not successful camera measurements or substitutes for accepted takes. All public tools remain free. A separate human service is not included by opening a guide or tool, and any B2B work requires its own agreed scope.
What to report if the problem remains
A useful support description is small and concrete: page name, loaded app version, browser and operating-system version if known, exact visible message, whether a permission prompt appeared, and whether a preview ever became visible. Distinguish what you observed from what you think caused it. For example, “Safari displayed Camera permission is blocked before any preview” is more informative than “the phone has no camera” when no hardware check was performed.
Do not include customer records, health details, saved-fit identifiers, full measurement links or raw video in a routine report. If you choose a screenshot, first check what private material it shows; sending it remains your decision through the existing support route. This reader neither collects a report nor opens a mail composer. Keep the unresolved state honest until a new observation changes it. A browser setting, software quality flag and physical device test are separate pieces of evidence.
Practical questions
Frequently asked questions
Does camera permission blocked mean my iPhone has no camera?
No. It identifies an access problem reported by the page, not a physical inspection. Check the intended site’s permission in Safari and observe one new deliberate test. Another restriction can remain unresolved.
Must I enable the microphone or allow every website?
No. OpenBikeFit requests video with audio disabled. Review only the intended site’s camera permission. You can leave it denied and read the public fictional analysis.
Why is there no camera prompt?
A prior choice, browser context or device policy can prevent a new prompt, and a request may remain unanswered. Read the exact current message; absence of a prompt alone does not identify the cause.
Why can I see a picture but still get no result?
A preview does not prove that the local pose model ran or that capture quality passed. Read whether the problem concerns processing, framing, sampling or the interrupted stream instead of treating them all as permission errors.
Why does Capture Director pause after readiness passed?
Preflight and the current recording answer different questions. Live capture additionally checks current framing, side-view tracking, stability, light and pedal-cycle evidence. A device pass cannot supply those observations.
Does a 30 fps camera guarantee enough samples?
No. Observed detections and timestamps determine usable density. Sixteen samples spanning fifteen seconds have fifteen intervals and density 1 sample/s. The nominal camera label does not fill the missing observations.
Should I delete website data or keep reloading?
Not as routine recovery. Website data can include saved local work; reloading can lose tab-only copies. Read the existing save/recovery notice first, correct one relevant issue and deliberately retry without deleting records.
Is a passed camera test proof that my bike fit is correct?
No. Device readiness, an accepted recording, a repeatable observation and a physical fit outcome are separate. The camera test does not approve hardware, riding suitability or clinical accuracy.