Issue with Logitech C270

**I'll follow up with the appropriate log information, I've determined how to get that information to a USB drive and to my computer for attachment **

Camera model

Logitech 860-000270 V-U0018

What is the problem?

When the Octopi is booted with the camera attached, the video image is garbled.

What did you already try to solve it?

If I boot Octopi, and wait for it to complete boot up, plug in the webcam, then load OctoPrint, I can get a a good image on Octoprint.

I have not connected a printer to the pi yet.

edited /boot/octopi.txt and added -r 1280x720 -f 30 per the webcam FAQ but it didn't solve the issue. Using a 2A power supply because I initially got a low voltage warning on boot up with another p/s.

Logs (/var/log/webcamd.log, syslog, dmesg, ... no logs, no support)

I can SSH into the octopi with Terminal and see & read the file contents. This is the file from Octoprint:

browser.user_agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_6) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0.3 Safari/605.1.15
connectivity.connection_check: 8.8.8.8:53
connectivity.connection_ok: true
connectivity.enabled: true
connectivity.online: true
connectivity.resolution_check: octoprint.org
connectivity.resolution_ok: true
env.hardware.cores: 4
env.hardware.freq: 900
env.hardware.ram: 915730432
env.os.bits: 32
env.os.id: linux
env.os.platform: linux
env.plugins.pi_support.model: Raspberry Pi 2 Model B Rev 1.1
env.plugins.pi_support.octopi_version: 0.18.0
env.plugins.pi_support.throttle_state: 0x50005
env.python.pip: 20.3.3
env.python.version: 3.7.3
env.python.virtualenv: true
octoprint.safe_mode: false
octoprint.version: 1.5.3

The ready-to-go Raspberry Pi image with OctoPrint

Version 0.18.0, running on Raspberry Pi 2 Model B Rev 1.1

The snappy web interface for your 3D printer

Version 1.5.3

Additional information about your setup (OctoPrint version, OctoPi version, ...)

Does that also happen if no other usb device (like your printer) is connected?

Yes. I haven't even connected a printer yet. Stock sw, no plugins. Worked first to get the Rpi connected to the network, then the camera & remote login. Easier to do everything in stages, solve one problem at a time. I also edited /boot/octopi.txt and added -r 1280x720 -f 30 per the webcam FAQ but it didn't solve the issue, went back and commented that line out. Using a 2A power supply because I initially got a low voltage warning on boot up with another p/s. Not sure if the screen shot will make it with this post.

Alright.

Let's check if a simple restart of the webcam service helps
log in via ssh and run
sudo service webcamd restart

if that doesn't help you could try to restart the usb ports
compile this GitHub - mvp/uhubctl: uhubctl - USB hub per-port power control utility
(how to compile it)
and use uhubctl -l 1-1 -p 2 -a 0 to disable the ports and uhubctl -l 1-1 -p 2 -a 1 to enable them again.

I gave that a try and the problem still persists. Here's a link to the log files. Same situation, if I connect the camera after it boots, the image is good to go. I have a powered USB hub that I may try just to make sure. The power cube says its rated at 2A and the camera says it draws 500ma.
ETA leaving the Pi connected to it's own power supply and using a 2.5A powered hub to power the camera made no difference so it's not a power problem. Unplugging and plugging the cam while the system is up just kills the webcam stream entirely. I have to shutdown and reboot then reconnect the camera once Octopi is running. Thats both using the USB hub or direct to the pi.

https://drive.google.com/drive/folders/1euUgtLC2vL0WDxT6lE4PPYnm8S5PGuR9?usp=sharing

When did you create the dmesg log?
you got an undervolting warning in it
10.570315] Under-voltage detected! (0x00050005)
sometimes the usb controller does weird stuff when the pi got power issues.

You should try to fix that first

also the driver of the wifi card is spamming an error


[  246.164881] rtl_usb: Pending RX skbuff queue full! (qlen: 64)
[  246.164929] rtl_usb: Pending RX skbuff queue full! (qlen: 64)
[  246.165008] rtl_usb: Pending RX skbuff queue full! (qlen: 64)
[  246.165076] rtl_usb: Pending RX skbuff queue full! (qlen: 64)
[  246.165166] rtl_usb: Pending RX skbuff queue full! (qlen: 64)
[  246.165211] rtl_usb: Pending RX skbuff queue full! (qlen: 64)
[  246.165278] rtl_usb: Pending RX skbuff queue full! (qlen: 64)
[  246.165340] rtl_usb: Pending RX skbuff queue full! (qlen: 64)
[  246.165409] rtl_usb: Pending RX skbuff queue full! (qlen: 64)
[  246.165470] rtl_usb: Pending RX skbuff queue full! (qlen: 64)
[  246.165532] rtl_usb: Pending RX skbuff queue full! (qlen: 64)
[  246.165618] rtl_usb: Pending RX skbuff queue full! (qlen: 64)
[  246.165664] rtl_usb: Pending RX skbuff queue full! (qlen: 64)

not sure if it could be related

The low voltage & probably the spamming appears to have been the USB cable. I swapped power supplies, WiFi dongles, even swapped another Pi, finally the cable. I've uploaded two new dmesg files. One booting with the camera connected and one without. The problem still persists. I can plug the cam in after booting and all is well but it won't boot with the cam connected without the video being distorted. Nothing other than the wifi dongle & cam connected to the Pi.

