#2648 - Cannot add ov5647 CSI camera - unable to open video device - starred/motioneye

deekerman commented

2026-02-28 01:16:41 -05:00

Owner

Originally created by @houserockr on GitHub (Jul 28, 2025).

I'm running a Raspberry Pi 4B rev 1.5 with raspbian 12.11 bookworm

$ uname -a
Linux eyes 6.12.25+rpt-rpi-v8 #1 SMP PREEMPT Debian 1:6.12.25-1+rpt1 (2025-04-30) aarch64 GNU/Linux

I've got an ov5647 camera connected to the CSI0 port (the one between hdmi1 and AUX).

I installed motioneye via the guide on the main repo page - installation went through w/o any problems.
motionEye Version 0.43.1b4
Motion Version 4.7.0

libcamera seems to detect the camera:

$ libcamera-hello --list-cameras
Available cameras
-----------------
0 : ov5647 [2592x1944 10-bit GBRG] (/base/soc/i2c0mux/i2c@1/ov5647@36)
    Modes: 'SGBRG10_CSI2P' : 640x480 [58.92 fps - (16, 0)/2560x1920 crop]
                             1296x972 [46.34 fps - (0, 0)/2592x1944 crop]
                             1920x1080 [32.81 fps - (348, 434)/1928x1080 crop]
                             2592x1944 [15.63 fps - (0, 0)/2592x1944 crop]

But vcgencmd doesn't

$ vcgencmd get_camera 
supported=0 detected=0, libcamera interfaces=0

v4l

$ v4l2-ctl --list-devices
bcm2835-codec-decode (platform:bcm2835-codec):
	/dev/video10
	/dev/video11
	/dev/video12
	/dev/video18
	/dev/video31

bcm2835-isp (platform:bcm2835-isp):
	/dev/video13
	/dev/video14
	/dev/video15
	/dev/video16
	/dev/video20
	/dev/video21
	/dev/video22
	/dev/video23
	/dev/media1
	/dev/media3

unicam (platform:fe801000.csi):
	/dev/video0
	/dev/media2

rpi-hevc-dec (platform:rpi-hevc-dec):
	/dev/video19
	/dev/media0

bcm2835-codec (vchiq:bcm2835-codec):
	/dev/media4

The camera has to be connected properly, because when I run libcamera-hello, I get a preview window with a live preview showing what's in front of the camera! I'm not showing an image, but here's the output of the program:

$ libcamera-hello 
[0:17:49.881334985] [2072]  INFO Camera camera_manager.cpp:326 libcamera v0.5.1+100-e53bdf1f
[0:17:49.929750802] [2075]  WARN RPiSdn sdn.cpp:40 Using legacy SDN tuning - please consider moving SDN inside rpi.denoise
[0:17:49.932465684] [2075]  INFO RPI vc4.cpp:440 Registered camera /base/soc/i2c0mux/i2c@1/ov5647@36 to Unicam device /dev/media2 and ISP device /dev/media1
[0:17:49.932634915] [2075]  INFO RPI pipeline_base.cpp:1107 Using configuration file '/usr/share/libcamera/pipeline/rpi/vc4/rpi_apps.yaml'
Made X/EGL preview window
Mode selection for 1296:972:12:P
    SGBRG10_CSI2P,640x480/0 - Score: 3296
    SGBRG10_CSI2P,1296x972/0 - Score: 1000
    SGBRG10_CSI2P,1920x1080/0 - Score: 1349.67
    SGBRG10_CSI2P,2592x1944/0 - Score: 1567
Stream configuration adjusted
[0:17:50.001828744] [2072]  INFO Camera camera.cpp:1205 configuring streams: (0) 1296x972-YUV420/sYCC (1) 1296x972-SGBRG10_CSI2P/RAW
[0:17:50.002318809] [2075]  INFO RPI vc4.cpp:615 Sensor: /base/soc/i2c0mux/i2c@1/ov5647@36 - Selected sensor format: 1296x972-SGBRG10_1X10 - Selected unicam format: 1296x972-pGAA

No matter which camera I add on the motioneye UI, I get a gray image displaying
unable to open video device

