Can't connect to composite camera #2387

Open
opened 2026-02-28 01:10:57 -05:00 by deekerman · 19 comments
Owner

Originally created by @ceejayemm on GitHub (May 1, 2023).

I have a quite old camera which only has a composite output. Up until recently I have been using this with the original MotionEye (upto v0.42.1) on a RPi ZeroW running 32 bit RaspberryOS and a no-brand composite to USB converter. This seems to work well for my purposes and I had no problems as far as I am aware. I recently came across this revised MotionEye project and decided to give the new DEV branch a try (to bring me into the current world). I installed the Dev version (as at the end of April) on a new SD card following the instructions on the GitHub pages. The new installation seems to have worked OK with no noted errors and when started reports:

motionEye Version: 0.43.0
Motion Version: 4.5.1
OS Version: Rasbian 11

Unfortunately after configuring the camera as before the camera setup seems to be not recognised with this version of the software and reports 'Unable to open video device since...'

In both versions of MotionEye the camera is mounted as:

Camera Type: Local V42L Camera
Camera: AV to USB 2.0

There have been no changes to the hardware, only the software version has been updated to the newer DEV version. Within the MotionEye configuration screen (both original version and new version) the Camera Device is noted as being:

/dev/v4l/by-id/usb-MACROSILICON_AV_TO_USB2.0_20150130-video-index0

Am I bound to revert to the old version of this software to continue using my existing camera or is there something I can tweak to make the camera usable in the new version of the software ?

Many thanks for any help anybody can supply.

Chris

Originally created by @ceejayemm on GitHub (May 1, 2023). I have a quite old camera which only has a composite output. Up until recently I have been using this with the original MotionEye (upto v0.42.1) on a RPi ZeroW running 32 bit RaspberryOS and a no-brand composite to USB converter. This seems to work well for my purposes and I had no problems as far as I am aware. I recently came across this revised MotionEye project and decided to give the new DEV branch a try (to bring me into the current world). I installed the Dev version (as at the end of April) on a new SD card following the instructions on the GitHub pages. The new installation seems to have worked OK with no noted errors and when started reports: motionEye Version: 0.43.0 Motion Version: 4.5.1 OS Version: Rasbian 11 Unfortunately after configuring the camera as before the camera setup seems to be not recognised with this version of the software and reports 'Unable to open video device since...' In both versions of MotionEye the camera is mounted as: Camera Type: Local V42L Camera Camera: AV to USB 2.0 There have been no changes to the hardware, only the software version has been updated to the newer DEV version. Within the MotionEye configuration screen (both original version and new version) the Camera Device is noted as being: /dev/v4l/by-id/usb-MACROSILICON_AV_TO_USB2.0_20150130-video-index0 Am I bound to revert to the old version of this software to continue using my existing camera or is there something I can tweak to make the camera usable in the new version of the software ? Many thanks for any help anybody can supply. Chris
Author
Owner

@MichaIng commented on GitHub (May 1, 2023):

I installed the Dev version (as at the end of April) on a new SD card following the instructions on the GitHub pages.

Did you try it on the old SD card? E.g. there are significant changes on the RPi kernel between Buster and Bullseye which may be responsible instead of the motionEye update.

A motionEye v0.42.1 can be seamlessly upgraded to 0.43.0, following the instructions: https://github.com/motioneye-project/motioneye/tree/dev#installation

@MichaIng commented on GitHub (May 1, 2023): > I installed the Dev version (as at the end of April) on a new SD card following the instructions on the GitHub pages. Did you try it on the old SD card? E.g. there are significant changes on the RPi kernel between Buster and Bullseye which may be responsible instead of the motionEye update. A motionEye v0.42.1 can be seamlessly upgraded to 0.43.0, following the instructions: https://github.com/motioneye-project/motioneye/tree/dev#installation
Author
Owner

@ceejayemm commented on GitHub (May 1, 2023):

Until recently I had all the same hardware and the 'old' version of MotionEye running under Raspian / Debian Buster. I updated that installation (still using the 'old' version of MotionEye) to Bullseye with no issues. That's why I was a bit surprised to get the problems I now have with the new MotionEye version running on Bullseye.

I didn't realise that I could upgrade the 'old' version to the 'new' version so I will restore the 'old' version and try the instructions listed above.

Chris

@ceejayemm commented on GitHub (May 1, 2023): Until recently I had all the same hardware and the 'old' version of MotionEye running under Raspian / Debian Buster. I updated that installation (still using the 'old' version of MotionEye) to Bullseye with no issues. That's why I was a bit surprised to get the problems I now have with the new MotionEye version running on Bullseye. I didn't realise that I could upgrade the 'old' version to the 'new' version so I will restore the 'old' version and try the instructions listed above. Chris
Author
Owner

