Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.os.linux.misc > #87133 > unrolled thread
| Started by | c186282 <c186282@nnada.net> |
|---|---|
| First post | 2026-05-26 02:21 -0400 |
| Last post | 2026-05-26 17:21 +0200 |
| Articles | 20 on this page of 100 — 16 participants |
Back to article view | Back to comp.os.linux.misc
Redundancy/Survival c186282 <c186282@nnada.net> - 2026-05-26 02:21 -0400
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-05-26 08:46 +0200
Re: Redundancy/Survival Marco Moock <mm@dorfdsl.de> - 2026-05-26 09:49 +0200
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-05-26 04:47 -0400
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-05-26 11:25 +0200
Re: Redundancy/Survival Rich <rich@example.invalid> - 2026-05-26 09:53 +0000
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-05-26 04:38 -0400
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-05-26 11:35 +0200
Re: Redundancy/Survival Rich <rich@example.invalid> - 2026-05-26 22:09 +0000
Re: Redundancy/Survival John Ames <commodorejohn@gmail.com> - 2026-05-26 16:17 -0700
Re: Redundancy/Survival Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-05-27 00:02 +0000
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-05-27 00:11 -0400
Re: Redundancy/Survival Marco Moock <mm@dorfdsl.de> - 2026-05-28 10:32 +0200
Re: Redundancy/Survival Nuno Silva <nunojsilva@invalid.invalid> - 2026-05-27 08:41 +0100
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-05-27 11:04 +0200
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-05-28 03:31 -0400
Re: Redundancy/Survival The Natural Philosopher <tnp@invalid.invalid> - 2026-05-28 09:18 +0100
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-05-28 13:42 +0200
Re: Redundancy/Survival The Natural Philosopher <tnp@invalid.invalid> - 2026-05-28 15:01 +0100
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-05-28 21:34 -0400
Re: Redundancy/Survival The Natural Philosopher <tnp@invalid.invalid> - 2026-05-29 11:07 +0100
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-05-29 12:55 +0200
Re: Redundancy/Survival The Natural Philosopher <tnp@invalid.invalid> - 2026-05-29 12:14 +0100
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-05-29 13:36 +0200
Re: Redundancy/Survival The Natural Philosopher <tnp@invalid.invalid> - 2026-05-29 13:26 +0100
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-05-29 19:36 +0200
Re: Redundancy/Survival Richard Kettlewell <invalid@invalid.invalid> - 2026-05-29 17:24 +0100
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-05-29 19:37 +0200
Re: Redundancy/Survival The Natural Philosopher <tnp@invalid.invalid> - 2026-05-29 19:36 +0100
Re: Redundancy/Survival Richard Kettlewell <invalid@invalid.invalid> - 2026-05-29 22:34 +0100
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-05-30 04:29 -0400
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-05-30 13:09 +0200
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-05-30 23:29 -0400
Re: Redundancy/Survival InterLinked <usenet@phreaknet.org> - 2026-05-31 21:45 -0400
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-06-01 12:15 +0200
Re: Redundancy/Survival Rich <rich@example.invalid> - 2026-05-29 04:30 +0000
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-05-29 01:34 -0400
Re: Redundancy/Survival rbowman <bowman@montana.com> - 2026-05-29 06:36 +0000
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-05-31 00:38 -0400
Re: Redundancy/Survival TheLastSysop <thelastsysop@dev.null> - 2026-05-31 05:09 +0000
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-05-31 03:10 -0400
Re: Redundancy/Survival TheLastSysop <thelastsysop@dev.null> - 2026-05-31 07:14 +0000
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-06-01 00:49 -0400
Re: Redundancy/Survival TheLastSysop <thelastsysop@dev.null> - 2026-06-01 04:57 +0000
Re: Redundancy/Survival Rich <rich@example.invalid> - 2026-06-01 03:20 +0000
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-05-29 02:17 -0400
Re: Redundancy/Survival Rich <rich@example.invalid> - 2026-06-01 03:50 +0000
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-06-01 01:07 -0400
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-06-01 12:47 +0200
Re: Redundancy/Survival The Natural Philosopher <tnp@invalid.invalid> - 2026-06-01 12:26 +0100
Re: Redundancy/Survival not@telling.you.invalid (Computer Nerd Kev) - 2026-05-30 09:09 +1000
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-05-30 13:17 +0200
Re: Redundancy/Survival not@telling.you.invalid (Computer Nerd Kev) - 2026-05-31 07:33 +1000
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-05-31 00:14 -0400
Re: Redundancy/Survival The Natural Philosopher <tnp@invalid.invalid> - 2026-05-31 12:09 +0100
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-06-01 00:51 -0400
Re: Redundancy/Survival The Natural Philosopher <tnp@invalid.invalid> - 2026-06-01 12:28 +0100
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-05-31 12:58 +0200
Re: Redundancy/Survival Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-05-27 20:51 +0000
Re: Redundancy/Survival John Ames <commodorejohn@gmail.com> - 2026-05-27 14:02 -0700
Re: Redundancy/Survival not@telling.you.invalid (Computer Nerd Kev) - 2026-05-28 08:54 +1000
Re: Redundancy/Survival Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-05-28 05:04 +0000
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-05-28 03:54 -0400
Re: Redundancy/Survival Andy Burns <usenet@andyburns.uk> - 2026-05-28 09:15 +0100
Re: Redundancy/Survival Rich <rich@example.invalid> - 2026-06-01 12:29 +0000
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-05-28 13:45 +0200
Re: Redundancy/Survival Robert Riches <spamtrap42@jacob21819.net> - 2026-05-29 02:50 +0000
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-05-29 01:17 -0400
Re: Redundancy/Survival rbowman <bowman@montana.com> - 2026-05-29 06:48 +0000
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-05-30 04:25 -0400
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-05-30 13:20 +0200
Re: Redundancy/Survival Robert Riches <spamtrap42@jacob21819.net> - 2026-05-30 14:16 +0000
Re: Redundancy/Survival Robert Riches <spamtrap42@jacob21819.net> - 2026-05-30 04:00 +0000
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-05-26 23:41 -0400
Re: Redundancy/Survival The Natural Philosopher <tnp@invalid.invalid> - 2026-05-27 14:09 +0100
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-05-28 03:51 -0400
Re: Redundancy/Survival rbowman <bowman@montana.com> - 2026-05-28 17:08 +0000
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-05-28 22:14 -0400
Re: Redundancy/Survival rbowman <bowman@montana.com> - 2026-05-29 04:41 +0000
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-05-29 01:53 -0400
Re: Redundancy/Survival rbowman <bowman@montana.com> - 2026-05-29 06:32 +0000
Re: Redundancy/Survival Rich <rich@example.invalid> - 2026-06-01 13:19 +0000
Re: Redundancy/Survival Rich <rich@example.invalid> - 2026-06-01 13:08 +0000
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-05-26 22:39 -0400
Re: Redundancy/Survival The Natural Philosopher <tnp@invalid.invalid> - 2026-05-27 14:10 +0100
Re: Redundancy/Survival not@telling.you.invalid (Computer Nerd Kev) - 2026-05-28 09:05 +1000
Re: Redundancy/Survival The Natural Philosopher <tnp@invalid.invalid> - 2026-05-28 08:19 +0100
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-05-28 03:52 -0400
Re: Redundancy/Survival The Natural Philosopher <tnp@invalid.invalid> - 2026-05-28 09:20 +0100
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-05-28 20:34 -0400
Re: Redundancy/Survival InterLinked <usenet@phreaknet.org> - 2026-05-28 21:07 -0400
Re: Redundancy/Survival Rich <rich@example.invalid> - 2026-06-01 13:40 +0000
Re: Redundancy/Survival rbowman <bowman@montana.com> - 2026-05-29 01:21 +0000
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-05-29 02:08 -0400
Re: Redundancy/Survival rbowman <bowman@montana.com> - 2026-05-29 06:41 +0000
Re: Redundancy/Survival Rich <rich@example.invalid> - 2026-06-01 13:23 +0000
Re: Redundancy/Survival Marco Moock <mm@dorfdsl.de> - 2026-05-26 09:44 +0200
Re: Redundancy/Survival c186282 <c186282@nnada.net> - 2026-05-26 04:45 -0400
Re: Redundancy/Survival "Carlos E.R." <robin_listas@es.invalid> - 2026-05-26 11:38 +0200
Re: Redundancy/Survival "Worst Case" <fritz@spamexpire-202605.rodent.frell.theremailer.net> - 2026-05-26 17:21 +0200
Page 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →
| From | c186282 <c186282@nnada.net> |
|---|---|
| Date | 2026-05-31 03:10 -0400 |
| Message-ID | <mRWdnVk6O9iPQob3nZ2dnZfqnPSdnZ2d@giganews.com> |
| In reply to | #87302 |
On 5/31/26 01:09, TheLastSysop wrote: >> On Sun, 31 May 2026 00:38:01 -0400, c186282 <c186282@nnada.net> wrote: >> On 5/29/26 02:36, rbowman wrote: >> >> DID used to know Code ... but that was a LONG time ago. >> >> But, if NECESSARY, could RE-learn it. >> >> A fuzzily-tuned spark gap transmitter might >> be good fun :-) >> >> Ah, DID finally get ONE (of four) PiCams to >> work. Couldn't get three to even acknowledge >> their existence. The working one - PART of >> the problem was trying to do "rpi-still" >> over a VNC connection ... it didn't like that, >> can't entirely cope with a virtual screen. >> [...trimmed...] >> into the trash (KEPT the cord though). >> [...trimmed...] > > If you want to keep using the CSI Pi camera, I would avoid trying to make the > raw h264 stream look like a webcam and instead put a thin server in front of it. 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 24/7 ... I *like* the weird colors ! Also made a sunrise/sunset daemon that adjusts the video params at the right time every day. Similar on several units. > A safe first check is whether the current stack sees the camera at all: > > libcamera-hello --list-cameras For three out of four - it DIDN'T see the cams reliably. ONE registered as "there", but you couldn't get any video from it no matter what. Kinda wasted a lot of money ... > For a quick LAN stream, something like this on the Pi is usually simpler than > fighting VNC preview windows: > > libcamera-vid -t 0 --inline --listen -o tcp://0.0.0.0:8888 Yea, tried that today - UDP and TCP. However VLC could not cope with that. It WAS getting data, but NO visual regardless. > Then on another box, tell VLC what it is receiving rather than letting it guess: > > vlc tcp/h264://PI_ADDRESS:8888 External boxes, maybe tomorrow's project. Gotta keep the brain busy. Hey, it's 2:30 AM now, been busy for a LONG time :-) > If you need RTSP/MJPEG because other software expects it, put mediamtx, > GStreamer, or ffmpeg between libcamera and the clients. That also keeps the Pi > Zero usable, since the camera capture stays local and the network side can be > made as dumb as possible. FFMPEG is the best documented and most capable. However, as noted in this group, I've also had lots of weird problems with it. Basically I have to take those UDP/TCP h264 streams and create jpg and/or mjpeg. Have another app that captures RTSP and, correctly, creates a 1-FPS movie. The "rpi-vid" whatever can't actually cope with creating a proper 1-FPS video. "Correctly" means it doesn't have 29 identical frames every second - ergo I can create very compact vids WITH SOUND from one of my front-door prox IP cams. Ffmpeg CAN do wonders IF you can find the exact combo of params. Took awhile. > Also worth checking: the older raspistill/raspivid tools and the newer > libcamera/rpicam tools are not interchangeable on recent Raspberry Pi OS images. > Mixing examples from the two eras causes a lot of false trails. ALL I've seen is 'rpi-still'/'rpi-jpeg'/'rpi-vid'. Some sites talk about 'libcamera' stuff - but there's nada. What is Where ... seems to move back and forth between distro versions, often. Anyway, will probably abandon the ribbon-cable cameras because they're SUCH a pain. Now gotta find USB connectors that aren't two+ inches long, will fit in a tiny box. What's the point in a little board if it has BIG connectors sticking out in every direction ??? One of the most useful video pgms is 'motion'. Alas they changed the config files considerably of late, so beware of older doc. Easily creates mjpeg streams and CAN do movie segments, though not with as much control as a custom app. Create most ALL my security cam stuff using 'motion' as the base. Hey, keeps the old brain busy !!! Now almost 3am ... STILL messing with this stuff. (also it's still over 80F ... my A/C is old and clunky, BIG $$$ to replace all that ! Electricians, permits maybe, yikes !!!) Note my house is early 1950s ... a pill-box that's wiring UN-friendly. Will need an extension box for 100 amps, new conduit/wires, what a PAIN ! And in the meanwhile ... COOK. I have some fans, but there are limits. As you get older there's LESS tolerance for cold and heat alas. Hawaii would be nice, but insanely expensive (and Obama is there !). But all that's a different "survival" theme ...
[toc] | [prev] | [next] | [standalone]
| From | TheLastSysop <thelastsysop@dev.null> |
|---|---|
| Date | 2026-05-31 07:14 +0000 |
| Message-ID | <a016d2f635d3ff34ea5d@dev.null> |
| In reply to | #87305 |
>On Sun, 31 May 2026 03:10:57 -0400, c186282 <c186282@nnada.net> 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.
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
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.
--
TheLastSysop <thelastsysop@dev.null>
"I survived the great rm -rf / rehearsal and all I got was this .signature."
[toc] | [prev] | [next] | [standalone]
| From | c186282 <c186282@nnada.net> |
|---|---|
| Date | 2026-06-01 00:49 -0400 |
| Message-ID | <bIScnQabw7vhkoD3nZ2dnZfqnPidnZ2d@giganews.com> |
| In reply to | #87306 |
On 5/31/26 03:14, TheLastSysop wrote: >> On Sun, 31 May 2026 03:10:57 -0400, c186282 <c186282@nnada.net> 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).
[toc] | [prev] | [next] | [standalone]
| From | TheLastSysop <thelastsysop@dev.null> |
|---|---|
| Date | 2026-06-01 04:57 +0000 |
| Message-ID | <72f72322909b3aee79a4@dev.null> |
| In reply to | #87321 |
>On Mon, 1 Jun 2026 00:49:48 -0400, c186282 <c186282@nnada.net> wrote:
>On 5/31/26 03:14, TheLastSysop wrote:
>>> On Sun, 31 May 2026 03:10:57 -0400, c186282 <c186282@nnada.net> 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 <thelastsysop@dev.null>
"I survived the great rm -rf / rehearsal and all I got was this .signature."
[toc] | [prev] | [next] | [standalone]
| From | Rich <rich@example.invalid> |
|---|---|
| Date | 2026-06-01 03:20 +0000 |
| Message-ID | <10vitqf$1us3j$1@dont-email.me> |
| In reply to | #87260 |
c186282 <c186282@nnada.net> wrote: > I've EXPERIENCED tower networks Going DOWN ... they have maybe > three days worth of power backup. Then it's 1826 again. > > But copper KEEPS WORKING. Simple and sure. Check that bet one winter when the ice storms pull down the mains cables powering your local copper exchange, and the snow is deep enough that the fuel trucks can't get to the exchange before its backup generators consume the diesel in their tanks. The copper *will* also stop working then as well. It only appears to keep working because there were several layers of redundancy backed in by the regulations. But those regulations are being sidelined now. Without those regulations keeping the companies honest, the old POTS that "just kept working" almost all the time will become just as flakey and offline at the slightest provocation as the other options. A *lot* of expense was spent to make the old copper POTS just "keep working", not a bit of it "just working" was because it was "copper". It was all because the companies operating it were kept whipped into shape by the regulators and forced to pay for the upkeep needed. If you applied the identical regulations to fiber, it too would (and could) be just as much a "it KEEPS WORKING" system as the old copper POTS system was. All the fiber would need to be all but identical is for a pair of power conductors (yes copper wires, since glass happens to be an electrical insulator) to be run along with each bundle, and for the demarc terminals in each home (plus one of the phone handsets) to be powered from the fiber bundle power conductors. The magic that made copper POTS just "keep working" was the strict regulations surrounding it, not the fact that it was copper. > Should add "alt.survival" to the groups ..... Please don't. All that does is bring in a bunch of trolls.
[toc] | [prev] | [next] | [standalone]
| From | c186282 <c186282@nnada.net> |
|---|---|
| Date | 2026-05-29 02:17 -0400 |
| Message-ID | <97OcnWwzhIQAsoT3nZ2dnZfqnPSdnZ2d@giganews.com> |
| In reply to | #87255 |
Argue crap all you want - the providers are generally REQUIRED to keep the POTS running and I support that. Note the theme here - "Redundancy". Keep EVERYTHING that worked. Add on new stuff all you want, but ..... Use the Laws. Hire class-action lawyers if needed to kick ass. Oh, and even TELEGRAPH service should be preserved over a few copper lines. Slow, but WORKED and was very robust. First comm network that could use pre-Tube/Transistor amplifiers ... just relays. Edison figured out how to record the traffic even as a youth. On the whole, "new" is MUCH more technically complicated at every level. That complication means MANY more ways for it to FAIL. OK ... believable ... North Korea sets off several EMP bombs high over the USA. ALL the 'complicated' tech immediately DIES for a LONG time. So HOW do you call an ambulance ? Your bank ? You AREN'T ... unless we've maintained some lower-tech REDUNDANCY.
[toc] | [prev] | [next] | [standalone]
| From | Rich <rich@example.invalid> |
|---|---|
| Date | 2026-06-01 03:50 +0000 |
| Message-ID | <10vivi4$1us3j$2@dont-email.me> |
| In reply to | #87265 |
c186282 <c186282@nnada.net> wrote: > Argue crap all you want - the providers are > generally REQUIRED to keep the POTS running > and I support that. And there you are slowly beginning to maybe see why POTS service was mostly "always working". The "providers are generally required" part is why. > OK ... believable ... North Korea sets off > several EMP bombs high over the USA. ALL the > 'complicated' tech immediately DIES for a > LONG time. Sadly, I have bad news for you. Your wonderful copper POTS line that begins at the side of your house, and travels however far from pole to pole to reach you local telephone switch, well, guess what it connects to at that switch now in 2026? The old electromechanical step-by-step switches, or electromechanical crossbar switches? Nope. Those were, mostly, long gone by the early 70's. It connects to...... a modern digitizer that digitizes the signals on the line, and the entire rest of the switch, in 2026, is a fancy computer system (usually running Erlang) that routes digital bits and bytes around. Guess what happens to those digital computer switches should that EMP be exploded? While you /might/ have 48v of power on the line, for a while (until the diesel generators run out of fuel) you won't have any communications, because *everything* after your copper wires terminate at the local switch is, and has been since the early 70's, essentially VOIP service now (not literally VOIP, but digital networking and/or digital computerized circuit switching (i.e. ATM)).
[toc] | [prev] | [next] | [standalone]
| From | c186282 <c186282@nnada.net> |
|---|---|
| Date | 2026-06-01 01:07 -0400 |
| Message-ID | <bIScnQGbw7sQjoD3nZ2dnZfqnPidnZ2d@giganews.com> |
| In reply to | #87318 |
On 5/31/26 23:50, Rich wrote: > c186282 <c186282@nnada.net> wrote: >> Argue crap all you want - the providers are >> generally REQUIRED to keep the POTS running >> and I support that. > > And there you are slowly beginning to maybe see why POTS service was > mostly "always working". The "providers are generally required" part > is why. > >> OK ... believable ... North Korea sets off >> several EMP bombs high over the USA. ALL the >> 'complicated' tech immediately DIES for a >> LONG time. > > Sadly, I have bad news for you. Your wonderful copper POTS line that > begins at the side of your house, and travels however far from pole to > pole to reach you local telephone switch, well, guess what it connects > to at that switch now in 2026? > > The old electromechanical step-by-step switches, or electromechanical > crossbar switches? Nope. Those were, mostly, long gone by the early > 70's. Saw 'em in action, late 60s. Neat ! > It connects to...... a modern digitizer that digitizes the signals on > the line, and the entire rest of the switch, in 2026, is a fancy > computer system (usually running Erlang) that routes digital bits and > bytes around. > > Guess what happens to those digital computer switches should that EMP > be exploded? > > While you /might/ have 48v of power on the line, for a while (until the > diesel generators run out of fuel) you won't have any communications, > because *everything* after your copper wires terminate at the local > switch is, and has been since the early 70's, essentially VOIP service > now (not literally VOIP, but digital networking and/or digital > computerized circuit switching (i.e. ATM)). Well, if the digital stuff fries they can STILL manually connect at least a sub-portion of the copper. Most tech fried ... hey ... telegraphy works :-) Simple relay-based line amps. Worked in 1850 and can work now over remaining POTS lines. Find a neighborhood 'telegraph guy'.
[toc] | [prev] | [next] | [standalone]
| From | "Carlos E.R." <robin_listas@es.invalid> |
|---|---|
| Date | 2026-06-01 12:47 +0200 |
| Message-ID | <ni40fmxe5o.ln2@Telcontar.valinor> |
| In reply to | #87324 |
On 2026-06-01 07:07, c186282 wrote: > On 5/31/26 23:50, Rich wrote: >> c186282 <c186282@nnada.net> wrote: >>> Argue crap all you want - the providers are >>> generally REQUIRED to keep the POTS running >>> and I support that. >> >> And there you are slowly beginning to maybe see why POTS service was >> mostly "always working". The "providers are generally required" part >> is why. >> >>> OK ... believable ... North Korea sets off >>> several EMP bombs high over the USA. ALL the >>> 'complicated' tech immediately DIES for a >>> LONG time. >> >> Sadly, I have bad news for you. Your wonderful copper POTS line that >> begins at the side of your house, and travels however far from pole to >> pole to reach you local telephone switch, well, guess what it connects >> to at that switch now in 2026? >> >> The old electromechanical step-by-step switches, or electromechanical >> crossbar switches? Nope. Those were, mostly, long gone by the early >> 70's. > > Saw 'em in action, late 60s. Neat ! > >> It connects to...... a modern digitizer that digitizes the signals on >> the line, and the entire rest of the switch, in 2026, is a fancy >> computer system (usually running Erlang) that routes digital bits and >> bytes around. >> >> Guess what happens to those digital computer switches should that EMP >> be exploded? >> >> While you /might/ have 48v of power on the line, for a while (until the >> diesel generators run out of fuel) you won't have any communications, >> because *everything* after your copper wires terminate at the local >> switch is, and has been since the early 70's, essentially VOIP service >> now (not literally VOIP, but digital networking and/or digital >> computerized circuit switching (i.e. ATM)). > > Well, if the digital stuff fries they can STILL > manually connect at least a sub-portion of the > copper. Manually? You need an expert to go in the exchange and rewire the cables to connect two phones permanently. Maybe, because the batteries are the wrong voltage. Certainly no dialing. > > Most tech fried ... hey ... telegraphy works :-) > Simple relay-based line amps. Worked in 1850 and > can work now over remaining POTS lines. Find a > neighborhood 'telegraph guy'. > -- Cheers, Carlos. ES🇪🇸, EU🇪🇺;
[toc] | [prev] | [next] | [standalone]
| From | The Natural Philosopher <tnp@invalid.invalid> |
|---|---|
| Date | 2026-06-01 12:26 +0100 |
| Message-ID | <10vjq9l$26505$2@dont-email.me> |
| In reply to | #87324 |
On 01/06/2026 06:07, c186282 wrote: > Most tech fried ... hey ... telegraphy works 🙂 It didnt. Neither did electrical power cables. Underound fibre might -- "What do you think about Gay Marriage?" "I don't." "Don't what?" "Think about Gay Marriage."
[toc] | [prev] | [next] | [standalone]
| From | not@telling.you.invalid (Computer Nerd Kev) |
|---|---|
| Date | 2026-05-30 09:09 +1000 |
| Message-ID | <6a1a1c98@news.ausics.net> |
| In reply to | #87255 |
Rich <rich@example.invalid> wrote: > c186282 <c186282@nnada.net> wrote: >> Kind of agree with the sentiment that copper should always be at >> hand for 'emergency' communications at a minimum. Towers die, cell >> contracts expire, copper keeps on going. > > The legacy copper phones only "kept on going" because POTS (copper) > phone service was a highly regulated utility with requirements for > upkeep and maintence so that it /would/ just keep on going. > > Without that upkeep, it eventually falls into disrepair and stops > working just like the rest. You bet, that's my POTS line here in Australia described exactly. Even though I just learnt our government is paying $270 million a year to maintain it (on top of the fees paid by customers) in places not connected to fibre or "fixed wireless" internet. Money straight into the telco's profits, no doubt. The exchanges even look abandoned now with peeling paint etc. > It's only real difference from towers is fewer possibilities to go > wrong when the 'system' is just a long pair of copper wires vs. complex > electronics systems for a radio tower (i.e., no capicators to dry out > and fail in a long pair of copper wires). Most failures were > mechanical (something physically tearing down the wires) or chemical > (water infiltration corroding the connection points). Well here it's almost always the exchange that keeps going wrong. Then they take between a few days to a few weeks to fix it, which I think just means how long until someone gets around to visiting it. Someone said they're required to fix it within 24 hours, but if that's true then they're completely ignoring that. > But fail it did. If the lines were above ground then tree branches (or > automobiles) would take out the lines. If the lines were underground > then water infiltration into the conduits would result in noise or > nothing working. I had this one myself on my pair once. Line that had > been nice and quiet (and worked well for DSL) suddenly sounded like > someone was scraping a turntable needle over a vinyl record constantly. > Reported it to Verizon, they took some time to fix, but I eventually > learned the cause was an underground wiring vault a couple miles away > had flooded. Yeah my old line rotted away completely after it was noisy for years and they switched me to a spare which also gets noisy when the ground's wet, but since we haven't had decent rainfall for years that hasn't been a problem lately. Since that line switch ~5+ years ago I only had one other line fault late last year when the council slashing grass on the roadsides cut the line. Amazingly that _was_ fixed within about 24 hours, though when the exchange died yet again later that week affecting everyone using it rather than just people down my road, it took them 4-5 days to fix it. And the exchange breaks far more frequently, in fact it was breaking every time there was a power failure for a year or so, but it does seem to be surviving those these days (except the obviously-dead battery there means you still can't make calls while the power's off anymore). > But your individual experience dependend upon what happened with your > specific pair. If you were lucky and no falling trees, drunk drivers, > or ice storms happened to pull down your copper pair, and no leaky > underground conduits soaked it, then to you it appeared to be > impervious to failure. Reality from the other size (the phone company) > viewpoint is that something, somewhere, was always failing and needing > repair. So apparantly our largest telco decided to just send the government the bill, then it eventually realised the government didn't notice/care anymore if they didn't fix things quickly or properly in return for that money anyway. Then they stopped mobile phones working properly here as well when they turned off 3G... -- __ __ #_ < |\| |< _#
[toc] | [prev] | [next] | [standalone]
| From | "Carlos E.R." <robin_listas@es.invalid> |
|---|---|
| Date | 2026-05-30 13:17 +0200 |
| Message-ID | <ojtqemx854.ln2@Telcontar.valinor> |
| In reply to | #87286 |
On 2026-05-30 01:09, Computer Nerd Kev wrote: > Rich <rich@example.invalid> wrote: >> c186282 <c186282@nnada.net> wrote: >>> Kind of agree with the sentiment that copper should always be at >>> hand for 'emergency' communications at a minimum. Towers die, cell >>> contracts expire, copper keeps on going. >> >> The legacy copper phones only "kept on going" because POTS (copper) >> phone service was a highly regulated utility with requirements for >> upkeep and maintence so that it /would/ just keep on going. >> >> Without that upkeep, it eventually falls into disrepair and stops >> working just like the rest. > > You bet, that's my POTS line here in Australia described exactly. > Even though I just learnt our government is paying $270 million a > year to maintain it (on top of the fees paid by customers) in > places not connected to fibre or "fixed wireless" internet. Money > straight into the telco's profits, no doubt. The exchanges even > look abandoned now with peeling paint etc. > >> It's only real difference from towers is fewer possibilities to go >> wrong when the 'system' is just a long pair of copper wires vs. complex >> electronics systems for a radio tower (i.e., no capicators to dry out >> and fail in a long pair of copper wires). Most failures were >> mechanical (something physically tearing down the wires) or chemical >> (water infiltration corroding the connection points). > > Well here it's almost always the exchange that keeps going > wrong. Then they take between a few days to a few weeks to fix it, > which I think just means how long until someone gets around to > visiting it. Someone said they're required to fix it within 24 > hours, but if that's true then they're completely ignoring that. Someone visiting, finding someone that knows those exchanges (all old people and running out), then finding the spares of abandoned technology, shipping them... > >> But fail it did. If the lines were above ground then tree branches (or >> automobiles) would take out the lines. If the lines were underground >> then water infiltration into the conduits would result in noise or >> nothing working. I had this one myself on my pair once. Line that had >> been nice and quiet (and worked well for DSL) suddenly sounded like >> someone was scraping a turntable needle over a vinyl record constantly. >> Reported it to Verizon, they took some time to fix, but I eventually >> learned the cause was an underground wiring vault a couple miles away >> had flooded. > > Yeah my old line rotted away completely after it was noisy for > years and they switched me to a spare which also gets noisy when > the ground's wet, but since we haven't had decent rainfall for > years that hasn't been a problem lately. Since that line switch > ~5+ years ago I only had one other line fault late last year when > the council slashing grass on the roadsides cut the line. Amazingly > that _was_ fixed within about 24 hours, though when the exchange > died yet again later that week affecting everyone using it rather > than just people down my road, it took them 4-5 days to fix it. And > the exchange breaks far more frequently, in fact it was breaking > every time there was a power failure for a year or so, but it does > seem to be surviving those these days (except the obviously-dead > battery there means you still can't make calls while the power's > off anymore). Those exchanges are not designed to suffer a sudden power off. And rebooting is not automatic, it takes a human with special knowledge to do it, because it is something done once in life. > >> But your individual experience dependend upon what happened with your >> specific pair. If you were lucky and no falling trees, drunk drivers, >> or ice storms happened to pull down your copper pair, and no leaky >> underground conduits soaked it, then to you it appeared to be >> impervious to failure. Reality from the other size (the phone company) >> viewpoint is that something, somewhere, was always failing and needing >> repair. > > So apparantly our largest telco decided to just send the government > the bill, then it eventually realised the government didn't > notice/care anymore if they didn't fix things quickly or properly > in return for that money anyway. Then they stopped mobile phones > working properly here as well when they turned off 3G... > -- Cheers, Carlos. ES🇪🇸, EU🇪🇺;
[toc] | [prev] | [next] | [standalone]
| From | not@telling.you.invalid (Computer Nerd Kev) |
|---|---|
| Date | 2026-05-31 07:33 +1000 |
| Message-ID | <6a1b57c6@news.ausics.net> |
| In reply to | #87291 |
Carlos E.R. <robin_listas@es.invalid> wrote: > On 2026-05-30 01:09, Computer Nerd Kev wrote: >> Yeah my old line rotted away completely after it was noisy for >> years and they switched me to a spare which also gets noisy when >> the ground's wet, but since we haven't had decent rainfall for >> years that hasn't been a problem lately. Since that line switch >> ~5+ years ago I only had one other line fault late last year when >> the council slashing grass on the roadsides cut the line. Amazingly >> that _was_ fixed within about 24 hours, though when the exchange >> died yet again later that week affecting everyone using it rather >> than just people down my road, it took them 4-5 days to fix it. And >> the exchange breaks far more frequently, in fact it was breaking >> every time there was a power failure for a year or so, but it does >> seem to be surviving those these days (except the obviously-dead >> battery there means you still can't make calls while the power's >> off anymore). > > Those exchanges are not designed to suffer a sudden power off. And > rebooting is not automatic, it takes a human with special knowledge to > do it, because it is something done once in life. That seems highly unlikely (more of your AI 'wisdom'?). These exchanges are tiny huts littered throughout regional Australia, and the last mechanical exchange was converted in the 1990s. If someone designed their electronic exchange equipment to require manual reset after power-off, they must have been nuts. In any case if they replaced the battery, which used to work, it wouldn't get powered off by every short blackout. -- __ __ #_ < |\| |< _#
[toc] | [prev] | [next] | [standalone]
| From | c186282 <c186282@nnada.net> |
|---|---|
| Date | 2026-05-31 00:14 -0400 |
| Message-ID | <mRWdnVw6O9g4KIb3nZ2dnZfqnPSdnZ2d@giganews.com> |
| In reply to | #87294 |
On 5/30/26 17:33, Computer Nerd Kev wrote: > Carlos E.R. <robin_listas@es.invalid> wrote: >> On 2026-05-30 01:09, Computer Nerd Kev wrote: >>> Yeah my old line rotted away completely after it was noisy for >>> years and they switched me to a spare which also gets noisy when >>> the ground's wet, but since we haven't had decent rainfall for >>> years that hasn't been a problem lately. Since that line switch >>> ~5+ years ago I only had one other line fault late last year when >>> the council slashing grass on the roadsides cut the line. Amazingly >>> that _was_ fixed within about 24 hours, though when the exchange >>> died yet again later that week affecting everyone using it rather >>> than just people down my road, it took them 4-5 days to fix it. And >>> the exchange breaks far more frequently, in fact it was breaking >>> every time there was a power failure for a year or so, but it does >>> seem to be surviving those these days (except the obviously-dead >>> battery there means you still can't make calls while the power's >>> off anymore). >> >> Those exchanges are not designed to suffer a sudden power off. And >> rebooting is not automatic, it takes a human with special knowledge to >> do it, because it is something done once in life. > > That seems highly unlikely (more of your AI 'wisdom'?). These > exchanges are tiny huts littered throughout regional Australia, and > the last mechanical exchange was converted in the 1990s. If someone > designed their electronic exchange equipment to require manual > reset after power-off, they must have been nuts. In any case if > they replaced the battery, which used to work, it wouldn't get > powered off by every short blackout. I do appreciate the "cutting grass" story ... in my case some distracted teen driver CRASHED into the big distro box down on the street corner, blacked out a quarter of the county :-) STILL think at least one layer of backwards compatible comm tech SHOULD be *mandated*. Fuck how much it costs AT&T or whomever (will also keep more humans employed). The big-L Libertarian perspective is good, but 'community utility' is also good. The best track is usually somewhere in-between. There ARE lawyers who live on 'class action' lawsuits to be found ... and the "Disabilities Act", which by default includes most "older people" like me, CAN be applied. IF they ever cut my land line it's gonna cost them a lot more than they thought they were saving. This is how it has to be. Corp -vs- Citizen IS often a sort of 'war' alas. Callous/hurtful extremes of 'capitalism' AND 'socialism' have to be combatted. I agree with Ferris Bueler ... "-Isms are bad" :-
[toc] | [prev] | [next] | [standalone]
| From | The Natural Philosopher <tnp@invalid.invalid> |
|---|---|
| Date | 2026-05-31 12:09 +0100 |
| Message-ID | <10vh4tk$1fsuq$2@dont-email.me> |
| In reply to | #87298 |
On 31/05/2026 05:14, c186282 wrote: > STILL think at least one layer of backwards compatible > comm tech SHOULD be *mandated*. I hadn't penned you for a Libral... They use words like 'should', and 'mandated'... -- For in reason, all government without the consent of the governed is the very definition of slavery. Jonathan Swift
[toc] | [prev] | [next] | [standalone]
| From | c186282 <c186282@nnada.net> |
|---|---|
| Date | 2026-06-01 00:51 -0400 |
| Message-ID | <aqCcneAQrL5skoD3nZ2dnZfqnPadnZ2d@giganews.com> |
| In reply to | #87315 |
On 5/31/26 07:09, The Natural Philosopher wrote: > On 31/05/2026 05:14, c186282 wrote: >> STILL think at least one layer of backwards compatible >> comm tech SHOULD be *mandated*. > > I hadn't penned you for a Libral... > > They use words like 'should', and 'mandated'... Um ... think "national security" - which SHOULD transcend 'right'/'left'/LP/etc. And yea, I meant *mandated*.
[toc] | [prev] | [next] | [standalone]
| From | The Natural Philosopher <tnp@invalid.invalid> |
|---|---|
| Date | 2026-06-01 12:28 +0100 |
| Message-ID | <10vjqdk$26505$3@dont-email.me> |
| In reply to | #87322 |
On 01/06/2026 05:51, c186282 wrote: > On 5/31/26 07:09, The Natural Philosopher wrote: >> On 31/05/2026 05:14, c186282 wrote: >>> STILL think at least one layer of backwards compatible >>> comm tech SHOULD be *mandated*. >> >> I hadn't penned you for a Libral... >> >> They use words like 'should', and 'mandated'... > > Um ... think "national security" - which SHOULD > transcend 'right'/'left'/LP/etc. > Always the last refuge of the fascist > And yea, I meant *mandated*. > Why would I think you didnt? -- "What do you think about Gay Marriage?" "I don't." "Don't what?" "Think about Gay Marriage."
[toc] | [prev] | [next] | [standalone]
| From | "Carlos E.R." <robin_listas@es.invalid> |
|---|---|
| Date | 2026-05-31 12:58 +0200 |
| Message-ID | <irgtemxmjm.ln2@Telcontar.valinor> |
| In reply to | #87294 |
On 2026-05-30 23:33, Computer Nerd Kev wrote: > Carlos E.R. <robin_listas@es.invalid> wrote: >> On 2026-05-30 01:09, Computer Nerd Kev wrote: >>> Yeah my old line rotted away completely after it was noisy for >>> years and they switched me to a spare which also gets noisy when >>> the ground's wet, but since we haven't had decent rainfall for >>> years that hasn't been a problem lately. Since that line switch >>> ~5+ years ago I only had one other line fault late last year when >>> the council slashing grass on the roadsides cut the line. Amazingly >>> that _was_ fixed within about 24 hours, though when the exchange >>> died yet again later that week affecting everyone using it rather >>> than just people down my road, it took them 4-5 days to fix it. And >>> the exchange breaks far more frequently, in fact it was breaking >>> every time there was a power failure for a year or so, but it does >>> seem to be surviving those these days (except the obviously-dead >>> battery there means you still can't make calls while the power's >>> off anymore). >> >> Those exchanges are not designed to suffer a sudden power off. And >> rebooting is not automatic, it takes a human with special knowledge to >> do it, because it is something done once in life. > > That seems highly unlikely (more of your AI 'wisdom'?). First hand knowledge, just not of AU. > These > exchanges are tiny huts littered throughout regional Australia, and > the last mechanical exchange was converted in the 1990s. If someone > designed their electronic exchange equipment to require manual > reset after power-off, they must have been nuts. In any case if > they replaced the battery, which used to work, it wouldn't get > powered off by every short blackout. > -- Cheers, Carlos. ES🇪🇸, EU🇪🇺;
[toc] | [prev] | [next] | [standalone]
| From | Charlie Gibbs <cgibbs@kltpzyxm.invalid> |
|---|---|
| Date | 2026-05-27 20:51 +0000 |
| Message-ID | <FPIRR.2$XSac.0@fx03.iad> |
| In reply to | #87185 |
On 2026-05-27, Nuno Silva <nunojsilva@invalid.invalid> wrote: > On 2026-05-27, Charlie Gibbs wrote: > >> On 2026-05-26, John Ames <commodorejohn@gmail.com> wrote: >> >>> On Tue, 26 May 2026 22:09:35 -0000 (UTC) >>> Rich <rich@example.invalid> wrote: >>> >>>> In the US, the ulterior motive actually appears to be the fact that >>>> POTS service is regulated (price regulated and availability >>>> requirements regulated) whereas the "new fangled" fiber services are >>>> free of those pesky requirements for requesting price increases or >>>> being required to provide a particular availably (uptime) level. >>> >>> Well *that* explains a lot :/ >> >> Yup. Our telco (Telus) had a really big push to convert everyone >> to fiber. Now we too can enjoy loss of dial tone when the power >> goes out. > > POTS has in a way always seemed a sensible option to still have > everywhere for certain emergencies, in fact perhaps households should > always have access to such a line even without contracting any service, > for stuff like 112. > > But that also requires that the handset is fully capable of operating > only with the line power. You mean like they all used to do? I still have a couple around here somewhere. Too bad our telco recently "upgraded" us to VoIP phones... -- /~\ Charlie Gibbs | Growth for the sake of \ / <cgibbs@kltpzyxm.invalid> | growth is the ideology X I'm really at ac.dekanfrus | of the cancer cell. / \ if you read it the right way. | -- Edward Abbey
[toc] | [prev] | [next] | [standalone]
| From | John Ames <commodorejohn@gmail.com> |
|---|---|
| Date | 2026-05-27 14:02 -0700 |
| Message-ID | <20260527140256.00006742@gmail.com> |
| In reply to | #87201 |
On Wed, 27 May 2026 20:51:49 GMT Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote: > > But that also requires that the handset is fully capable of > > operating only with the line power. > > You mean like they all used to do? I still have a couple around here > somewhere. Too bad our telco recently "upgraded" us to VoIP phones... I think the implication was that, e.g., digital cordless handsets are useless without power, even in a POTS setup - which *is* true, but that was so all through the '90s - '00s and it was no great hassle to keep an old Bakelite number in another room of the house or dig it outta the closet in the event of an outage.
[toc] | [prev] | [next] | [standalone]
Page 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →
Back to top | Article view | comp.os.linux.misc
csiph-web