The first ones I've tried are the "unicam" models, because their devices /dev/video0 and /dev/media2 match the output of libcamera-hello, where I get an actual preview image. But no success.

Is there any way to see a (debug) log that shows why motioneye isn't able to open the devices? Permissions?

Originally created by @houserockr on GitHub (Jul 28, 2025). I'm running a Raspberry Pi 4B rev 1.5 with raspbian 12.11 bookworm ```` $ uname -a Linux eyes 6.12.25+rpt-rpi-v8 #1 SMP PREEMPT Debian 1:6.12.25-1+rpt1 (2025-04-30) aarch64 GNU/Linux ```` I've got an ov5647 camera connected to the CSI0 port (the one between hdmi1 and AUX). I installed motioneye via the guide on the main repo page - installation went through w/o any problems. motionEye Version 0.43.1b4 Motion Version 4.7.0 libcamera seems to detect the camera: ```` $ libcamera-hello --list-cameras Available cameras ----------------- 0 : ov5647 [2592x1944 10-bit GBRG] (/base/soc/i2c0mux/i2c@1/ov5647@36) Modes: 'SGBRG10_CSI2P' : 640x480 [58.92 fps - (16, 0)/2560x1920 crop] 1296x972 [46.34 fps - (0, 0)/2592x1944 crop] 1920x1080 [32.81 fps - (348, 434)/1928x1080 crop] 2592x1944 [15.63 fps - (0, 0)/2592x1944 crop] ```` But `vcgencmd` doesn't ```` $ vcgencmd get_camera supported=0 detected=0, libcamera interfaces=0 ```` v4l ```` $ v4l2-ctl --list-devices bcm2835-codec-decode (platform:bcm2835-codec): /dev/video10 /dev/video11 /dev/video12 /dev/video18 /dev/video31 bcm2835-isp (platform:bcm2835-isp): /dev/video13 /dev/video14 /dev/video15 /dev/video16 /dev/video20 /dev/video21 /dev/video22 /dev/video23 /dev/media1 /dev/media3 unicam (platform:fe801000.csi): /dev/video0 /dev/media2 rpi-hevc-dec (platform:rpi-hevc-dec): /dev/video19 /dev/media0 bcm2835-codec (vchiq:bcm2835-codec): /dev/media4 ```` The camera has to be connected properly, because when I run libcamera-hello, I get a preview window with a live preview showing what's in front of the camera! I'm not showing an image, but here's the output of the program: ```` $ libcamera-hello [0:17:49.881334985] [2072] INFO Camera camera_manager.cpp:326 libcamera v0.5.1+100-e53bdf1f [0:17:49.929750802] [2075] WARN RPiSdn sdn.cpp:40 Using legacy SDN tuning - please consider moving SDN inside rpi.denoise [0:17:49.932465684] [2075] INFO RPI vc4.cpp:440 Registered camera /base/soc/i2c0mux/i2c@1/ov5647@36 to Unicam device /dev/media2 and ISP device /dev/media1 [0:17:49.932634915] [2075] INFO RPI pipeline_base.cpp:1107 Using configuration file '/usr/share/libcamera/pipeline/rpi/vc4/rpi_apps.yaml' Made X/EGL preview window Mode selection for 1296:972:12:P SGBRG10_CSI2P,640x480/0 - Score: 3296 SGBRG10_CSI2P,1296x972/0 - Score: 1000 SGBRG10_CSI2P,1920x1080/0 - Score: 1349.67 SGBRG10_CSI2P,2592x1944/0 - Score: 1567 Stream configuration adjusted [0:17:50.001828744] [2072] INFO Camera camera.cpp:1205 configuring streams: (0) 1296x972-YUV420/sYCC (1) 1296x972-SGBRG10_CSI2P/RAW [0:17:50.002318809] [2075] INFO RPI vc4.cpp:615 Sensor: /base/soc/i2c0mux/i2c@1/ov5647@36 - Selected sensor format: 1296x972-SGBRG10_1X10 - Selected unicam format: 1296x972-pGAA ```` No matter which camera I add on the motioneye UI, I get a gray image displaying **unable to open video device** The first ones I've tried are the "unicam" models, because their devices `/dev/video0` and `/dev/media2` match the output of `libcamera-hello`, where I get an actual preview image. But no success. Is there any way to see a (debug) log that shows **why** motioneye isn't able to open the devices? Permissions?