@MichaIng commented on GitHub (May 1, 2023):

Upgrading an existing Buster to Bullseye does not imply changed /boot/config.txt defaults, like KMS graphics driver and modern camera stack. So

I will restore the 'old' version and try the instructions listed above.

That would be great.

@MichaIng commented on GitHub (May 1, 2023): Upgrading an existing Buster to Bullseye does not imply changed `/boot/config.txt` defaults, like KMS graphics driver and modern camera stack. So > I will restore the 'old' version and try the instructions listed above. That would be great.
Author
Owner

@ceejayemm commented on GitHub (May 2, 2023):

I carried out the upgrade of the 'old' version following the instructions noted above:

pi@cmcam3:~ $ sudo systemctl stop motioneye
pi@cmcam3:~ $ sudo python3 -m pip install --upgrade --force-reinstall --no-deps 'https://github.com/motioneye-project/motioneye/archive/dev.tar.gz'
Collecting https://github.com/motioneye-project/motioneye/archive/dev.tar.gz
  Downloading https://github.com/motioneye-project/motioneye/archive/dev.tar.gz
     / 1.3 MB 1.2 MB/s 0:00:01
  Installing build dependencies ... done
  Getting requirements to build wheel ... done
  Preparing metadata (pyproject.toml) ... done
Building wheels for collected packages: motioneye
  Building wheel for motioneye (pyproject.toml) ... done
  Created wheel for motioneye: filename=motioneye-0.43.0-py3-none-any.whl size=933413 sha256=d7390f6eea1304ebfaa8ad03eefb3afc49457cfbf94eaa93880a3785bd6815a7
  Stored in directory: /tmp/pip-ephem-wheel-cache-kpmvk3qo/wheels/5d/19/3b/8df45c45f762bba3d414e214316b57965795dbbf58c209bce5
Successfully built motioneye
Installing collected packages: motioneye
Successfully installed motioneye-0.43.0
WARNING: Running pip as the 'root' user can result in broken permissions and conflicting behaviour with the system package manager. It is recommended to use a virtual environment instead: https://pip.pypa.io/warnings/venv
pi@cmcam3:~ $ sudo systemctl start motioneye

There are no obvious errors in any of the above however I can no longer access the system via http://cmcam3:8765/ so it would appear the upgrade has failed in some way but how ?

Any further suggestions ?

Chris

@ceejayemm commented on GitHub (May 2, 2023): I carried out the upgrade of the 'old' version following the instructions noted above: ```console pi@cmcam3:~ $ sudo systemctl stop motioneye pi@cmcam3:~ $ sudo python3 -m pip install --upgrade --force-reinstall --no-deps 'https://github.com/motioneye-project/motioneye/archive/dev.tar.gz' Collecting https://github.com/motioneye-project/motioneye/archive/dev.tar.gz Downloading https://github.com/motioneye-project/motioneye/archive/dev.tar.gz / 1.3 MB 1.2 MB/s 0:00:01 Installing build dependencies ... done Getting requirements to build wheel ... done Preparing metadata (pyproject.toml) ... done Building wheels for collected packages: motioneye Building wheel for motioneye (pyproject.toml) ... done Created wheel for motioneye: filename=motioneye-0.43.0-py3-none-any.whl size=933413 sha256=d7390f6eea1304ebfaa8ad03eefb3afc49457cfbf94eaa93880a3785bd6815a7 Stored in directory: /tmp/pip-ephem-wheel-cache-kpmvk3qo/wheels/5d/19/3b/8df45c45f762bba3d414e214316b57965795dbbf58c209bce5 Successfully built motioneye Installing collected packages: motioneye Successfully installed motioneye-0.43.0 WARNING: Running pip as the 'root' user can result in broken permissions and conflicting behaviour with the system package manager. It is recommended to use a virtual environment instead: https://pip.pypa.io/warnings/venv pi@cmcam3:~ $ sudo systemctl start motioneye ``` There are no obvious errors in any of the above however I can no longer access the system via http://cmcam3:8765/ so it would appear the upgrade has failed in some way but how ? Any further suggestions ? Chris
Author
Owner

@MichaIng commented on GitHub (May 2, 2023):

Please do not follow the "upgrade" instruction, but the install instructions. The latter is only right for dev to dev upgrades when the version string did not change.

@MichaIng commented on GitHub (May 2, 2023): Please do not follow the "upgrade" instruction, but the install instructions. The latter is only right for dev to dev upgrades when the version string did not change.
Author
Owner

@ceejayemm commented on GitHub (May 9, 2023):

Sorry for the delay in getting back to you, I have had other things on my plate.

I flashed 2 new SD cards with the latest Raspberry PI OS Lite (3 May 2023 - Bullseye) 32 bit version and applied all outstanding updates (apt update/full-upgrade).

