Back camera is being shown sometimes, instead of front camera.

[ghost]

Hi!

My current setup:
setFacing(CameraKit.Constants.FACING_FRONT);
setFlash(CameraKit.Constants.FLASH_OFF);
setFocus(CameraKit.Constants.FOCUS_CONTINUOUS);
setMethod(CameraKit.Constants.METHOD_STILL);
setCropOutput(true);
setJpegQuality(100);

Sometimes (1 from 100 or 200) preview of back camera is being displayed instead of front camera.

Also front camera is set in xml:

<com.beyondar.android.view.CameraKitView
android:id="@+id/camera"
camerakit:ckFacing="front"
android:layout_width="match_parent"
android:layout_height="match_parent"/>

however it doesn't help.

Any ideas? :)

[Moonbloom]

I'm experiencing the same issue.
I save the last facing variable to shared preferences in our app, and parse it when opening the camera, so it keeps the state.

I've verified that my shared preferences are saved/opened correctly, so the issue must lie within the library.

I've tried setting setFacing before starting the camera, and also after (and also both), but sometimes it simply ignores this completely and opens the back camera.

For me it happens more than 1 in 100 or 200, it's more like 1 in 10 or 20.

If it was possible to get the current facing from the camera, we could correct it ourselves (by checking in "onCameraOpened", if the facing we expect is the same as the one that was opened, if not, then set it).
But thats more of a hotfix than an actual fix.

[ghost]

it's more like 1 in 10 or 20.

I guess it may also differ per device. I see it rarely on my nexus, and often on Samsung.

Also I guess there are some kind of race conditions there.

[Moonbloom]

I've hacked my way around this issue (for now).

I call .setFacing(int) before calling .start(), and when i call .start(), i delay it by 50 ms (using a Handler and postDelayed function), and then after i call .start(), i call .setFacing(int) once more.

This seems, for me, to handle all cases. So the camera is always facing the correct way, and i've yet to find any errors in this except for the fact that the first 50 ms, the view will be blank.

Hope it can help you @nethergrim and possibly others.

[ghost]

Sounds like a tmp fix, but thanks a lot!

[Moonbloom]

I've digged a bit deeper into this issue and i'm certain i've found the culprit to the main issue:

When calling .setFacing(int), internally the library creates a new thread and does the actual switching on that thread. So it's asynchronous, but that also means that if the timing is bad, it will start the actual camera before setFacing is done, thus the wrong camera is shown.

I removed the new thread, which means everything is called on the UI thread, and then i tried to open/close the camera about 50-100 times, on 2 devices i have, and it has not "messed" up one single time.

I don't have access to a really slow/lowend device right now, so i don't know how it will handle the camera facing on the UI thread on such a device. But on my highend device, it works absolutely perfect, with no lag.

If it lags on a lowend device, a good fix would be to create a thread internally and handle the switching on that thread (as it does now), but then expose an interface that the user can hook into, to get a callback when the switching is finished.

I'll be able to test this on about 20 different devices on monday when i'm back at work, and i'll post an update on how lowend devices handle it.

With this fix, i could also remove all my hacky code that i posted about earlier.
I call .setFacing(int) one time before calling .start(), and there are no Handlers using postDelayed.