deekerman added the

Raspberry Pi

label

2026-02-28 01:16:41 -05:00

deekerman commented

2026-02-28 01:16:43 -05:00

Author

Owner

@houserockr commented on GitHub (Jul 28, 2025):

This fixed my problem, technically:
https://github.com/motioneye-project/motioneye/issues/2812#issuecomment-1817391735

Changing /etc/systemd/system/motioneye.service
from

...
ExecStart=/usr/local/bin/meyectl startserver -c /etc/motioneye/motioneye.conf
...

to

...
ExecStart=/usr/bin/libcamerify /usr/local/bin/meyectl startserver -c /etc/motioneye/motioneye.conf
...

Suddenly ME listed the camera's device path (/base/soc/i2c0mux/...) in the drop down menu to add a new camera and I can now see an image in ME.

However, now I cannot change the resolution of the camera, it's stuck to 320x200 and changing the resolution in the UI just crops the image weirdly.

@houserockr commented on GitHub (Jul 28, 2025): This fixed my problem, technically: https://github.com/motioneye-project/motioneye/issues/2812#issuecomment-1817391735 Changing `/etc/systemd/system/motioneye.service` from ```` ... ExecStart=/usr/local/bin/meyectl startserver -c /etc/motioneye/motioneye.conf ... ```` to ```` ... ExecStart=/usr/bin/libcamerify /usr/local/bin/meyectl startserver -c /etc/motioneye/motioneye.conf ... ```` Suddenly ME listed the camera's device path (`/base/soc/i2c0mux/...`) in the drop down menu to add a new camera and I can now see an image in ME. However, now I cannot change the resolution of the camera, it's stuck to 320x200 and changing the resolution in the UI just crops the image weirdly.

deekerman commented

2026-02-28 01:16:44 -05:00

Author

Owner

@yiays commented on GitHub (Jul 31, 2025):

If you have the option to "Enable legacy camera" in raspi-config (in the interfaces section), turn that on. As far as I'm aware, motioneye still doesn't support libcamera.

@yiays commented on GitHub (Jul 31, 2025): If you have the option to "Enable legacy camera" in raspi-config (in the interfaces section), turn that on. As far as I'm aware, motioneye still doesn't support libcamera.

deekerman commented

2026-02-28 01:16:44 -05:00

Author

Owner

@houserockr commented on GitHub (Jul 31, 2025):

If you have the option to "Enable legacy camera" in raspi-config (in the interfaces section), turn that on. As far as I'm aware, motioneye still doesn't support libcamera.

I knew about that option, but it seems to have been removed in raspbian bookworm, I do not have it any more in raspi-config.

I reverted back to bullseye.

@houserockr commented on GitHub (Jul 31, 2025): > If you have the option to "Enable legacy camera" in raspi-config (in the interfaces section), turn that on. As far as I'm aware, motioneye still doesn't support libcamera. I knew about that option, but it seems to have been removed in raspbian bookworm, I do not have it any more in `raspi-config`. I reverted back to bullseye.

deekerman commented

2026-02-28 01:16:44 -05:00

Author

Owner

@MichaIng commented on GitHub (Jul 31, 2025):

The MMAL library has been removed from RPi OS Bookworm in the meantime. See above usage of libcamerify, which provides a common V4L2 API on top of libcamera. The full steps:

apt install -y libcamera-v4l2 libcamera-tools
sed -i 's|/usr/local/bin/meyectl|/usr/bin/libcamerify /usr/local/bin/meyectl|' /etc/systemd/system/motioneye.service
systemctl daemon-reload
systemctl restart motioneye

@MichaIng commented on GitHub (Jul 31, 2025): The MMAL library has been removed from RPi OS Bookworm in the meantime. See above usage of `libcamerify`, which provides a common V4L2 API on top of libcamera. The full steps: ```sh apt install -y libcamera-v4l2 libcamera-tools sed -i 's|/usr/local/bin/meyectl|/usr/bin/libcamerify /usr/local/bin/meyectl|' /etc/systemd/system/motioneye.service systemctl daemon-reload systemctl restart motioneye ```