On Card 1, I installed the original MotionEye software (v4.2.1) from the Python2 branch of the Github repository and followed the instructions at: https://github.com/motioneye-project/motioneye/wiki/Install-on-Debian-11-%28Bullseye%29. Once the installation was complete I then configured the camera (Local camera / AV to USB 2.0) which seems to work as I would expect.

On Card 2, I installed the original MotionEye software (again using the Python2 branch and configuration as for Card 1). This again seemed to be working OK. Without changing anything else I then installed the (new) Python 3 version from the Dev branch following the instructions in the readme.md file on that branch. This seems to work OK at first, I could access the camera and see a video image UNTIL I rebooted the PI. At this point the PI was not accessible via the web page at all but the system is accessible via SSH.

I cannot find any obvious log files for this installation but journalctl -xe shows:

May 09 14:25:00 cmcam3 motion[342]: [1:ml1] [WRN] [ALL] mlp_retry: Retrying until successful connection with camera
May 09 14:25:00 cmcam3 motion[342]: [1:ml1] [NTC] [VID] vid_start: Opening V4L2 device
May 09 14:25:00 cmcam3 motion[342]: [1:ml1] [NTC] [VID] v4l2_device_open: Using videodevice /dev/video0 and input -1
May 09 14:25:00 cmcam3 motion[342]: [1:ml1] [ALR] [VID] v4l2_device_open: Failed to open video device /dev/video0: No such file>
May 09 14:25:00 cmcam3 motion[342]: [1:ml1] [ERR] [VID] vid_start: V4L2 device failed to open
May 09 14:25:04 cmcam3 dhcpcd[465]: wlan0: leased 192.168.86.233 for 86400 seconds
May 09 14:25:04 cmcam3 avahi-daemon[235]: Joining mDNS multicast group on interface wlan0.IPv4 with address 192.168.86.233.
May 09 14:25:04 cmcam3 dhcpcd[465]: wlan0: adding route to 192.168.86.0/24
May 09 14:25:04 cmcam3 dhcpcd[465]: wlan0: adding default route via 192.168.86.1
May 09 14:25:04 cmcam3 avahi-daemon[235]: New relevant interface wlan0.IPv4 for mDNS.
May 09 14:25:04 cmcam3 avahi-daemon[235]: Registering new address record for 192.168.86.233 on wlan0.IPv4.
May 09 14:25:10 cmcam3 motion[342]: [1:ml1] [WRN] [ALL] mlp_retry: Retrying until successful connection with camera
May 09 14:25:10 cmcam3 motion[342]: [1:ml1] [NTC] [VID] vid_start: Opening V4L2 device
May 09 14:25:10 cmcam3 motion[342]: [1:ml1] [NTC] [VID] v4l2_device_open: Using videodevice /dev/video0 and input -1
May 09 14:25:10 cmcam3 motion[342]: [1:ml1] [ALR] [VID] v4l2_device_open: Failed to open video device /dev/video0: No such file>
May 09 14:25:10 cmcam3 motion[342]: [1:ml1] [ERR] [VID] vid_start: V4L2 device failed to open
May 09 14:25:13 cmcam3 dhcpcd[465]: wlan0: no IPv6 Routers available
May 09 14:25:14 cmcam3 sshd[518]: Connection closed by 192.168.86.53 port 58016 [preauth]
May 09 14:25:17 cmcam3 systemd[1]: systemd-hostnamed.service: Succeeded.
░░ 

It seems that /dev/video0 does not exist (ls -lrt /dev/video0 confirms this too)

So it seems that the 'new' version is lacking something that the original version has !

I hope this helps.

Chris