Sorry then I'm out of ideas :man_shrugging:

If nobody else comes up with another idea, I would suggest you try it in the raspberry forums.

Where is the cable routed? I had issues, not quite the same but it was interference because the c270 cable was alongside either a power or motor cable.

1 Like

Everything is just wide open on the bench, nothing around it to cause interference, nothing zip-tied together. Disconnected everything except the cam & Edimax wifi dongle. Others have had a similar issue, found this link, haven't dug into it further.

I’m going to give this a try next

I tried burning a new OctoPi 0.18.0 image straight from the url with Balena. Issue persists. I even made sure the very first boot was done with the camera connected.

Some additional information that might be helpful?
The (distorted image)results of the grep with the cam connected on boot:
636 pts/0 S+ 0:00 grep --color=auto mjpg-streamer

The (functioning cam) results after booting and then connecting the cam: 2038 pts/0 S+ 0:00 grep --color=auto mjpg-streamer

Also stumbled on this Alternate USB cam daemon

@PrintedWeezl

I am seeing the same problem with my C270 from time to time on bootup. For me rebooting the whole system from the Octoprint interface has resolved the issue every time. I once tried manually restarting the camera stream from ssh connect and that worked, too.

Thanks, gave that a try several times but no luck. Tried entire system, just Octoprint and Safe mode. I'm wondering if not having the printer connected is the issue, been trying to debug one issue at a time.

ETA If I cold boot cam connected, then SSH and sudo service webcamd restart Then refresh the octopi.local page it comes up fine. I can almost live with that. I'm guessing that the reason this didn't work in the beginning is due to the wifi adapter spamming & low voltage error in the original thread above and I never went back and tried the restart again. Is there a way to do the webcamd restart at the very end of the cold boot? Or add a delay? @Twilek @PrintedWeezl

I posted something similar about adding a delay here:

1 Like

Gave that a try, adding just one line at a time but no luck. Here's the Dmesg after both those lines added.

dmesg.txt.zip (8.2 KB)

I edited the config.yaml file to restart webcamd at the very end but it had no effect. I ran v4l2-ctl -all before and after restarting webcamd and comparing the values and the only difference was the gain and white balance were slightly different values. All other values were the same.

I ordered a new C270 to try and that solved the problem. The previous one was 3-5 years old so there is some subtle difference between them and there is no firmware to update with this model. It works fine on Mac OS & Win 10 so it can be used elsewhere.

1 Like

I'm actually trying to figure out why my webcamd takes the parameters for my C270 -r 1280x720 -f 10 -vf and then reports an error after

Jun 22 00:35:24 octopi webcamd[17384]: libv4l2: error setting pixformat: Device or resource busy
Jun 22 00:35:24 octopi webcamd[17384]: Unable to set format: 1196444237 res: 1280x720

Wondering if any of you have similar issues getting your C270 to go higher than 640x480.


In any case, I have an alternate solution for this problem which involves running a script to check the image, perhaps this can save someone some money and keep an old C270 from the dumpster:

#!/usr/bin/env bash

# Deftdawg's webcam-checker script
#
# This script detects when the Logitech C270 Webcam has failed to initialize and if needed restarts it.
#
# How it works:
# 1. Take snapshot JPG from the webcam
# 2. Attempt to gzip the snapshot JPG
# 3. If the compression ratio exceeds 50%, assume b/w static and restart webcamd
#
# Recommeded Usage:
# 1. Copy script to /home/pi/webcam-checker.sh and make executable (chmod +x)
# 2. Create a root crontab (sudo crontab -e) with the following job details:
#   * *   *   *   *   /home/pi/webcam-checker.sh | logger -t webcam-checker

# set -x
export TEST_URI='http://127.0.0.1:8080/?action=snapshot'
export TEST_FILE=/tmp/octopi-test.jpg
export TEST_TIMEOUT=5

curl --max-time ${TEST_TIMEOUT} --connect-timeout ${TEST_TIMEOUT} -s $TEST_URI > $TEST_FILE && \
( \
 [ $(du -k $TEST_FILE|cut -f1) -gt 50 ] \
 && [ $(gzip -fk $TEST_FILE; gunzip -l $TEST_FILE.gz | tail -1 | grep -oE '\w+\.\w%' | cut -d\. -f1) -gt 30 ] \
 && (date >> /tmp/restart-static; killall -9 mjpg_streamer) \
 || echo >/dev/null \
) \
|| ( \
    (date > /tmp/restart-timeout; systemctl restart webcamd.service) \
   )

I'm fine with this setting:
camera_usb_options="-r 1280x720 -m 31000 -n -f 30"
The C270 needs a lof of light so with my printerbox with 4m ledstripe i have to block gargage frames (-m).

Thanks I got it sorted.

Had to put my config in /boot/octopi.txt, not /boot/octopi.conf.d/test.txt, I thought /boot/octopi.conf.d/*.txt should work but it tries to use /dev/video0 for octopi.txt and /dev/video1+ for *.txt

Then took me 2 days to figure out how to flip the camera 180 (c270 is missing the v4l2-ctl to do it in hardware).