Hi!
I'm currently running Octoprint 1.6.1 on a Raspberry Pi 3B+
Like many people, I often have problems with my webcam (I have a mystery off brand webcam) that often crashes for no apparent reason.
I do manage to fix it every time by opening Kitty, SSHing into Octoprint and sending:
sudo systemctl restart webcamd
This works great but it's really annoying.
Would it be possible in the webcam window, when you get the information asking you to check that the webcam is connected on the correct path for the streaming device, to get a link to reboot the webcam daemon?
I know it's not an elegant solution but it does have the advantage of being simple.
Thanks
You should be able to add this command as a system command to the menu, in the same place that the standard restart/shutdown/reboot commands. You can follow the docs: config.yaml: system — OctoPrint Documetation
It would mean adding this to config.yaml:
system:
actions:
- name: Restart Webcam
action: restartwebcam
command: sudo systemctl restart webcamd
confirm: You are about to restart the webcam
2 Likes
Thanks!
I for sure am going to try it.
It's really too bad it doesn't come as a built-in feature though...
It's not built in because OctoPrint can run on any Windows, MacOS or Linux computer however you install it. It doesn't deal with webcam streaming itself, just embedding the stream and has no knowledge of the webcam server.
It could come pre-configured as above with the OctoPi image I guess.
I tried that and it worked. Just adding a minute clarification:
From the wording I had somehow assumed to find a system section in the .yaml with entries for restart/shutdown/reboot. Not so.
There is a server: section with similar commands but that was not the place to add an entry. Instead I literally copy-pasted the lines before another section and that did it.
That does make sense...
Windows does handle all the backend stuff by itself in a pretty reliable manner.
Thanks for the tip.
I'm going to work on that today.
But I wonder about one thing: does the config.yaml file get saved when we do a configuration backup?
Those backups are stored as zip archives in ~/.octoprint/data/backup.
I checked it there and the zip contains, among other things, the config.yaml in the subfolder basedir
1 Like
That's fantastic!
Thanks!
OK... Progress and not so progress.
I discovered that for some reason the code doesn't like to be put at the end of the file. So I put it just over the webcam: tag.
Now the web server will start. So I proceeded to test it all by stopping the server in the console and trying to get it restarted. But it gives me this error:
{"error":"Command for custom:restartwebcam failed: 500 Internal Server Error: Command for custom:restartwebcam failed with return code 1:\nSTDOUT: \nSTDERR: sudo: no tty present and no askpass program specified\n"}
mmmm.... what could it all mean?
OK, I think I figured it out. For some reason I had pasted to a different location without noticing it (oops!)
Also, I added the
async: true
function to the command set since the webcam doesn't need to interfere with the other operations.
EDIT 3
I just discovered that Octoprint re-orders the config.yaml file all by itself, so the problem wasn't with my instruction placement but with the missing async tag (I think).
But even with that, it only works about 50% of the time... bummer.
A non-obvious problem are garbage frames which occur when there is too little light. For example in my box I have 4m ledstripes and had problems with my C270 which always "crashes" after a while. After a longer search I found the switch -m and adjusted my config as follows.
camera_usb_options="-r 1280x720 -m 31000 -n -f 30"
Since then the service runs stable.
It might be helpful if the developers would include this switch in the documentation.
My solution was to use mjpg-streamer and just setup a systemd service to start it if it fails without me explicitly stopping it. Here's my /etc/systemd/system/mjpg-streamer.service. Place the file there, run systemctl enable mjpg-streamer and systemctl start mjpg-streamer and you should be fine, even after an uncontrolled reboot.
Systemd is quite simple once you get a hang on it and after that's it's just plug and p[lr]ay 
[Unit]
Description=MJPEG streamer
After=network-online.target
Wants=network-online.target
[Service]
Environment="LC_ALL=C.UTF-8"
Environment="LANG=C.UTF-8"
Type=simple
User=octoprint
ExecStart=mjpg_streamer -i "input_uvc.so -d /dev/video0 -r 1280x720 -f 15" -o "output_http.so -p 8080 -w /usr/local/share/mjpg-streamer/www"
#Restart=on-failure
Restart=always
[Install]
WantedBy=multi-user.target
1 Like
I never thought about that.
Somehow, I'm surprised that the webcam service could be so sensitive to lost frames.
On my last webcam crash, I did notice that the webcam was slightly warm to the touch. I figured that inside the plastic housing, it must be really hot. So I took it apart and drilled some ventilation holes in the case.
I have the feeling that it probably helps to some extent.
I wonder what the -m 31000 and the -n actually do?
Just a warning to add along with this one (and why OctoPi doesn't ship like this) - if your webcam is ever unplugged, then it will be constantly restarting the service which may not be great for resource usage or something. I think systemd allows you to setup restart delays?
It is not the service itself. The service starts and stops mjpg streamer which loads and unloads input_uvc.so and pushes some parameter to it (in my opinion). Take a look here
-m drops frames smaller than that size, and -n means 'no dynamic control', which for some cameras means you have a separate page to access some things like brightness etc.
So essentially it prevents the webcam service from dropping any frames by setting a value that the webcam can't ever reach... sneaky. I love it 