@ceejayemm commented on GitHub (May 9, 2023): Sorry for the delay in getting back to you, I have had other things on my plate. I flashed 2 new SD cards with the latest Raspberry PI OS Lite (3 May 2023 - Bullseye) 32 bit version and applied all outstanding updates (apt update/full-upgrade). On Card 1, I installed the original MotionEye software (v4.2.1) from the Python2 branch of the Github repository and followed the instructions at: https://github.com/motioneye-project/motioneye/wiki/Install-on-Debian-11-%28Bullseye%29. Once the installation was complete I then configured the camera (Local camera / AV to USB 2.0) which seems to work as I would expect. On Card 2, I installed the original MotionEye software (again using the Python2 branch and configuration as for Card 1). This again seemed to be working OK. Without changing anything else I then installed the (new) Python 3 version from the Dev branch following the instructions in the readme.md file on that branch. This seems to work OK at first, I could access the camera and see a video image UNTIL I rebooted the PI. At this point the PI was not accessible via the web page at all but the system is accessible via SSH. I cannot find any obvious log files for this installation but journalctl -xe shows: ``` May 09 14:25:00 cmcam3 motion[342]: [1:ml1] [WRN] [ALL] mlp_retry: Retrying until successful connection with camera May 09 14:25:00 cmcam3 motion[342]: [1:ml1] [NTC] [VID] vid_start: Opening V4L2 device May 09 14:25:00 cmcam3 motion[342]: [1:ml1] [NTC] [VID] v4l2_device_open: Using videodevice /dev/video0 and input -1 May 09 14:25:00 cmcam3 motion[342]: [1:ml1] [ALR] [VID] v4l2_device_open: Failed to open video device /dev/video0: No such file> May 09 14:25:00 cmcam3 motion[342]: [1:ml1] [ERR] [VID] vid_start: V4L2 device failed to open May 09 14:25:04 cmcam3 dhcpcd[465]: wlan0: leased 192.168.86.233 for 86400 seconds May 09 14:25:04 cmcam3 avahi-daemon[235]: Joining mDNS multicast group on interface wlan0.IPv4 with address 192.168.86.233. May 09 14:25:04 cmcam3 dhcpcd[465]: wlan0: adding route to 192.168.86.0/24 May 09 14:25:04 cmcam3 dhcpcd[465]: wlan0: adding default route via 192.168.86.1 May 09 14:25:04 cmcam3 avahi-daemon[235]: New relevant interface wlan0.IPv4 for mDNS. May 09 14:25:04 cmcam3 avahi-daemon[235]: Registering new address record for 192.168.86.233 on wlan0.IPv4. May 09 14:25:10 cmcam3 motion[342]: [1:ml1] [WRN] [ALL] mlp_retry: Retrying until successful connection with camera May 09 14:25:10 cmcam3 motion[342]: [1:ml1] [NTC] [VID] vid_start: Opening V4L2 device May 09 14:25:10 cmcam3 motion[342]: [1:ml1] [NTC] [VID] v4l2_device_open: Using videodevice /dev/video0 and input -1 May 09 14:25:10 cmcam3 motion[342]: [1:ml1] [ALR] [VID] v4l2_device_open: Failed to open video device /dev/video0: No such file> May 09 14:25:10 cmcam3 motion[342]: [1:ml1] [ERR] [VID] vid_start: V4L2 device failed to open May 09 14:25:13 cmcam3 dhcpcd[465]: wlan0: no IPv6 Routers available May 09 14:25:14 cmcam3 sshd[518]: Connection closed by 192.168.86.53 port 58016 [preauth] May 09 14:25:17 cmcam3 systemd[1]: systemd-hostnamed.service: Succeeded. ░░ ``` It seems that /dev/video0 does not exist (ls -lrt /dev/video0 confirms this too) So it seems that the 'new' version is lacking something that the original version has ! I hope this helps. Chris
Author
Owner

@MichaIng commented on GitHub (May 10, 2023):

Did you change something about the camera support settings in raspi-config or in /boot/config.txt directly? Such changes are only effective after reboot, so that would explain your behaviour pretty well.

@MichaIng commented on GitHub (May 10, 2023): Did you change something about the camera support settings in `raspi-config` or in `/boot/config.txt` directly? Such changes are only effective after reboot, so that would explain your behaviour pretty well.
Author
Owner

@ceejayemm commented on GitHub (May 11, 2023):

No changes at all. The reason for the final reboot was that that even after upgrading to the DEV branch and restarting the MotionEye service the web page was that the Admin information page still showed the version as v4.2.1. So I figured a reboot was necessary, after which the web access to the system was not possible.

I have since come across this article:

https://www.linuxquestions.org/questions/linux-newbie-8/missing-dev-video0-261133/

which, towards the end, shows how to recreate /dev/video and it seems to work. However the MotionEye service will still not start due to (taken from journalctl -xe immediately after restarting the MotionEye service):

May 11 09:41:59 cmcam3 systemd[1]: Started motionEye Server.
░░ Subject: A start job for unit motioneye.service has finished successfully
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░ 
░░ A start job for unit motioneye.service has finished successfully.
░░ 
░░ The job identifier is 616.
May 11 09:41:59 cmcam3 sudo[576]: pam_unix(sudo:session): session closed for user root
May 11 09:42:15 cmcam3 meyectl[581]: configure_logging cmd motioneye: False
May 11 09:42:15 cmcam3 meyectl[581]: configure logging to file: None
May 11 09:42:15 cmcam3 meyectl[581]:     INFO: hello! this is motionEye server 0.43.0
May 11 09:42:15 cmcam3 meyectl[581]: CRITICAL: log directory "/var/log" does not exist or is not writable
May 11 09:42:17 cmcam3 systemd[1]: motioneye.service: Main process exited, code=exited, status=255/EXCEPTION

