Path: csiph.com!eternal-september.org!feeder.eternal-september.org!nntp.eternal-september.org!.POSTED!not-for-mail From: TheLastSysop Newsgroups: comp.os.linux.misc Subject: Re: Redundancy/Survival Date: Mon, 01 Jun 2026 04:57:37 GMT Organization: The Null Device Restoration Society Lines: 119 Message-ID: <72f72322909b3aee79a4@dev.null> References: <10v55mv$2co0n$1@dont-email.me> <20260526161738.00004146@gmail.com> <10v677l$2jh1c$3@dont-email.me> <10vb4pn$3tios$1@dont-email.me> Injection-Date: Mon, 01 Jun 2026 04:57:38 +0000 (UTC) Injection-Info: dont-email.me; logging-data="2111495"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19D3lq6fKw6LfdIGr8W+MYpOeraEY3XtdU="; posting-host="ba59903ec678904fef4b69d99f9031f0" Cancel-Lock: sha1:2xbF2nEoc1UPEDukzLG6Q7om3JY= sha256:pleN65FCzbcG90dzTD0jhABsd/Yl4LXGRwG0v3G9UCM= sha1:hka941c7AZ6hJdrnFuOkMQ7691o= In-Reply-To: X-Operating-System: TempleOS-adjacent abacus cluster X-Newsreader: tin can + wet string 0.9.7 X-Archive-Policy: please preserve the funny parts X-Mood: reasonably caffeinated Xref: csiph.com comp.os.linux.misc:87323 >On Mon, 1 Jun 2026 00:49:48 -0400, c186282 wrote: >On 5/31/26 03:14, TheLastSysop wrote: >>> On Sun, 31 May 2026 03:10:57 -0400, c186282 wrote: >>> On 5/31/26 01:09, TheLastSysop wrote: >>> >>> Good advice. >>> >>> My humble intent was to just do a still-frame capture >>> every few seconds, re-name and stash somewhere. Easy >>> with lots of webcam apps, but not with ...... >>> >>> I think I *can* do that basic trick now. But do I >>> want to ??? Better off with little web-cams. Look >>> for "Spinel" ... they USED to have a micro-boxed >>> board, but of late only bare boards. Easy to use >>> and cope with and highly sensitive. DID fit one of >>> those microboxes AND a Pi3 into a little weatherproof >>> box ... it's now on a screen porch. IR sensitive >>> [...trimmed...] >>> But all that's a different "survival" theme ... >>> [...trimmed...] >> >> If the goal is only "one JPEG every few seconds", I would skip VLC and the >> streaming path entirely. Let the camera program write stills directly. > > > A very simple Python daemon can do that nicely. > > I have another PI with 'motion' on it, but it's > a Python daemon that grabs a frame and stashes > it (also keeps track of too-old pix). > >> On newer Raspberry Pi OS images the names may be rpicam-* rather than >> libcamera-*; on older ones it is the other way around. So check both: >> >> command -v rpicam-still libcamera-still >> >> The usual package is the Raspberry Pi camera apps package, called rpicam-apps >> on >> newer installs and libcamera-apps on some older ones. >> >> For a simple timed capture, the shape is roughly: >> >> rpicam-still -n -t 0 --timelapse 5000 -o frame%06d.jpg >> >> or, on older installs: >> >> libcamera-still -n -t 0 --timelapse 5000 -o frame%06d.jpg > > Yep, the first one works on my Pi4, most recent distro. > Haven't used the "timelapse" yet however. Resembles > the ffmpeg automatic naming approach (the app may be > BUILT using ffmpeg as its core). > > Still a bit vague on where/how the ribbon-cable cams > deliver stuff. "Network" port - "localhost:1234" ??? > Something weirder ??? Gotta check some more. > >> That avoids preview windows, VNC, h264 elementary streams, and VLC guessing. >> Then a separate cron job or shell loop can move/rename/compress/prune files. >> >> For 1 FPS video without duplicated frames, ffmpeg is often easier if you feed >> it >> an actual 1 FPS image sequence rather than a 30 FPS camera stream, e.g. >> capture >> JPEGs first, then encode the sequence later. That is less elegant, but a lot >> more predictable on small Pis. > > I wrote an app using OpenCV2 commands - can grab webcam frames > at 1 fps and assembles them into (silent) movies. > > Ffmpeg ... had some good experiences and a few bad. The doc > seems all over the place. My final working param set was much > smaller than many of the docs suggested. Do have it making > RTSP movies at 1-fps, resized, but with continuous sound. > Works well EXCEPT kinda in the middle of the day - very odd. > It's almost like somebody subtly screwed up the time calx in > some deep hidden subroutine, the movies almost always > terminate early from about 10am-4pm. > > The trick with movies is keeping the SIZE down. Has to be > enough rez and FPS for 'security' doc purposes, but that > can be less than most think. 2k movies at 30fps and you'll > use up a whole hard disk real quick (and I don't think > a PI has enough speed for that anyway). For the ribbon cable cameras there usually is not a network port involved. They sit on the Pi's CSI connector and the kernel/libcamera stack exposes them locally. So the first sanity check I would do is just: rpicam-hello --list-cameras or, on older installs: libcamera-hello --list-cameras If that sees the module, rpicam-still/rpicam-vid talk to it directly. No localhost:1234 unless you deliberately start some server or streamer on top of it. The old raspistill/raspivid world was different enough that stale web pages can be actively unhelpful here. For USB webcams the path is more like /dev/video*, and then v4l2-ctl is useful: v4l2-ctl --list-devices v4l2-ctl -d /dev/video0 --list-formats-ext For CSI/libcamera cameras, the rpicam/libcamera tools are the better first probe. On the midday ffmpeg weirdness, I would first check whether it is really a clock/time-of-day problem or just the camera/source wedging under heat/light. If the camera is in sun during those hours, thermal throttling, exposure changes, or an RTSP source timeout can look very much like "ffmpeg went odd". A parallel still-image capture during that window is a cheap way to separate camera trouble from encoder trouble. -- TheLastSysop "I survived the great rm -rf / rehearsal and all I got was this .signature."