deekerman commented

2026-02-28 01:16:44 -05:00

Author

Owner

@houserockr commented on GitHub (Jul 31, 2025):

Yes and I got it working that way, like I wrote.
But it only worked partially, because I wasn’t able to change any of the camera’s parameters, like with MMAL.

I like the consequent move towards libcamera on the OS end. Question is: Are there any plans in motioneye to adopt/migrate all the features that worked with MMAL? It seems to me this hole libcamerify approach, probably using ld_preload “hacks, is only meant for a transition phase?!

@houserockr commented on GitHub (Jul 31, 2025): Yes and I got it working that way, like I wrote. But it only worked partially, because I wasn’t able to change any of the camera’s parameters, like with MMAL. I like the consequent move towards libcamera on the OS end. Question is: Are there any plans in motioneye to adopt/migrate all the features that worked with MMAL? It seems to me this hole libcamerify approach, probably using ld_preload “hacks, is only meant for a transition phase?!

deekerman commented

2026-02-28 01:16:44 -05:00

Author

Owner

@MichaIng commented on GitHub (Jul 31, 2025):

The problem is that motion itself does not support libcamera, so there is currently no way for motionEye to support it directly either. libcamerify is part of the libcamera project itself, at least, but of course it is not perfect.

Not sure whether the resolution limitation is an issue with libcamerify, or something we can fix in motionEye, or a limitation with certain camera module models in combination with libcamerify. Needs some testing, I guess. Should be possible to use enter a subshell:

libcamerify bash

And then check which info and resolutions v4l2-ctl gives for the resulting /dev/video* device(s). Might be something to report at the RPi fork of the libcamera project: https://github.com/raspberrypi/libcamera/issues

@MichaIng commented on GitHub (Jul 31, 2025): The problem is that `motion` itself does not support `libcamera`, so there is currently no way for motionEye to support it directly either. `libcamerify` is part of the `libcamera` project itself, at least, but of course it is not perfect. Not sure whether the resolution limitation is an issue with `libcamerify`, or something we can fix in motionEye, or a limitation with certain camera module models in combination with `libcamerify`. Needs some testing, I guess. Should be possible to use enter a subshell: ```sh libcamerify bash ``` And then check which info and resolutions `v4l2-ctl` gives for the resulting `/dev/video*` device(s). Might be something to report at the RPi fork of the `libcamera` project: https://github.com/raspberrypi/libcamera/issues

deekerman commented

2026-02-28 01:16:44 -05:00

Author

Owner

@TipsyTheCat commented on GitHub (Dec 11, 2025):

motion v5 supports libcamera natively iirc, im not sure how stable it is atm. if motioneye intends to play nice with current hardware and software then utilizing motion v5 should be looked into

@TipsyTheCat commented on GitHub (Dec 11, 2025): motion v5 supports libcamera natively iirc, im not sure how stable it is atm. if motioneye intends to play nice with current hardware and software then utilizing motion v5 should be looked into

deekerman commented

2026-02-28 01:16:44 -05:00

Author

Owner

@MichaIng commented on GitHub (Dec 11, 2025):

Great news. There is no release (or pre-release) tag for v5 yet, but I guess can be tested with an own build. We'd still need to find a way to detect libcamera cameras correctly, i.e. to not show their dozen's of /dev/video* nodes, but a single node instead. libcamera tools and again a special handling/camera type that replaces MMAL looks like the most probable way. I wished they would behave like regular V4L2 cameras, so the we could remove all this annoying special-handling 🙄.

@MichaIng commented on GitHub (Dec 11, 2025): Great news. There is no release (or pre-release) tag for v5 yet, but I guess can be tested with an own build. We'd still need to find a way to detect libcamera cameras correctly, i.e. to not show their dozen's of `/dev/video*` nodes, but a single node instead. libcamera tools and again a special handling/camera type that replaces MMAL looks like the most probable way. I wished they would behave like regular V4L2 cameras, so the we could remove all this annoying special-handling 🙄.

Rows
Columns

Cannot add ov5647 CSI camera - unable to open video device #2648