So is the MotionEye service not running as the correct user ?

Chris

@ceejayemm commented on GitHub (May 11, 2023): No changes at all. The reason for the final reboot was that that even after upgrading to the DEV branch and restarting the MotionEye service the web page was that the Admin information page still showed the version as v4.2.1. So I figured a reboot was necessary, after which the web access to the system was not possible. I have since come across this article: https://www.linuxquestions.org/questions/linux-newbie-8/missing-dev-video0-261133/ which, towards the end, shows how to recreate /dev/video and it seems to work. However the MotionEye service will still not start due to (taken from journalctl -xe immediately after restarting the MotionEye service): ``` May 11 09:41:59 cmcam3 systemd[1]: Started motionEye Server. ░░ Subject: A start job for unit motioneye.service has finished successfully ░░ Defined-By: systemd ░░ Support: https://www.debian.org/support ░░ ░░ A start job for unit motioneye.service has finished successfully. ░░ ░░ The job identifier is 616. May 11 09:41:59 cmcam3 sudo[576]: pam_unix(sudo:session): session closed for user root May 11 09:42:15 cmcam3 meyectl[581]: configure_logging cmd motioneye: False May 11 09:42:15 cmcam3 meyectl[581]: configure logging to file: None May 11 09:42:15 cmcam3 meyectl[581]: INFO: hello! this is motionEye server 0.43.0 May 11 09:42:15 cmcam3 meyectl[581]: CRITICAL: log directory "/var/log" does not exist or is not writable May 11 09:42:17 cmcam3 systemd[1]: motioneye.service: Main process exited, code=exited, status=255/EXCEPTION ``` So is the MotionEye service not running as the correct user ? Chris
Author
Owner

@MichaIng commented on GitHub (May 11, 2023):

For the RPi camera module there shouldn't be any additional driver necessary. Can you show me what exactly you did? It might even broke it.

motionEye support is one thing, but getting up the RPi camera as regular V4L2 device with the embedded drivers and raspi-config resp. config.txt definitely works without any additional modification.

@MichaIng commented on GitHub (May 11, 2023): For the RPi camera module there shouldn't be any additional driver necessary. Can you show me what exactly you did? It might even broke it. motionEye support is one thing, but getting up the RPi camera as regular V4L2 device with the embedded drivers and `raspi-config` resp. `config.txt` definitely works without any additional modification.
Author
Owner

@ceejayemm commented on GitHub (May 12, 2023):

I am not using an RPI camera module but an (elderly) external camera with a composite output that then feeds into a nobrand composite to USB adapter. This is the same setup that works with the Python2 version but doesn't appear to work with the DEV branch.

The commands I ran from the article noted above are:

sudo rm /dev/video /dev/video0
sudo mknod /dev/video0 c 81 0
sudo chmod 666 /dev/video0
sudo chgrp video /dev/video0
sudo ln -s /dev/video0 /dev/video

As noted above I am getting a lot of permission errors but the only logging output I can get is via journalctl. I have attached the full output from a recent 'journalctl -xe' command for you to see. None of the normal logs (in /var/log) are available due to these permission errors.

Chris

journalctl.zip

@ceejayemm commented on GitHub (May 12, 2023): I am not using an RPI camera module but an (elderly) external camera with a composite output that then feeds into a nobrand composite to USB adapter. This is the same setup that works with the Python2 version but doesn't appear to work with the DEV branch. The commands I ran from the article noted above are: > sudo rm /dev/video /dev/video0 > sudo mknod /dev/video0 c 81 0 > sudo chmod 666 /dev/video0 > sudo chgrp video /dev/video0 > sudo ln -s /dev/video0 /dev/video As noted above I am getting a lot of permission errors but the only logging output I can get is via journalctl. I have attached the full output from a recent 'journalctl -xe' command for you to see. None of the normal logs (in /var/log) are available due to these permission errors. Chris [journalctl.zip](https://github.com/motioneye-project/motioneye/files/11464657/journalctl.zip)
Author
Owner

@ceejayemm commented on GitHub (May 12, 2023):

As a test I created a new folder '/motioneye' and within that a 'log' subfolder, the ownership of both folders was set to motion:motion. I modified the /etc/motioneye/motioneye.conf to read:

log_path /motioneye/log

and restarted the motioneye service. Lo and behold the service started and remained running, creating a motion.log file in the new location. The web page is available and, after configuring the camera as:

Camera Type: Local V4L2 Cameral
Camera: AV to USB 2.0

I can now see output from the camera. The system is reporting:

motionEye Version: 0.43.0
Motion Version: 4.5.1
OS Version: Raspbian 11

So it would seem is if the reported access problems to the /var/log location can be rectified then this version will work for me.

Chris

@ceejayemm commented on GitHub (May 12, 2023): As a test I created a new folder '/motioneye' and within that a 'log' subfolder, the ownership of both folders was set to motion:motion. I modified the /etc/motioneye/motioneye.conf to read: log_path /motioneye/log and restarted the motioneye service. Lo and behold the service started and remained running, creating a motion.log file in the new location. The web page is available and, after configuring the camera as: Camera Type: Local V4L2 Cameral Camera: AV to USB 2.0 I can now see output from the camera. The system is reporting: motionEye Version: 0.43.0 Motion Version: 4.5.1 OS Version: Raspbian 11 So it would seem is if the reported access problems to the /var/log location can be rectified then this version will work for me. Chris
Author
Owner

@MichaIng commented on GitHub (May 18, 2023):

The steps you did look pretty wrong, I mean you manually remove and create device nodes which is reverted on every reboot and every time a device is detected/attached/removed etc. When you attach a camera, and the kernel does have a matching driver for it, it should be loaded automatically and a device node should be created automatically. If /dev/video0 exists already, it should be named /dev/video1 etc. At least this is how is is/should commonly happen. Also the permissions you apply look strange. You make it world read-writable but then still assign a group, which then has no effect anymore. Also this is something the system should automatically do as of default udev rules, i.e. create a 660 or 664 mode device with video group. And the motion user is member of this group, at least when it is installed a regular way like via APT (which is what the motionEye installer also tries).

The default log directory /var/log/motioneye is automatically created by the systemd unit on service start (if missing) with correct permissions as of this line: github.com/motioneye-project/motioneye@ebf0d58/motioneye/extra/motioneye.systemd (L8)
If you modify that default path, of course you need to manually apply permissions as well.

However, so it does work now without manually hacking the device nodes?

@MichaIng commented on GitHub (May 18, 2023): The steps you did look pretty wrong, I mean you manually remove and create device nodes which is reverted on every reboot and every time a device is detected/attached/removed etc. When you attach a camera, and the kernel does have a matching driver for it, it should be loaded automatically and a device node should be created automatically. If `/dev/video0` exists already, it should be named `/dev/video1` etc. At least this is how is is/should commonly happen. Also the permissions you apply look strange. You make it world read-writable but then still assign a group, which then has no effect anymore. Also this is something the system should automatically do as of default udev rules, i.e. create a `660` or `664` mode device with `video` group. And the `motion` user is member of this group, at least when it is installed a regular way like via APT (which is what the motionEye installer also tries). The default log directory `/var/log/motioneye` is automatically created by the systemd unit on service start (if missing) with correct permissions as of this line: https://github.com/motioneye-project/motioneye/blob/ebf0d58/motioneye/extra/motioneye.systemd#L8 If you modify that default path, of course you need to manually apply permissions as well. However, so it does work now without manually hacking the device nodes?
Author
Owner

@ceejayemm commented on GitHub (May 18, 2023):

I have given up with the python2 / dev mashup and have gone back to basics ( I have however saved this SD card for reference should it be necessary.

I have reflashed a new SD card to Raspberry PI OS Lite 32 bit (May 3rd 2023) and installed the current DEV branch only (as per https://github.com/motioneye-project/motioneye/tree/dev#readme). All hardware is the same as previous attempts. I have NOT made any other changes to the installation but I still cannot access the composite camera on this installation despite choosing:

Camera Type: Local V4L2 Camera
and there being three 'AV to USB2.0' options to choose from under 'Camera'

None of the other 'Camera' options - bcm-2835-codec-decode (6 options) or bcm-2835-isp (10 options) work either.

I now have a log file (/var/log/motioneye/motion.log) and I have uploaded this for you to see. It still seems like this version cannot access the composite to usb adapter that the python2 version can. However using v4l2-ctl gives:

pi@cmcam3:~ $ v4l2-ctl --all -d /dev/video0
Driver Info:
	Driver name      : uvcvideo
	Card type        : AV TO USB2.0
	Bus info         : usb-20980000.usb-1
	Driver version   : 6.1.21
	Capabilities     : 0x84a00001
		Video Capture
		Metadata Capture
		Streaming
		Extended Pix Format
		Device Capabilities
	Device Caps      : 0x04200001
		Video Capture
		Streaming
		Extended Pix Format
Media Driver Info:
	Driver name      : uvcvideo
	Model            : AV TO USB2.0
	Serial           : 20150130
	Bus info         : usb-20980000.usb-1
	Media version    : 6.1.21
	Hardware revision: 0x00000121 (289)
	Driver version   : 6.1.21
Interface Info:
	ID               : 0x03000002
	Type             : V4L Video
Entity Info:
	ID               : 0x00000001 (1)
	Name             : AV TO USB2.0
	Function         : V4L2 I/O
	Flags         : default
	Pad 0x01000007   : 0: Sink
	  Link 0x0200000d: from remote pad 0x100000a of entity 'Processing 2': Data, Enabled, Immutable
Priority: 2
Video input : 0 (Input 1: ok)
Format Video Capture:
	Width/Height      : 480/320
	Pixel Format      : 'YUYV' (YUYV 4:2:2)
	Field             : None
	Bytes per Line    : 960
	Size Image        : 307200
	Colorspace        : sRGB
	Transfer Function : Rec. 709
	YCbCr/HSV Encoding: ITU-R 601
	Quantization      : Default (maps to Limited Range)
	Flags             : 
Crop Capability Video Capture:
	Bounds      : Left 0, Top 0, Width 480, Height 320
	Default     : Left 0, Top 0, Width 480, Height 320
	Pixel Aspect: 1/1
Selection Video Capture: crop_default, Left 0, Top 0, Width 480, Height 320, Flags: 
Selection Video Capture: crop_bounds, Left 0, Top 0, Width 480, Height 320, Flags: 
Streaming Parameters Video Capture:
	Capabilities     : timeperframe
	Frames per second: 30.000 (30/1)
	Read buffers     : 0

The last post to this forum topic may, or may not, be of relevance:

https://superuser.com/questions/1523804/linux-usb-video-capture-issues

Chris

motion.log

@ceejayemm commented on GitHub (May 18, 2023): I have given up with the python2 / dev mashup and have gone back to basics ( I have however saved this SD card for reference should it be necessary. I have reflashed a new SD card to Raspberry PI OS Lite 32 bit (May 3rd 2023) and installed the current DEV branch only (as per https://github.com/motioneye-project/motioneye/tree/dev#readme). All hardware is the same as previous attempts. I have NOT made any other changes to the installation but I still cannot access the composite camera on this installation despite choosing: Camera Type: Local V4L2 Camera and there being three 'AV to USB2.0' options to choose from under 'Camera' None of the other 'Camera' options - bcm-2835-codec-decode (6 options) or bcm-2835-isp (10 options) work either. I now have a log file (/var/log/motioneye/motion.log) and I have uploaded this for you to see. It still seems like this version cannot access the composite to usb adapter that the python2 version can. However using v4l2-ctl gives: ```console pi@cmcam3:~ $ v4l2-ctl --all -d /dev/video0 Driver Info: Driver name : uvcvideo Card type : AV TO USB2.0 Bus info : usb-20980000.usb-1 Driver version : 6.1.21 Capabilities : 0x84a00001 Video Capture Metadata Capture Streaming Extended Pix Format Device Capabilities Device Caps : 0x04200001 Video Capture Streaming Extended Pix Format Media Driver Info: Driver name : uvcvideo Model : AV TO USB2.0 Serial : 20150130 Bus info : usb-20980000.usb-1 Media version : 6.1.21 Hardware revision: 0x00000121 (289) Driver version : 6.1.21 Interface Info: ID : 0x03000002 Type : V4L Video Entity Info: ID : 0x00000001 (1) Name : AV TO USB2.0 Function : V4L2 I/O Flags : default Pad 0x01000007 : 0: Sink Link 0x0200000d: from remote pad 0x100000a of entity 'Processing 2': Data, Enabled, Immutable Priority: 2 Video input : 0 (Input 1: ok) Format Video Capture: Width/Height : 480/320 Pixel Format : 'YUYV' (YUYV 4:2:2) Field : None Bytes per Line : 960 Size Image : 307200 Colorspace : sRGB Transfer Function : Rec. 709 YCbCr/HSV Encoding: ITU-R 601 Quantization : Default (maps to Limited Range) Flags : Crop Capability Video Capture: Bounds : Left 0, Top 0, Width 480, Height 320 Default : Left 0, Top 0, Width 480, Height 320 Pixel Aspect: 1/1 Selection Video Capture: crop_default, Left 0, Top 0, Width 480, Height 320, Flags: Selection Video Capture: crop_bounds, Left 0, Top 0, Width 480, Height 320, Flags: Streaming Parameters Video Capture: Capabilities : timeperframe Frames per second: 30.000 (30/1) Read buffers : 0 ``` The last post to this forum topic may, or may not, be of relevance: https://superuser.com/questions/1523804/linux-usb-video-capture-issues Chris [motion.log](https://github.com/motioneye-project/motioneye/files/11509751/motion.log)
Author
Owner

@MichaIng commented on GitHub (May 21, 2023):

Please assure that RPi camera module support is disabled in raspi-config. And what is the output of:

v4l2-ctl --list-devices
@MichaIng commented on GitHub (May 21, 2023): Please assure that RPi camera _module_ support is disabled in `raspi-config`. And what is the output of: ```sh v4l2-ctl --list-devices ```
Author
Owner

@ceejayemm commented on GitHub (May 21, 2023):

I have made sure that RPi Camera support is turned off in raspi-config via:

3 Interface Options / I1 Legacy Camera

MotioneEye now shows NO cameras available at all now. (when Camera Type is Local v4L2 Camera)

v4l2-ctl --list-devices then gives the following info:

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

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

AV TO USB2.0 (usb-20980000.usb-1):
	/dev/video0
	/dev/video1
	/dev/media3
@ceejayemm commented on GitHub (May 21, 2023): I have made sure that RPi Camera support is turned off in raspi-config via: 3 Interface Options / I1 Legacy Camera MotioneEye now shows NO cameras available at all now. (when Camera Type is Local v4L2 Camera) v4l2-ctl --list-devices then gives the following info: ```console pi@cmcam3:~ $ v4l2-ctl --list-devices bcm2835-codec-decode (platform:bcm2835-codec): /dev/video10 /dev/video11 /dev/video12 /dev/video18 /dev/video31 /dev/media2 bcm2835-isp (platform:bcm2835-isp): /dev/video13 /dev/video14 /dev/video15 /dev/video16 /dev/video20 /dev/video21 /dev/video22 /dev/video23 /dev/media0 /dev/media1 AV TO USB2.0 (usb-20980000.usb-1): /dev/video0 /dev/video1 /dev/media3 ```
Author
Owner

@MichaIng commented on GitHub (May 21, 2023):

3 Interface Options / I1 Legacy Camera

No that is wrong, it needs to be turned off completely. Legacy camera support enables the old CSI camera driver with legacy graphics driver stack etc. I hope with it disabled completely, the first two device batches disappear and only the "AV TO USB2.0" remains.

@MichaIng commented on GitHub (May 21, 2023): ``` 3 Interface Options / I1 Legacy Camera ``` No that is wrong, it needs to be turned off completely. Legacy camera support enables the old CSI camera driver with legacy graphics driver stack etc. I hope with it disabled completely, the first two device batches disappear and only the "AV TO USB2.0" remains.
Author
Owner

@ceejayemm commented on GitHub (May 21, 2023):

Using the latest raspi-config, that was the only option I could find to disable cameras. What should I be using to do as you ask ?

Chris

@ceejayemm commented on GitHub (May 21, 2023): Using the latest raspi-config, that was the only option I could find to disable cameras. What should I be using to do as you ask ? Chris
Author
Owner

@ceejayemm commented on GitHub (May 21, 2023):

BTW the following seems to suggest the PI Camera module IS disabled:

pi@cmcam3:~ $ raspistill -o image.jpg
mmal: Cannot read camera info, keeping the defaults for OV5647
mmal: mmal_vc_component_create: failed to create component 'vc.ril.camera' (1:ENOMEM)
mmal: mmal_component_create_core: could not create component 'vc.ril.camera' (1)
mmal: Failed to create camera component
mmal: main: Failed to create camera component
mmal: Camera is not enabled in this build. Try running "sudo raspi-config" and ensure that "camera" has been enabled

but

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

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

AV TO USB2.0 (usb-20980000.usb-1):
/dev/video0
/dev/video1
/dev/media3

Chris

@ceejayemm commented on GitHub (May 21, 2023): BTW the following seems to suggest the PI Camera module IS disabled: pi@cmcam3:~ $ raspistill -o image.jpg mmal: Cannot read camera info, keeping the defaults for OV5647 mmal: mmal_vc_component_create: failed to create component 'vc.ril.camera' (1:ENOMEM) mmal: mmal_component_create_core: could not create component 'vc.ril.camera' (1) mmal: Failed to create camera component mmal: main: Failed to create camera component mmal: Camera is not enabled in this build. Try running "sudo raspi-config" and ensure that "camera" has been enabled but pi@cmcam3:~ $ v4l2-ctl --list-devices bcm2835-codec-decode (platform:bcm2835-codec): /dev/video10 /dev/video11 /dev/video12 /dev/video18 /dev/video31 /dev/media2 bcm2835-isp (platform:bcm2835-isp): /dev/video13 /dev/video14 /dev/video15 /dev/video16 /dev/video20 /dev/video21 /dev/video22 /dev/video23 /dev/media0 /dev/media1 AV TO USB2.0 (usb-20980000.usb-1): /dev/video0 /dev/video1 /dev/media3 Chris
Author
Owner

@ceejayemm commented on GitHub (Jun 29, 2023):

Any further thoughts ?

Chris

@ceejayemm commented on GitHub (Jun 29, 2023): Any further thoughts ? Chris
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/motioneye#2387
No description provided.