DEV Community: Super Funicular

((count++)) Stopped My Clip Counter Under set -e Before It Printed a Line: Bash Arithmetic Returns 1 on Zero

Super Funicular — Thu, 05 Nov 2026 19:54:14 +0000

A small Bash script counts the camera clips in a folder before a nightly job moves them. It has set -e at the top, a counter that starts at zero, and ((count++)) inside the loop. Pointed at a folder of three clips, it printed nothing at all and exited with status 1. Not one counted line, not the total, not an error message.

Here is the script:

#!/usr/bin/env bash
set -e
count=0
for f in clips/*.mp4; do
  ((count++))
  echo "counted $f"
done
echo "clips: $count"

And here is what it did, first as written and then with only the set -e line taken out:

mkdir -p clips
touch clips/clip_01.mp4 clips/clip_02.mp4 clips/clip_03.mp4
echo "== with set -e"
bash count.sh
echo "exit status: $?"
echo "== same script, set -e line removed"
grep -v '^set -e$' count.sh > count_no_e.sh
bash count_no_e.sh
echo "exit status: $?"

== with set -e
exit status: 1
== same script, set -e line removed
counted clips/clip_01.mp4
counted clips/clip_02.mp4
counted clips/clip_03.mp4
clips: 3
exit status: 0

Without set -e it counts all three clips and exits 0. With it, the script stops before its first echo, on the line that adds one to the counter.

Disclosure: I make an Android camera app. Nothing below uses its code or describes how it records or stores anything. The clips here are empty files made with touch and head, and every output is pasted from the scripts shown. Versions:

GNU bash, version 5.1.16(1)-release (aarch64-unknown-linux-gnu)
stat (GNU coreutils) 8.32

What the manual says `(( ))` returns

((count++)) is not an assignment statement in the way count=1 is. It is the arithmetic command, and the Bash manual gives it an exit status based on the value of the expression. From the entry for (( expression )) in Conditional Constructs: "If the value of the expression is non-zero, the return status is 0; otherwise the return status is 1."

The value of count++ is the value of count before it goes up. On the first trip through the loop that value is 0, so the command returns 1, even though it did its job and count is now 1. set -e sees a command that returned 1 and stops the script.

I checked that directly, without set -e, printing the status after each form:

#!/usr/bin/env bash
count=0
((count++)); echo "count++ from 0: status $?, count now $count"
((count++)); echo "count++ from 1: status $?, count now $count"
count=0
((++count)); echo "++count from 0: status $?, count now $count"
total=0; size=0
((total += size)); echo "total += 0 from 0: status $?, total now $total"
let "total += size"; echo "let total += 0 from 0: status $?"

count++ from 0: status 1, count now 1
count++ from 1: status 0, count now 2
++count from 0: status 0, count now 1
total += 0 from 0: status 1, total now 0
let total += 0 from 0: status 1

Three things in that output matter for a clip script:

Post-increment from 0 returns 1. The variable still goes up. The status reports the old value, not whether the increment worked.
The second time, it returns 0. Once count is 1, count++ has the value 1, which is non-zero. So the failure is only ever on the first increment, which is why the script died before printing anything.
+= with a zero result returns 1 too, and so does let. Pre-increment ++count from 0 has the value 1 and returns 0.

Why it printed nothing

set -e stops the script quietly. There is no message saying which line failed. The status is 1, the same status a script returns for many other kinds of failure, so a cron log or a wrapper that only records the exit status shows a job that failed with no clue as to why.

An ERR trap makes the line visible. This is the same counter with one line added:

#!/usr/bin/env bash
set -e
trap 'echo "ERR: status $? at line $LINENO: $BASH_COMMAND" >&2' ERR
count=0
for f in clips/*.mp4; do
  ((count++))
  echo "counted $f"
done
echo "clips: $count"

bash trap.sh
echo "exit status: $?"

ERR: status 1 at line 6: ((count++))
exit status: 1

The trap fired on line 6, ((count++)), with status 1. If a script with set -e exits 1 and prints nothing useful, a trap like this one is a quick way to find out which command it stopped on before you start reading the logic.

The version that only fails on some nights

The counter fails every time, which at least makes it easy to notice the first time you run it. Adding up file sizes with += is worse, because whether it fails depends on the files.

This script totals the bytes in a folder of clips. Recorders that stop mid-write can leave a clip of 0 bytes behind, so the test sets up two nights with the same two clips in a different order: one where the empty clip sorts first, and one where it sorts second.

#!/usr/bin/env bash
set -e
total=0
for f in "$1"/*.mp4; do
  size=$(stat -c %s "$f")
  ((total += size))
  echo "$f: $size bytes"
done
echo "total: $total bytes"

mkdir -p nightA nightB
: > nightA/clip_01.mp4
head -c 5000 /dev/zero > nightA/clip_02.mp4
head -c 5000 /dev/zero > nightB/clip_01.mp4
: > nightB/clip_02.mp4
for night in nightA nightB; do
  echo "== $night"
  bash bytes.sh "$night"
  echo "exit status: $?"
done

== nightA
exit status: 1
== nightB
nightB/clip_01.mp4: 5000 bytes
nightB/clip_02.mp4: 0 bytes
total: 5000 bytes
exit status: 0

On nightA the empty clip comes first. total is 0, size is 0, total += size has the value 0, the command returns 1, and the script stops without printing a line. On nightB the empty clip comes second. By then total is already 5000, so total += 0 has the value 5000, the command returns 0, and the script finishes normally with the right total.

Same script, same two files, and whether it exits 1 depends on which file the glob happens to list first. A test folder without an empty file at the front will pass every time.

What I changed, and what each fix covers

I tried the fixes people usually reach for, all under set -e:

#!/usr/bin/env bash
set -e
a=0; ((++a));            echo "((++a)):            a=$a"
b=0; b=$((b + 1));       echo "b=\$((b + 1)):       b=$b"
c=0; ((c++)) || true;    echo "((c++)) || true:    c=$c"
t=0; t=$((t + 0));       echo "t=\$((t + 0)):       t=$t"
v=0; ((v += 0)) || true; echo "((v += 0)) || true: v=$v"
n=0; if ((n > 0)); then echo "if: n is positive"; else echo "if ((n > 0)) with n=0: took the else branch"; fi
echo "fixes.sh reached its last line"

bash fixes.sh
echo "exit status: $?"

((++a)):            a=1
b=$((b + 1)):       b=1
((c++)) || true:    c=1
t=$((t + 0)):       t=0
((v += 0)) || true: v=0
if ((n > 0)) with n=0: took the else branch
fixes.sh reached its last line
exit status: 0

Every line ran and the script reached its end. They do not all fix the same thing, though:

((++a)) works for a counter that starts at 0, because the value after the increment is 1. It does nothing for += with a zero amount, and a counter that starts below zero can still land on 0.
|| true keeps the script running, but it throws the status away completely. If the arithmetic itself is wrong, the line now fails silently in the other direction.
b=$((b + 1)) and t=$((t + 0)) are ordinary assignments. The arithmetic happens inside an expansion, and under set -e the script carried on past both, including the one whose result was 0.
if ((n > 0)) with n at 0 took the else branch and the script kept going. As the test of an if, a status of 1 means false, which is what the arithmetic command is good at.

For the byte total, the assignment form is the one I kept:

#!/usr/bin/env bash
set -e
total=0
for f in "$1"/*.mp4; do
  size=$(stat -c %s "$f")
  total=$((total + size))
  echo "$f: $size bytes"
done
echo "total: $total bytes"

for night in nightA nightB; do
  echo "== $night"
  bash bytes_fixed.sh "$night"
  echo "exit status: $?"
done

== nightA
nightA/clip_01.mp4: 0 bytes
nightA/clip_02.mp4: 5000 bytes
total: 5000 bytes
exit status: 0
== nightB
nightB/clip_01.mp4: 5000 bytes
nightB/clip_02.mp4: 0 bytes
total: 5000 bytes
exit status: 0

Both nights now finish with the same total and exit 0.

A short checklist for clip scripts with `set -e`

Search the script for (( and let. Any line where the expression can be 0 will stop a set -e script, whether or not the arithmetic did what you meant.
Counters starting at 0 with count++ fail on the first item every time. Totals with += fail when the first value is 0, which depends on the data.
Prefer x=$((x + n)) for counting and totals, so the line's status says nothing about the number.
Keep (( )) for conditions, like if ((count > 0)), where a status of 1 is supposed to mean false.
Test with an empty file at the front of the folder, not only with clips that all have something in them.
Add an ERR trap while debugging, so a silent exit says which line it stopped on.

Things I did not test

Other Bash versions. I ran 5.1. The quote is from the current online manual, and what I ran matched it, but I did not try a newer or older Bash.
Other shells. (( )) and let are not POSIX sh. I did not test how dash, zsh or ksh treat them, or whether their set -e behaves the same way.
The exceptions to set -e. The shell does not stop on every failing command; a status inside an if, while or && list is handled differently. I tested a plain (( )) line, the || true form and one if above, and did not test while, until or && lists.
Real clips. The files here are empty or filled with zero bytes. The arithmetic does not care what is inside a clip, but I did not run this against a folder from a real recorder.

Sources. The quote is from the GNU Bash Reference Manual page Conditional Constructs (the (( expression )) entry). Outputs are pasted unedited from the scripts above.

If you want an old Android phone recording in the background so there is a folder of clips for a script like this to count, the app I make is Background Camera RemoteStream on Google Play. Nothing above depends on it.

In a script that stops on any non-zero status, an arithmetic line reports the number it produced, so the safe place for counting is an assignment, where the status belongs to the line and not to the total.

Six Camera Clips, Three in the Archive, Every mv Exited 0: Testing Same-Name Moves From Two Folders

Super Funicular — Thu, 05 Nov 2026 13:55:07 +0000

Two phones recording into two folders will sooner or later produce two clips with the same name. I set that up on purpose, with three clips in each folder named the same way, and moved everything into one archive folder four ordinary ways. Three of them ended with three clips in the archive instead of six, and every mv in those three exited 0.

The one form that refused to lose anything was the one that looks the least careful: a single mv with both folders on one command line. Below are the test scripts, what each one printed, what the GNU coreutils manual says about -n, -i and --backup, where this old mv and the current manual disagree about exit status, and the version of the move I would run instead.

Disclosure: I make an Android camera app. Nothing below uses its code or describes how it names or stores clips. The clips here are one-line text files made on a Linux machine, and every output is pasted from the scripts shown. Versions:

GNU bash, version 5.1.16(1)-release (aarch64-unknown-linux-gnu)
mv (GNU coreutils) 8.32
PRETTY_NAME="Ubuntu 22.04.5 LTS"

The setup

Each test starts from the same two folders. The first line of every clip says which camera recorded it, so the archive can be checked by reading it rather than by trusting a count.

# Two cameras, same clip names, one archive folder.
# Each clip's first line says which camera recorded it.
setup() {
  rm -rf cam1 cam2 archive
  mkdir cam1 cam2 archive
  for n in 0001 0002 0003; do
    printf 'cam1 clip %s\n' "$n" > "cam1/clip_$n.mp4"
    printf 'cam2 clip %s\n' "$n" > "cam2/clip_$n.mp4"
  done
}
report() {
  echo "archive: $(ls archive | wc -l) files," \
       "left in cam1: $(ls cam1 | wc -l), cam2: $(ls cam2 | wc -l)"
  head -q -n 1 archive/*
}

One mv, both folders

. ./setup.sh; setup
mv cam1/*.mp4 cam2/*.mp4 archive/
echo "exit $?"
report

mv: will not overwrite just-created 'archive/clip_0001.mp4' with 'cam2/clip_0001.mp4'
mv: will not overwrite just-created 'archive/clip_0002.mp4' with 'cam2/clip_0002.mp4'
mv: will not overwrite just-created 'archive/clip_0003.mp4' with 'cam2/clip_0003.mp4'
exit 1
archive: 3 files, left in cam1: 0, cam2: 3
cam1 clip 0001
cam1 clip 0002
cam1 clip 0003

GNU mv noticed that the second clip_0001.mp4 would land on a file it had created moments earlier in the same command, refused, said so three times and exited 1. Nothing was lost: the cam2 clips stayed where they were. As far as I can tell from the outputs, this check only covers files the same mv command just moved there. The next two tests are what happens without it.

One mv per camera

. ./setup.sh; setup
mv cam1/*.mp4 archive/; echo "cam1 exit $?"
mv cam2/*.mp4 archive/; echo "cam2 exit $?"
report

cam1 exit 0
cam2 exit 0
archive: 3 files, left in cam1: 0, cam2: 0
cam2 clip 0001
cam2 clip 0002
cam2 clip 0003

Same clips, same destination, split into two commands. Both exited 0. The archive holds three files, both camera folders are empty, and every surviving clip is from cam2. The cam1 recordings were replaced, with no message.

A loop, one mv per clip

. ./setup.sh; setup
for f in cam1/*.mp4 cam2/*.mp4; do
  mv "$f" archive/
done
echo "loop exit $?"
report

loop exit 0
archive: 3 files, left in cam1: 0, cam2: 0
cam2 clip 0001
cam2 clip 0002
cam2 clip 0003

This is the shape most scripts take, because a loop is where you add logging, skip partial files or build names. Same result as the previous test: three clips survive, all from cam2, and the loop exits 0. Nothing in the output says three recordings are gone.

What the manual says

The GNU coreutils manual's page for mv describes the three options a script would reach for here.

On -n: "Do not overwrite an existing file; silently fail instead."

On -i: "Prompt whether to overwrite each existing destination file, regardless of its permissions, and fail if the response is not affirmative."

On --backup: "Make a backup of each file that would otherwise be overwritten or removed."

And at the bottom: "An exit status of zero indicates success, and a nonzero value indicates failure."

The page I read is the current online manual. The mv I tested is coreutils 8.32, the one Ubuntu 22.04 ships, and the next two tests are where those two differ.

mv -n

. ./setup.sh; setup
mv -n cam1/*.mp4 archive/; echo "cam1 exit $?"
mv -n cam2/*.mp4 archive/; echo "cam2 exit $?"
report

cam1 exit 0
cam2 exit 0
archive: 3 files, left in cam1: 0, cam2: 3
cam1 clip 0001
cam1 clip 0002
cam1 clip 0003

-n protected the archive: the three cam1 clips are intact. It also left the three cam2 clips sitting in their folder and exited 0 both times. On this version it is silent, as described, but the exit status does not report a failure. A script that checks $? after mv -n and then empties or deletes the source folder would be deleting the cam2 clips, which exist nowhere else.

The current manual points to --update=none as the replacement for -n, which "will skip existing files but not fail", and describes a none-fail value where "any skipped files are diagnosed and induce a failure." This mv does not have either:

. ./setup.sh; setup
mv cam1/*.mp4 archive/
mv --update=none cam2/*.mp4 archive/; echo "cam2 exit $?"

mv: option '--update' doesn't allow an argument
Try 'mv --help' for more information.
cam2 exit 1

So a script written against the current manual will stop with a usage error on an older system, and a script written for the older system gets a different exit status from -n on a newer one. If you rely on the exit status of -n, check which version is on the machine that runs the job.

mv -i with nobody at the keyboard

A nightly job has no terminal. Standard input here comes from /dev/null, standing in for a job with no one to answer.

. ./setup.sh; setup
mv cam1/*.mp4 archive/
mv -i cam2/*.mp4 archive/ < /dev/null; rc=$?; echo
echo "cam2 exit $rc"
report

mv: overwrite 'archive/clip_0001.mp4'? mv: overwrite 'archive/clip_0002.mp4'? mv: overwrite 'archive/clip_0003.mp4'? 
cam2 exit 0
archive: 3 files, left in cam1: 0, cam2: 3
cam1 clip 0001
cam1 clip 0002
cam1 clip 0003

mv printed three prompts, read no answer, skipped all three and exited 0. The archive is safe and the cam2 clips are left behind, same as -n. The manual says -i should fail when the answer is not yes; on 8.32 the skip happened and the failure did not.

mv --backup=numbered

. ./setup.sh; setup
mv --backup=numbered cam1/*.mp4 archive/; echo "cam1 exit $?"
mv --backup=numbered cam2/*.mp4 archive/; echo "cam2 exit $?"
report
ls archive

cam1 exit 0
cam2 exit 0
archive: 6 files, left in cam1: 0, cam2: 0
cam2 clip 0001
cam1 clip 0001
cam2 clip 0002
cam1 clip 0002
cam2 clip 0003
cam1 clip 0003
clip_0001.mp4
clip_0001.mp4.~1~
clip_0002.mp4
clip_0002.mp4.~1~
clip_0003.mp4
clip_0003.mp4.~1~

All six clips are in the archive. The cam1 clips were renamed to clip_0001.mp4.~1~ and so on, and the cam2 clips took the plain names. Nothing was lost, and both commands exited 0, which is correct here because nothing failed. The cost is that anything downstream that looks for *.mp4 will not see the backups, so half the footage is there but invisible to a job that globs on the extension.

What I would run instead

The clips collide because the camera folder is part of the identity and the move throws it away. Keeping it in the name removes the collision instead of choosing a winner:

. ./setup.sh; setup
for f in cam1/*.mp4 cam2/*.mp4; do
  cam=${f%%/*}            # cam1
  name=${f##*/}           # clip_0001.mp4
  mv -n "$f" "archive/${cam}_$name"
done
report
ls archive

archive: 6 files, left in cam1: 0, cam2: 0
cam1 clip 0001
cam1 clip 0002
cam1 clip 0003
cam2 clip 0001
cam2 clip 0002
cam2 clip 0003
cam1_clip_0001.mp4
cam1_clip_0002.mp4
cam1_clip_0003.mp4
cam2_clip_0001.mp4
cam2_clip_0002.mp4
cam2_clip_0003.mp4

Six files, every first line matches its name, both folders empty. I kept -n in the loop as a second line of defence, in case a rerun meets a clip that is already in the archive.

The other thing I would add to any move like this, whatever the naming, is a count that has to balance:

. ./setup.sh; setup
before=$(ls cam1/*.mp4 cam2/*.mp4 | wc -l)
for f in cam1/*.mp4 cam2/*.mp4; do
  mv "$f" archive/
done
after=$(ls archive | wc -l)
echo "before $before, after $after"
if [ "$before" -ne "$after" ]; then
  echo "MISMATCH: $((before - after)) clips missing" >&2
  exit 1
fi

bash 09_count.sh; echo "script exit $?"

before 6, after 3
MISMATCH: 3 clips missing
script exit 1

That is the plain loop from earlier, unchanged, with a check around it. It does not save the clips; it turns three missing recordings into a non-zero exit and a line on standard error, which is the part the earlier tests did not produce. A count only proves the numbers match, not that the right files arrived, so on footage I care about I would also compare names, or checksums, before removing anything from the source.

What I would check in an existing job

Find every move or copy into a shared folder and ask whether two sources can produce the same file name. Two cameras, two days with a counter that resets, or a phone reset that restarts numbering will all do it.
Run the job once on purpose against two folders whose clips share names. Read the first line or a checksum of what survives, not the count.
If the script uses mv -n or mv -i, do not treat exit 0 as proof that everything moved. On coreutils 8.32 both returned 0 with files left behind.
Check the version on the machine that runs the job before relying on --update=none or the exit status of -n.
Make an imbalance fail loudly, with a count or a manifest, before anything deletes or clears the source.

What I did not test

Newer coreutils. I only ran 8.32. I have not run the current release, so I have not confirmed that its -n or -i exits non-zero where 8.32 exited 0; the manual says they fail, and I am reporting the manual, not a test.
Moves across file systems. Every test here moved within one disk, where mv renames. Across disks it copies and then deletes, and I did not test whether anything above changes.
BSD and BusyBox mv. macOS and many small Linux images ship a different mv, and the just-created check and the option names may differ.
cp. It shares most of these options, but none of the outputs above are from cp.

Sources. Quotes about -n, -i, --backup, --update and exit status are from the GNU coreutils manual, mv: Move (rename) files. Outputs are pasted unedited from the scripts shown.

If you want an old Android phone recording in the background so there is a folder of clips for a job like this to move, the app I make is Background Camera RemoteStream on Google Play. Nothing above depends on it.

Before a job moves clips from more than one folder into one place, give it two folders with matching file names and read what survives, because a per-folder or per-file mv replaces the earlier clip and still exits 0.

Why Does My Phone Camera's Live Stream Stop After a Few Hours on Mobile Data? The 1.5 GB/Day Limit and the 64 Kbps Speed After It

Super Funicular — Thu, 05 Nov 2026 08:13:39 +0000

You set up an old phone as a camera for the shop or the house. It streams to YouTube Live over a prepaid SIM. It works in the evening. By the early morning the stream is frozen or gone, but the phone is still on, still charging, and the data icon still shows 4G.

On many prepaid plans the reason is the daily data limit. On a plan that says "1.5 GB/day", the data does not stop when the 1.5 GB is used. It gets slow. This guide explains what that means for a phone camera, how many hours of streaming a daily pack really covers, and how to set up the camera so the important hours are not the ones that get cut.

It is written for budget and older Android phones on prepaid data, the usual setup in India, Bangladesh and many other markets. The plan figures below come from Jio's own help pages, read on 5 November 2026. Your operator and plan may differ, so check your plan's own wording (the next section shows where to look).

Why does my phone camera stream stop after a few hours on mobile data?

Short answer: the plan's daily high-speed data ran out, and the speed dropped below what a live stream needs.

Jio's ₹319 plan is a good example. Its help page lists the benefits as:

Data - 1.5 GB/day (thereafter @ 64 Kbps)

The words to look for are "thereafter @ 64 Kbps". After the daily 1.5 GB, the connection keeps working, but at 64 kilobits per second. That is enough for a chat message. It is not enough for video.

YouTube's own table of live encoder settings gives the minimum bitrate for an H.264 stream at 360p or 480p, 30 fps, as 0.4 Mbps (400 Kbps). That is the lowest row in the whole table. 720p needs a minimum of 3 Mbps.

So after the daily limit:

64 Kbps is 6.25 times less than YouTube's lowest H.264 minimum (400 ÷ 64).
If you also send audio at the 128 Kbps YouTube recommends for stereo, the stream needs about 528 Kbps, which is 8.25 times more than 64 Kbps.

The phone has not crashed, and the camera app may not have stopped. The pipe is just too narrow. What YouTube does when the incoming video stops or slows is covered in our guide to what happens to a phone's YouTube Live stream when mobile data drops.

How to read your own plan

Open your operator's app or website and find the plan details. Look for a line like one of these:

"X GB/day, thereafter @ 64 Kbps" — a daily limit with slow data after it.
"X GB, valid for N days" — a total pack. When it is used, data may stop completely until you recharge.
"Unlimited" with a smaller line about fair usage — read the smaller line. It usually describes a speed after a limit.

If the plan has a daily limit, also find when it resets. Jio's Data Add-On help page says:

If you are on a Daily FUP plan, the daily data quota is renewed at midnight (between 00:00 hrs and 02:00 hrs).

That one sentence explains a common pattern: the stream dies at some point in the night, and "comes back" after midnight. The camera did not fix itself. The quota came back.

How many hours of live streaming does 1.5 GB per day give?

Here is the arithmetic, so you can redo it for your own plan.

MB per hour = bitrate in Mbps × 3,600 seconds ÷ 8

At YouTube's 0.4 Mbps minimum, that is 180 MB per hour of video. With 128 Kbps audio added, it is about 238 MB per hour.

Daily high-speed data	Hours at 0.4 Mbps (video only)	Hours at ~0.53 Mbps (video + 128 Kbps audio)
1 GB	about 5.6 h	about 4.2 h
1.5 GB	about 8.3 h	about 6.3 h
2 GB	about 11.1 h	about 8.4 h
3 GB	about 16.7 h	about 12.6 h

These are the best case. They assume:

the stream runs at YouTube's lowest allowed rate, not the 4 Mbps it recommends for 480p;
nothing else on the phone uses data;
1 GB = 1,000 MB (some operators count 1,024, which changes the hours a little).

A real phone uses some data for other things: app updates, backups, the operator's own apps. So in practice the hours are lower. At 720p the picture is far worse: YouTube's 720p minimum is 3 Mbps, which is 1.35 GB per hour. A 1.5 GB daily pack is gone in a little over one hour.

The honest summary: a 1.5 GB/day plan cannot carry a 24-hour live stream. At the lowest quality it covers a night, not a day and a night.

What still works after the daily limit?

This is the good news. Two of the three things a phone camera does use no mobile data at all.

1. Recording to the phone. Writing video to the phone's own storage or SD card does not touch the network. At 64 Kbps, or with mobile data switched off, the phone keeps recording. Background Camera RemoteStream records with the screen off and keeps the files on the phone. Nothing is uploaded to a cloud.

2. Live view on the same local network. Background Camera RemoteStream has a built-in web server (the browser live view is a Pro feature, per the Play listing). Any phone or laptop on the same Wi-Fi, or the same phone hotspot, can open the live view in a browser. That traffic stays inside the local network, so it does not count against the SIM's daily data. If you are in the shop or the house, you can still look at the camera after the daily limit.

3. YouTube Live over mobile data. This is the only part that needs the SIM's high-speed data. It is the part that stops.

So when people say "the camera stopped at night", it is worth asking which of the three stopped. Very often the recording is complete on the phone and only the live stream to YouTube failed.

How to set up a phone camera on a daily data plan

1. Decide which hours need a live stream

Most people do not need to watch live all day. They need to watch the hours when nobody is there: the shop at night, the house while the family is at work or away. Stream those hours. Let the phone record locally the rest of the time.

With 1.5 GB per day at the lowest setting, about 6 to 8 hours of streaming is a realistic target. Choose the hours on purpose, instead of letting the limit choose them for you.

2. Remember when the day resets

If your quota resets around midnight, a stream that starts in the evening uses the old day's data until midnight, then the new day's data after it. Example on a 1.5 GB plan:

If you stream from 8 pm, and nothing else used data that day, the stream can run until midnight on the old quota.
After the reset, the new 1.5 GB covers the rest of the night until about 6 am to 8 am, depending on audio.
But the new day's data is then mostly used before the day starts. Anyone using that SIM for anything else will find it slow.

That is fine for a SIM that only serves the camera. It is not fine if the SIM is also someone's main phone number. Our dual-SIM guide covers which SIM to leave in a camera phone, and why.

3. Use the lowest stream quality you can accept

For a security camera, 480p at the minimum bitrate is usually enough to see that someone came in, when, and roughly what they did. The full-quality recording stays on the phone. If you need a clear face later, you get it from the local file, not from the stream.

4. Stop other things from eating the camera's data

On the camera phone:

Turn off automatic app updates over mobile data in the Play Store settings.
Turn off photo and file backup over mobile data.
Uninstall or disable apps you will never use on that phone.
Check Settings > Network > Data usage (the name varies by brand) after the first day to see which app used what.

Data Saver is the other tool people reach for. It does not block a foreground camera service the way many guides say. We checked Android's source code for that in Does Data Saver Cut Off a Phone Security Camera Streaming on Mobile Data With the Screen Off?

5. Know what an add-on pack buys you

If you need extra hours on a particular night, a data add-on can help. On 5 November 2026, Jio's Data Add-On page listed a ₹19 pack with 1 GB valid for 24 hours, and said: "In case you have an active valid plan then the Data pack will be auto-activated on expiry of daily data allocation."

At the 0.4 Mbps minimum, 1 GB is about 5.6 hours of video, or about 4.2 hours with audio. Prices and packs change, so check the current list in your operator's app before you rely on this.

6. If a phone hotspot is the uplink, the same rule applies

Some setups use a second phone's hotspot as the internet for the camera phone. Then the hotspot phone's daily limit is the one that matters, and its 64 Kbps "after" speed slows the stream in the same way. Live view between the two phones still works, because it stays on the hotspot's local network. Our hotspot setup guide walks through that layout.

7. Test one night before you trust it

Do this once, on a normal day:

Note the data used so far today in your operator's app.
Start the stream at the hour you plan to use, at the quality you plan to use.
After one hour, check the data used again. That number, in MB, is your real MB per hour.
Divide your daily high-speed data by that number. That is your real hours per day.
Next morning, open the YouTube Live archive and the local recordings. Check whether the stream stopped, when it stopped, and whether the local recording carried on.

Also check one thing about your own setup: after the quota resets, does the stream start again by itself, or do you need to restart it? Test it, so you know before the night it matters.

What this means if you are on an old 3G phone

If the camera phone only supports 3G and your operator has switched 3G off, the phone may fall back to 2G and be slow before any daily limit. That is a different problem, with a different fix. See Will an Old 3G Phone Work as a Security Camera on Mobile Data?

Quick answers

My stream stopped but the phone still shows 4G. Is the phone broken?
Probably not. On a daily plan with "thereafter @ 64 Kbps", the 4G connection stays up, but at a speed far below YouTube's 0.4 Mbps minimum. Check your data balance in the operator's app.

Did the camera stop recording too?
Not because of data. Recording to the phone's storage does not use mobile data. Check the local files.

Can I still watch the camera at home after the limit?
Yes, on the same Wi-Fi or hotspot. Background Camera RemoteStream's local live view (a Pro feature) does not use the SIM's data.

How long will 1.5 GB a day stream for?
At best about 8 hours of 480p video at YouTube's minimum rate, or about 6 hours with audio. In practice a bit less.

Do I need a cloud account to use the camera?
No. Video stays on the phone and there is no cloud storage plan. Screen-off recording is in the core app; the browser live view and YouTube Live are Pro features per the Play listing, so check the listing for the current free vs Pro split. The only data cost is your own mobile plan, and only for the YouTube stream.

Get the app

Background Camera RemoteStream turns an Android phone into a camera that records with the screen off, keeps video on the phone, offers live view on your local network through its built-in web server, and can stream to YouTube Live. Live view and YouTube Live are Pro features per the Play listing; check it for the current free vs Pro details.

Google Play: https://play.google.com/store/apps/details?id=com.superfunicular.digicam
Website: https://superfunicular.com

Sources

Jio — What are the benefits of the ₹319 plan ("1.5 GB/day (thereafter @ 64 Kbps)")
Jio — I have used my daily data quota & the data speed has been reduced (midnight renewal, Data Add-On list)
YouTube Help — Choose live encoder settings, bitrates, and resolutions (H.264 minimums, 128 Kbps stereo audio)

All hours and MB figures in this article are calculated from those numbers, not measured on a phone.

An Empty Folder Made My Upload Loop Report One Clip: What Bash Does With a Glob That Matches Nothing

Super Funicular — Wed, 04 Nov 2026 13:55:03 +0000

I pointed a nightly upload loop at an empty folder of camera clips, the kind of folder you get on a night the phone recorded nothing, and it reported one clip uploaded. There was no clip. The loop had run once, with the pattern clips/*.mp4 itself as the file name.

That is documented Bash behavior, and the usual fix, shopt -s nullglob, brings its own surprise: with it on, ls clips/*.mp4 in an empty folder listed the files in the current directory instead. Below are the test scripts, what each one printed, what the Bash manual says about all three settings, what happens under /bin/sh, and the version of the job I would run instead.

Disclosure: I make an Android camera app. Nothing below uses its code or describes how it records, names or stores anything. The clips are random bytes or empty folders made on a Linux machine, and every output is pasted from the scripts shown. Versions:

GNU bash, version 5.1.16(1)-release (aarch64-unknown-linux-gnu)
dash 0.5.11+git20210903+057cd650a4ed-3build1 (/bin/sh)
ls (GNU coreutils) 8.32
tar (GNU tar) 1.34
find (GNU findutils) 4.8.0

The loop on an empty night

The job counts the clips in a folder and copies each one to an upload directory. The folder exists, but nothing was recorded into it.

#!/bin/bash
# A nightly job: count tonight's clips, then upload each one.
# The phone recorded nothing, so the folder is empty.
mkdir -p clips
n=0
for f in clips/*.mp4; do
  n=$((n + 1))
  echo "uploading: $f"
  cp "$f" /tmp/upload/ 2>&1 | sed 's/^/  /'
done
echo "clips uploaded tonight: $n"

uploading: clips/*.mp4
  cp: cannot stat 'clips/*.mp4': No such file or directory
clips uploaded tonight: 1
exit status: 0

The loop body ran once. $f held the literal text clips/*.mp4, cp failed on it, and the count went to one. The script still exited with status 0, because its last command was an echo that worked. A log that keeps only the last line says one clip went up on a night when none existed.

In this test the damage is a wrong number and a cp error in the middle of the output. In a job that does more with $f, such as writing it into a manifest, passing it to a remote command, or using it to build an output file name, the literal pattern goes wherever a real name would have gone.

What the manual says

The Bash Reference Manual, in the section on filename expansion, covers all three behaviors in one paragraph. The default: "If no matching filenames are found, and the shell option nullglob is disabled, the word is left unchanged."

The first alternative: "If the nullglob option is set, and no matches are found, the word is removed."

The second: "If the failglob shell option is set, and no matches are found, Bash prints an error message and does not execute the command."

The shopt page adds that "Unless otherwise noted, the shopt options are disabled (off) by default." Neither nullglob nor failglob is noted as on, so a script that does not set one gets the unchanged word. That is the loop above.

Turning on nullglob

nullglob fixes the loop: no match, no word, no iteration. The trouble is that it applies to every command in the script, and plenty of commands behave differently when handed no file arguments at all than when handed a pattern that matched nothing. Same empty folder, with two ordinary files in the directory the job runs from:

#!/bin/bash
# Same empty folder, nullglob on. The loop is fixed; now watch what
# the same setting does to commands that take the glob as arguments.
shopt -s nullglob
mkdir -p work/clips && cd work
touch notes.txt; sleep 1; touch settings.json
n=0
for f in clips/*.mp4; do n=$((n + 1)); done
echo "loop count: $n"
echo "== ls clips/*.mp4"
ls clips/*.mp4; echo "exit $?"
echo "== newest clip: ls -t clips/*.mp4 | head -n 1"
ls -t clips/*.mp4 | head -n 1
echo "== rm -f clips/*.mp4"
rm -f clips/*.mp4; echo "exit $?"
echo "== rm clips/*.mp4"
rm clips/*.mp4; echo "exit $?"
echo "== tar czf night.tgz clips/*.mp4"
tar czf night.tgz clips/*.mp4; echo "exit $?"

loop count: 0
== ls clips/*.mp4
clips
notes.txt
settings.json
exit 0
== newest clip: ls -t clips/*.mp4 | head -n 1
settings.json
== rm -f clips/*.mp4
exit 0
== rm clips/*.mp4
rm: missing operand
Try 'rm --help' for more information.
exit 1
== tar czf night.tgz clips/*.mp4
tar: Cowardly refusing to create an empty archive
Try 'tar --help' or 'tar --usage' for more information.
exit 2

Line by line:

The loop counted zero. That is the fix working.
ls clips/*.mp4 listed the current directory. With the word removed, the command became plain ls, and ls with no arguments lists where it is. It exited 0.
The newest-clip line picked settings.json. A job that uploads $(ls -t clips/*.mp4 | head -n 1) as the latest recording would have picked a settings file, without an error.
rm -f did nothing and exited 0. That is harmless here, and it is also why nobody notices the setting is on.
rm without -f failed with missing operand, and tar refused to make an empty archive and exited 2. Both are loud, which is better than ls, but a job written for the default behavior now fails on a night that used to pass.

So nullglob is not a setting to put at the top of an existing script and forget. Every command that receives a glob as arguments, rather than iterating over it, has to be checked for what it does with nothing.

Turning on failglob

failglob takes the opposite approach: an unmatched pattern is an error and the command does not run.

#!/bin/bash
# failglob instead: an unmatched pattern is an error.
shopt -s failglob
mkdir -p clips
echo "before the loop"
for f in clips/*.mp4; do echo "uploading: $f"; done
echo "after the loop, status $?"
ls clips/*.mp4
echo "after ls, status $?"

before the loop
./03_failglob.sh: line 6: no match: clips/*.mp4
after the loop, status 1
./03_failglob.sh: line 8: no match: clips/*.mp4
after ls, status 1
exit status: 0

Both the loop and ls were skipped, each with a no match error naming the line, and $? was 1 after each. The script itself kept going and exited 0. In this Bash, without set -e, failglob stopped the command and not the script.

With set -e added:

#!/bin/bash
# failglob together with set -e.
set -e
shopt -s failglob
mkdir -p clips
echo "before the loop"
for f in clips/*.mp4; do echo "uploading: $f"; done
echo "after the loop"

before the loop
./04_failglob_e.sh: line 7: no match: clips/*.mp4
exit status: 1

Now the script stopped at the loop and exited 1. That is a clear failure, which is what you want if an empty folder means something is wrong, and not what you want if an empty folder is a normal night. Whether a night with no clips is an error depends on the setup: a motion-triggered camera may record nothing on a quiet night, and one that records continuously should not.

Under /bin/sh

A script run directly, by hand or from a crontab line, gets whatever interpreter its first line names, and plenty of scripts say #!/bin/sh. On this machine that is dash, which has no shopt:

#!/bin/sh
# The same loop under /bin/sh, which is dash on this machine.
mkdir -p clips
shopt -s nullglob
for f in clips/*.mp4; do echo "would upload: $f"; done
for f in clips/*.mp4; do
  [ -e "$f" ] || continue
  echo "uploading: $f"
done
echo "guarded loop done"

./05_dash.sh: 4: shopt: not found
would upload: clips/*.mp4
guarded loop done
exit status: 0

dash could not find shopt, carried on, and the first loop ran once with the literal pattern, the same as Bash's default. A script that was tested under bash script.sh and then installed with a #!/bin/sh line loses its nullglob line silently, apart from one error message.

The second loop shows the portable guard: test $f with -e and continue if it does not exist. If the word was left unchanged, there is no such file and the body is skipped. The -e test is part of POSIX test, so the guard does not depend on Bash. One limit I did not test: a real file whose name is literally *.mp4 would pass the guard, since it exists.

The version I would run

For a Bash script, collect the matches into an array with nullglob on, turn it straight back off, and decide what an empty array means before doing anything with it.

#!/bin/bash
# Collect matches into an array with nullglob on, then turn it back off
# so no later command is changed by it. An empty night is reported.
set -u
dir=${1:-clips}
mkdir -p /tmp/upload
shopt -s nullglob
clips=("$dir"/*.mp4)
shopt -u nullglob
if [ "${#clips[@]}" -eq 0 ]; then
  echo "no clips in $dir tonight; nothing uploaded" >&2
  exit 3
fi
for f in "${clips[@]}"; do
  cp -- "$f" /tmp/upload/ && echo "uploaded: $f"
done
echo "clips uploaded tonight: ${#clips[@]}"

And a test of it on an empty folder, then on a folder with two clips, one with a space in its name:

#!/bin/bash
# Run the job on an empty folder, then on a folder with two clips.
rm -rf clips && mkdir clips
./06_upload.sh clips; echo "exit $?"
head -c 1024 /dev/urandom > clips/2026-11-03_0100.mp4
head -c 1024 /dev/urandom > "clips/2026-11-03 0200.mp4"
./06_upload.sh clips; echo "exit $?"

no clips in clips tonight; nothing uploaded
exit 3
uploaded: clips/2026-11-03 0200.mp4
uploaded: clips/2026-11-03_0100.mp4
clips uploaded tonight: 2
exit 0

What changed:

nullglob is on for one line. It changes how the array is filled and nothing else, so ls, rm and tar later in the script keep their usual behavior.
The count is the length of the array, so the number in the log and the files that were copied come from the same list.
An empty folder is reported and exits with its own status (3 here), so a monitor can tell an empty night apart from a failed upload. If an empty folder is a normal night for your setup, change that branch to exit 0, but keep the message.
Every expansion is quoted, and cp -- stops a name starting with a dash from being read as an option. The clip with a space in its name went through as one file.

For a /bin/sh script, the alternative is to let find do the matching. It treats a pattern with no matches as no output, not as a name:

#!/bin/sh
# For /bin/sh: let find do the matching. No match prints nothing.
mkdir -p clips
n=$(find clips -maxdepth 1 -type f -name '*.mp4' | wc -l)
echo "clips found: $n"
find clips -maxdepth 1 -type f -name '*.mp4' -exec cp -- {} /tmp/upload/ \;
echo "find exit: $?"

clips found: 0
find exit: 0

Zero clips found, nothing copied, and find exited 0. The count line runs find a second time, so on a folder that is still being written to, the two runs could disagree; in a real job I would write the list to a file once and count and copy from that.

What I would check in an existing job

Search for unquoted patterns in for loops and command arguments, such as for f in dir/*.mp4 and ls dir/*.log, and ask what each does on an empty folder.
Run the job once against an empty folder on purpose. That is the test that shows the literal pattern, and it takes a minute.
If the script sets nullglob, look at every command that takes a glob as arguments, especially ls, which lists the current directory when given nothing.
Check the first line. A #!/bin/sh script cannot use shopt; use the -e guard or find.
Decide what an empty night means and make the job say so with an exit status, instead of letting a count of one or zero stand in for that decision.

What I did not test

Other shells. This was Bash 5.1.16 and dash on Linux. zsh, ksh and BusyBox sh were not part of it, and I have not checked how each handles an unmatched pattern.
Newer Bash. The online manual is for a later Bash than the one tested; it mentions settings such as GLOBSORT that 5.1 does not have. I only quote the parts about unmatched patterns.
dotglob, nocaseglob and globstar. All change what a pattern matches; none was turned on here.
Very large folders. A pattern that matches many thousands of files can run into the system's argument length limit, which is a different failure.

Sources. Quotes about unmatched patterns, nullglob, failglob and default settings are from the GNU Bash Reference Manual, Filename Expansion and The Shopt Builtin. Outputs are pasted unedited from the scripts shown.

If you want an old Android phone recording in the background so there is a folder of clips for a job like this to pick up, the app I make is Background Camera RemoteStream on Google Play. Nothing above depends on it.

By default, an empty night does not make the loop fail: it runs once on a file named clips/*.mp4 and counts it, so a night with nothing recorded reports the same total as a night with one clip.

Does VOICE_RECOGNITION Make Breaking Glass Sound Duller? What a 4 kHz Ceiling Costs a Phone Camera's Sound Detection

Super Funicular — Wed, 04 Nov 2026 09:01:49 +0000

Last week I wrote about why a phone security camera's audio hisses in a quiet room. In short: automatic gain control (AGC) turns an empty room up. Of the audio sources a camera app would pick, VOICE_RECOGNITION is the one with a written promise that AGC and noise reduction are off by default.

Ahmed Znouda left a comment that deserves its own post. He asked two things:

"Did you try VOICE_RECOGNITION for the camera case? The flat-response target only covers 100 Hz to 4 kHz, so I'd be curious whether a slamming door or breaking glass sounds duller than with UNPROCESSED."

He also suggested a check that costs almost nothing at runtime: create the effect on the recorder's session and read getEnabled() before changing anything, then log the result per phone model.

This post does both. First it tests his frequency question with a reproducible simulation. Then it turns his runtime check into a log line that also catches effects your code didn't create.

What the compatibility rules promise, by frequency

The two sources are specified differently. Both figures come from Android's Compatibility Definition (CDD):

Source	Flatness the CDD asks for	What it says above that band
`VOICE_RECOGNITION`	approximately flat, ±3 dB from 100 Hz to 4000 Hz	nothing
`UNPROCESSED`	±10 dB from 100 Hz to 7000 Hz, for every mic used	within ±30 dB from 7000 Hz to 22 kHz of the mid band

So Ahmed's reading is right, with one precise point. The CDD doesn't say a voice-recognition path cuts above 4 kHz. It just doesn't promise anything there. A phone can pass compatibility with a voice path that rolls off steeply at 4 kHz, or with one that runs flat to 20 kHz. You can't know which from the spec.

The useful question, then, is: if the phone does roll off at 4 kHz, what does that cost?

The simulation

I built three synthetic events and put each into the same 30-second pink-noise room at the 10-second mark:

"Door": brown noise, low-passed at 400 Hz, 0.4 s with a fade. Almost all of its energy is a low thump.
"Glass (high)": white noise, high-passed twice at 3 kHz, 0.6 s with a fade. This is a deliberately unfavourable case: nearly all of its energy sits above the ceiling.
"Glass (broad)": the same, but high-passed at 1 kHz, so part of its energy falls under 4 kHz.

These are not recordings of a real door or real glass. Real breaking glass has energy across a wide band, and how much sits above 4 kHz depends on the pane, the room and the microphone. The two glass versions bracket that range. They don't measure it.

Then I ran each file through two stand-ins:

The 4 kHz ceiling: four cascaded lowpass=f=4000 filters, which gives a steep roll-off. This is the worst case the CDD allows for a voice path, not a description of any real phone.
AGC: dynaudnorm=f=500:g=31:m=30, the same stand-in as last week. It isn't any phone's AGC. It's a dynamic normaliser that raises quiet passages the way AGC does.

# Room + one event at t=10 s (shown for the high glass; door and broad glass are built the same way)
ffmpeg -f lavfi -i "anoisesrc=color=pink:amplitude=0.003:duration=30:sample_rate=48000:seed=7" room.wav
ffmpeg -f lavfi -i "anoisesrc=color=white:amplitude=0.5:duration=0.6:sample_rate=48000:seed=11" \
       -af "highpass=f=3000,highpass=f=3000,afade=t=out:st=0:d=0.6" glass.wav
ffmpeg -f lavfi -i "anoisesrc=color=brown:amplitude=0.9:duration=0.4:sample_rate=48000:seed=5" \
       -af "lowpass=f=400,afade=t=out:st=0:d=0.4" door.wav
ffmpeg -i room.wav -i glass.wav -filter_complex \
  "[1]adelay=10000,apad=whole_len=1440000[e];[0][e]amix=inputs=2:normalize=0" -ac 1 mix_glass.wav

# 4 kHz ceiling stand-in
ffmpeg -i mix_glass.wav -af "lowpass=f=4000,lowpass=f=4000,lowpass=f=4000,lowpass=f=4000" lp_glass.wav
# AGC stand-in
ffmpeg -i mix_glass.wav -af dynaudnorm=f=500:g=31:m=30 agc_mix_glass.wav

# Levels: the event (10.0–10.4 s) and quiet room (12–21 s), RMS dBFS
ffmpeg -ss 10 -t 0.4 -i lp_glass.wav -af astats=measure_perchannel=none:measure_overall=RMS_level -f null - 2>&1 | grep "RMS level"
ffmpeg -ss 12 -t 9   -i lp_glass.wav -af astats=measure_perchannel=none:measure_overall=RMS_level -f null - 2>&1 | grep "RMS level"

Results

Contrast below is the event's RMS level minus the quiet room's RMS level. That gap is what a sound detector lives on. ffmpeg 4.4.2, run 2026-11-04.

Event	Raw	4 kHz ceiling only	AGC stand-in only	Both
Door (low thump)	43.4 dB	45.5 dB	28.5 dB	30.5 dB
Glass (broad, >1 kHz)	50.4 dB	40.1 dB	31.7 dB	29.7 dB
Glass (high, >3 kHz)	49.9 dB	30.6 dB	31.4 dB	26.0 dB

The event levels themselves show the same thing. Under the ceiling, the door's RMS didn't move (−21.3 → −21.3 dBFS). The high glass dropped 21.3 dB (−14.8 → −36.1). The broad glass dropped 12.4 dB (−14.2 → −26.6).

What that answers

A slamming door: no, it doesn't get duller. Its energy is under 4 kHz, so the ceiling takes nothing from it. Contrast actually rose 2.1 dB, because the ceiling also trimmed some of the room's hiss (the quiet floor fell from −64.7 to −66.7 dBFS). For low events, a voice-recognition path that keeps its no-AGC promise is a pure gain: you skip the ~15 dB the AGC stand-in costs.

Breaking glass: possibly, and by about as much as AGC costs. In the unfavourable case, a hard 4 kHz ceiling cut the glass's contrast by 19.3 dB. The AGC stand-in cut it by 18.5 dB. So for a high-pitched event, a worst-case voice path doesn't remove the loss. It swaps one ~19 dB loss for another. With broader glass the ceiling cost 10.3 dB, about half as much.

Both together is the worst row. A phone that applies AGC and rolls off high (which a camcorder-style path can do, since its tuning is vendor-specific) left the high glass at 26.0 dB.

With the ceiling alone, a fixed −50 dB silencedetect threshold (2 s minimum) still isolated every event: silence before 10 s, silence again right after the event. With the AGC stand-in, the room itself rose to about −42 to −45 dBFS, above that threshold. The detector then reported one long stretch of "activity" running from about 4–10 s to 27 s, with the event lost inside it. That's last week's finding again: a fixed threshold can't follow a room that AGC keeps moving. The ceiling shrinks the margin, and AGC moves the floor up into it. Put in a louder room, a fan, or a phone farther away, and the case that starts with the least margin is the one that drops out first.

So there's no single best source for a camera. It depends on what you're listening for:

Doors, footsteps, voices, knocks: VOICE_RECOGNITION is the safe choice. Everything that matters is under 4 kHz, and AGC is promised off.
Glass, alarms, smoke-detector chirps: these sit high (a typical smoke alarm tone is around 3 kHz, with harmonics above it). UNPROCESSED, where supported, is the source whose spec actually covers the upper band. Check AudioManager.getProperty(AudioManager.PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED) first: it returns null when there's no support, and the source then behaves like DEFAULT.

Ahmed's runtime check, extended

The audiofx docs say this directly: an AGC, noise suppressor or echo canceller "can be inserted by default in the capture path by the platform according to the MediaRecorder.AudioSource used." The docs tell the app to create the effect and read its enabled state to learn the default for that session. That's Ahmed's check:

// Per-effect check (API 16+). null = this phone doesn't expose that effect through audiofx.
val session = audioRecord.audioSessionId
val agc = AutomaticGainControl.create(session)
val ns  = NoiseSuppressor.create(session)
Log.i(TAG, "agcDefaultOn=${agc?.enabled} nsDefaultOn=${ns?.enabled}")
agc?.release(); ns?.release()

It has one blind spot. It only answers for effect types you think to ask about. Since API 29 there's a second view that lists whatever is running. AudioRecord and MediaRecorder both implement AudioRecordingMonitor. Once capture has started, getActiveRecordingConfiguration() returns an AudioRecordingConfiguration with two lists:

getClientEffects(): the effects on your capture client.
getEffects(): the effects on the capture stream. Android's audio-sharing guide notes that these two can differ when another app is capturing at the same time with higher priority.

// API 29+. Call after start(); returns null before capture is active.
fun logCaptureEffects(monitor: AudioRecordingMonitor) {
    val cfg = monitor.activeRecordingConfiguration ?: return
    fun label(list: List<AudioEffect.Descriptor>) = list.joinToString { d ->
        when (d.type) {
            AudioEffect.EFFECT_TYPE_AGC -> "AGC"
            AudioEffect.EFFECT_TYPE_NS  -> "NS"
            AudioEffect.EFFECT_TYPE_AEC -> "AEC"
            else -> d.name
        }
    }.ifEmpty { "none" }
    Log.i(TAG, "${Build.MANUFACTURER} ${Build.MODEL} source=${cfg.clientAudioSource} " +
               "client=[${label(cfg.clientEffects)}] stream=[${label(cfg.effects)}]")
}

Logged once per session, that gives you a per-model table of which source actually came with which processing. It's the measurement the spec can't give you. Two cautions:

An empty list isn't proof of a flat path. These lists report effects the framework knows about. A vendor can still tune gain or equalisation inside the HAL without listing it as an effect, so the descriptor list is a floor, not a ceiling. The ten-minute offline recording test from the previous post is still the final check.
None of this tells you the frequency response. For that, record one known high sound (a phone playing a 6 kHz tone works) with each source on the same device, and compare levels with astats as above.

Where this fits

I build Background Camera RemoteStream, an Android app that turns a spare phone into a camera that keeps recording with the screen off. Recordings stay on the phone, there's a live view from any browser on the same Wi-Fi, and YouTube Live is there when you want an off-site copy. I'm not claiming a particular audio source for it here. The point of this post is that the right source depends on what you want to hear, and the behaviour depends on the phone. Both are things you measure, not things you assume.

Thanks to Ahmed for a question that turned out to have a two-sided answer. More at superfunicular.com.

Sources

AOSP — Android 12 Compatibility Definition (§5.4 voice recognition ±3 dB 100–4000 Hz; §5.11 unprocessed ±10 dB 100–7000 Hz, ±30 dB 7000 Hz–22 kHz)
Android Developers — NoiseSuppressor, AutomaticGainControl, AcousticEchoCanceler (default insertion by audio source; check enabled state after create)
Android Developers — AudioRecordingConfiguration (getEffects(), getClientEffects(), API 29), AudioRecordingMonitor, Sharing audio input
Simulation: ffmpeg 4.4.2 anoisesrc, lowpass, highpass, dynaudnorm, astats, silencedetect; commands above, run 2026-11-04

Why Does My Samsung Phone Camera Stop Recording at Night? Auto Restart, the 30% Battery Rule, and What to Turn Off

Super Funicular — Wed, 04 Nov 2026 08:12:55 +0000

You set up an old Samsung Galaxy as a security camera. It is plugged in, the screen is off, it is recording. You check it in the morning and the recording stopped somewhere around 3 a.m. Nothing crashed. There was no power cut. The phone simply restarted itself, and after the restart nothing was recording.

On many Galaxy phones this is not a fault. It is a setting, and Samsung documents it. This guide explains what the setting does, why a camera phone is exactly the kind of phone it picks, and how to check and turn it off on your own phone in about two minutes. It is written for a simple setup: one old Android phone, no cloud account, no subscription.

Why does my Samsung phone restart by itself at night?

Most likely because of Auto restart, a Samsung maintenance feature that restarts the phone on a schedule or "when needed." Samsung's own support pages describe it in two places, depending on the phone model and One UI version:

Settings → Battery and device care → ⋮ (More options) → Automation → Auto restart at set times. Samsung's Philippines support page says: "Your phone will restart automatically within 1 hour of the time you set."
Settings → Device care → Auto optimisation → Auto restart, with two switches: Restart when needed and Restart on schedule. Samsung's Hong Kong support page (updated 8 September 2026) says Restart when needed will restart the device "when memory usage increases or if it has not been restarted for a period of time."

Samsung also says on both pages that menus "may vary depending on the device model and software version." So on your phone the names may be slightly different. The search box at the top of Settings is the quickest way to find it: type restart.

Why a camera phone is the perfect target for Auto restart

Samsung lists the conditions under which the phone will restart itself. From the Philippines support page, the phone will only restart when:

"The screen is off."
"The phone isn't being used."
"The battery is above 30%."
"SIM card lock is off."

The Hong Kong page says the same thing in shorter form: "By default, the screen must be off and the battery level must be at least 30%."

Now look at a phone doing camera duty:

Samsung's condition	A normal phone at 3 a.m.	An old phone used as a camera
Screen is off	Usually	Always — screen-off recording is the point
Battery above 30%	Sometimes	Always — it is on the charger 24/7
SIM card lock off	Usually	Almost always — many camera phones have no SIM at all
Phone isn't being used	Usually	Unclear — see below

The first three conditions are not "sometimes true" for a camera phone. They are true by design, every night. The battery rule is the interesting one: the 30% condition protects a phone that is running low, but a camera phone that never leaves the charger never falls below it. The setup that keeps your camera reliable (plugged in, screen off) is the same setup that makes it eligible for an automatic restart.

The fourth condition, "the phone isn't being used," is the one nobody can answer for you. Samsung does not define it on these pages. A recording app running in the background with the screen off might count as "use," or it might not, and it may differ between phones and software versions. I am not going to guess. The honest answer is: test your own phone, which is the last section of this guide.

What actually breaks after the restart

A restart takes a minute or two. Losing a minute of footage is not the real problem. The real problem is what the phone is like after it comes back.

Samsung says it plainly on the Hong Kong page, under Restart when needed: "You must unlock your device to check messages and notifications normally after it restarts."

That sentence is about messages, but the same rule applies to a camera. After any restart, Android starts in a locked state until someone enters the PIN, pattern or password. Android's developer documentation calls this Direct Boot mode and says: "By default, apps don't run during Direct Boot mode." An app only runs in that state if its developer built it to. So in an empty house or a closed shop, the phone may sit on the lock screen for days, waiting for a finger that is not coming.

We went through that state in detail, with Google's exact wording, in The Restart Nobody Scheduled: Direct Boot, and What an Unattended Android Camera Cannot Do. This guide is the Samsung-specific half: the restart that Samsung schedules for you, and the switch that turns it off.

How to turn off Auto restart on a Samsung camera phone (step by step)

Do this on the camera phone itself, while you are standing next to it.

Newer menu (Battery and device care):

Open Settings.
Tap Battery and device care (on some phones just Device care).
Tap the three dots at the top right.
Tap Automation.
Tap Auto restart at set times and turn it off.
While you are in Automation, look at the other items too. If there is an Auto optimise daily or similar option, read what it says it does before leaving it on.

Older or regional menu (Auto optimisation):

Open Settings → Device care.
Tap Auto optimisation.
Tap Auto restart.
Turn off Restart when needed.
Turn off Restart on schedule.

Cannot find it? Use the search box at the top of Settings and type restart or optimis. The menu names change between One UI versions, but the search usually finds them.

Turning it off does not stop every restart

Samsung is clear that the switches do not cover everything. From the Hong Kong page:

"Even if both Restart when needed and Restart on schedule are turned off, a system restart may still occur depending on your device's condition."
"Emergency security updates may restart the device automatically even when automatic software download settings are turned off, depending on your country or region."

App updates from Google Play are a separate path again. An update can close a running app, and whether it comes back is up to the app. That is covered in The Update You Did Not Schedule: What Google Play Does to a Running Camera Phone.

So treat "Auto restart off" as removing the scheduled, every-night restart, not as a guarantee that the phone never restarts. The goal is to remove the restart that happens on purpose, and then know what your phone does after the ones you cannot remove.

If you want to keep a scheduled restart

Samsung recommends regular restarts to stop a phone getting slow, and on a very old phone that advice may be sensible. If you want to keep it, make it work for you instead of against you:

Pick a time when you are usually there. For a shop camera, a time just after you open in the morning. For a home camera, a time when someone is normally awake. Then the person who is there can unlock the phone and check the camera is running again.
Remember the one-hour window. Samsung says the restart happens "within 1 hour of the time you set," not exactly at that time. If you set 9:00, expect anything from 9:00 to 10:00.
Use weekly, not daily. If your menu lets you choose days, one restart a week is one gap a week instead of seven.
Turn it off before you travel. A locked house for a week, with nobody to unlock the phone, is the worst case. (Our Diwali travel guide has the rest of that checklist.)

The 10-minute test: what does your camera do after a restart?

This is the part that answers the question Samsung's pages leave open. Do it once, on the actual camera phone, with the actual app you use.

Start recording the normal way and turn the screen off.
Note the time.
Restart the phone yourself (hold the side key, or pull down the quick panel and tap the power icon, then Restart).
Do not unlock it. Leave it on the lock screen for 5 minutes. This copies what happens at 3 a.m.
Check from another device. If your app has a live view over Wi-Fi, try to open it from a second phone or laptop on the same Wi-Fi.
Now unlock the phone and look at the recordings. Is there a new file that started after the restart? Or does the last file end at the time you noted?
Write down the result. "Recording came back without unlocking", "came back only after unlocking", or "did not come back until I opened the app". All three are possible, and they depend on the app and the phone, not on you.

If the answer is anything except the first one, the setting in this guide matters a lot for your setup, and so does who can reach the phone to unlock it.

Quick checklist for a Samsung camera phone

[ ] Auto restart at set times: off (or set to a time when someone is there)
[ ] Restart when needed / Restart on schedule: off, if your phone has them
[ ] Restart test done; you know what your camera app does after a restart
[ ] Battery checked, so a power cut does not also become a restart (how to check an old phone's battery)
[ ] Play Store auto-update decision made for the camera app

If you are setting up a phone camera for the first time, start with Turn an old Android phone into a screen-off security camera (no cloud, LAN-only), then come back to this checklist before you leave the phone alone.

Sources

Samsung Philippines support — Restart your Galaxy phone regularly to prevent it from slowing down or freezing (Auto restart at set times, the one-hour window, the four conditions)
Samsung Hong Kong support — What to do if your Samsung Galaxy device appears to keep restarting (Auto optimisation, Restart when needed, Restart on schedule, restarts that still happen)
Android Developers — Support Direct Boot mode

Background Camera RemoteStream turns an Android phone into a screen-off camera: it records with the screen off and keeps recordings on the phone, with no cloud account needed. Its Pro tier adds a live browser view over your own Wi-Fi and YouTube Live streaming; check the Play listing for what is free and what is Pro.

Google Play: https://play.google.com/store/apps/details?id=com.superfunicular.digicam
Website: https://superfunicular.com

UK Law Makes Phone Makers Publish When Security Updates End. One Statement I Read Ran Out in February 2025

Super Funicular — Tue, 03 Nov 2026 13:55:13 +0000

Before a phone from the drawer gets a second job pointed at a door, somebody usually asks whether it is too old. That question tends to get answered by feel: the battery seems fine, the screen has a crack, it felt slow last year. There is a better input than feel for one part of it, and in the UK it has been a legal requirement since spring 2024. The maker has to write down how long the phone will get security updates, and publish it.

I went and read the law, then read two of the documents it produced. One of them ended in February 2025. The other does not contain a calendar date at all. Both are worth seeing before you decide what an old phone should be trusted with.

None of this is legal advice and I am not a lawyer. It is a close reading of a short statutory instrument and two manufacturer statements, aimed at people who are about to repurpose a handset.

What the law asks a phone maker for

The rules come from the Product Security and Telecommunications Infrastructure Act 2022 and a set of regulations made under it in 2023. The government's guidance page puts the start date plainly: "The UK’s consumer connectable product security regime came into effect on 29 April 2024."

The same page lists the three security requirements in a line each:

"banning universal default and easily guessable passwords"
"publishing information on how to report security issues"
"publishing information on minimum security update periods"

Phones are inside the regime. The exclusions on the guidance page are narrow, and the computing one reads "desktop computers, laptop computers and tablet computers which do not have the capability to connect to cellular networks". A handset with a SIM slot is none of those.

The third requirement is the one that matters for a repurposed phone, and the regulations define its key term carefully. A "defined support period" means "the minimum length of time, expressed as a period of time with an end date, for which security updates will be provided".

Three more sentences in the same schedule do most of the work:

"The defined support period must be published."
It has to be written "in such a way that is understandable by a reader without prior technical knowledge."
"The security requirements in this paragraph are not met if the defined support period is shortened after the publication of the information in sub-paragraph (2)."

So the number can go up after publication but not down. The document that carries it is called a statement of compliance, and the regulations say it must include "the defined support period for the product that was correct when the manufacturer first supplied the product;".

That is the promise in the abstract. Here is what it looks like on two real handsets.

Statement one: a date that has already passed

OPPO publishes its UK statements as PDFs. The one for model CPH2371, filed under the Find X5 Lite name, lists "Product Type: Mobile Phone" and then, on the line that matters, "Defined Support Period: 3 years (until 01-February-2025)", followed by an address where any update would be published.

The statement is signed and dated "2024-04-12". I ran the arithmetic: from the signature to the end of the period is 295 days, a little under ten months. From the day the regime started to the end of the period is 278 days.

None of that is a criticism. This is a model that went on sale years before the law existed, and the statement does what the law asks: it names a period and a calendar end date, and says where an extension would appear. What it shows is the situation a repurposing project is usually in. The handsets people hand down are, by construction, the old ones, and an old handset's published support period may be finished before anybody thinks to look. When I read it in November 2026, that end date was 640 days in the past.

Statement two: a period with no calendar date in it

Google publishes its UK statements as help-centre pages, one per Pixel model. The statement for the Pixel 10a gives its UK defined support period as "At least seven years from when the device first became available on the Google Store in the US".

The page is dated "November 7, 2025". The period is generous. What it does not contain is a date you can copy down. To get one you need a second fact, the day the model first went on sale in the United States, which Google points to on a separate page, and then you do the addition yourself.

Whether a relative period like that satisfies "expressed as a period of time with an end date" is for the regulator to decide, not me. The practical point for someone holding the handset is simpler: two manufacturers answered the same legal question in two different shapes, and one of the shapes needs a lookup and a sum before it tells you anything.

The same page also carries a scope note worth reading twice: the statement "is only applicable to products listed above where sold in the UK." Outside the UK, the number is still the best public signal of the maker's intent for that model. It is not a UK-law commitment to you.

What the published date covers, and what it leaves out

Reading the schedule closely, the security update requirement applies to the phone's hardware and to software pre-installed on it at the point of supply, plus software that has to be installed for the product to do what the manufacturer intends. Then there is a carve-out written specifically for phones. The broadest category of covered software is "software used for, or in connection with, any manufacturer’s intended purpose of the product unless the product is a smartphone or a tablet computer capable of connecting to cellular networks."

My reading, which is a reading and nothing firmer: for most connected gadgets, companion software the maker supplies is pulled into scope. For a smartphone, that wider category is switched off, and the commitment stays with the phone itself and what ships on it.

Either way, a camera app you download onto an old phone was not made by the phone's manufacturer and was not installed when the phone was supplied. The phone's support date says nothing about it. If you want to know how long an app will be maintained, that is a separate question for whoever publishes the app.

Three more gaps, stated plainly:

Handsets sold before the start date. The regulations "come into force on 29th April 2024". A phone sold new before that was not required to arrive with a statement, although, as the OPPO example shows, makers have published statements for older models that were still on sale afterwards.
Phones bought outside the UK. The Google note above limits the statement to UK sales.
Second-hand sales. The guidance page frames the regime around people "who purchase new connectable products". I did not find text in the documents I read that settles whether a resold handset carries any obligation, so I am leaving that as an open question.

The password rule, briefly

The first requirement is shorter and less useful to someone repurposing a phone, but it explains a habit worth keeping. The regulations say passwords must be "unique per product; or" "defined by the user of the product.", and passwords that are unique per product cannot be "based on incremental counters;" or "based on or derived from publicly available information;".

That rule binds the hardware maker, and it applies to "hardware of the product when that product is not in the factory default state;". It does not reach a camera app you install afterwards. The habit it encodes travels well anyway: any starting password that came printed in a manual or a setup guide is, by definition, publicly available information. Before a repurposed phone streams anything, the login in front of that stream should be one you chose.

A check that takes about five minutes

Find the model number on the handset itself. It is usually under Settings, then About phone. Marketing names are often shared across several model numbers, and the statements are filed by model number.
Search for the maker's UK statement of compliance for that model. The phrase PSTI statement of compliance plus the model number is what both documents above are titled around.
Read the defined support period. If it is a calendar date, copy it. If it is a period counted from a launch, find the launch date the statement refers to and do the sum.
Write the date on the phone. A strip of tape on the back is enough. It is the one fact about this handset that will not change by feel, and the person who picks it up in two years will not remember where you found it.
If the date has passed, narrow the job. A phone past its published support period still powers on and still records. What it no longer has is a public promise of security fixes. That argues for a smaller job: one task, on a network you control, signed in to as little as possible, with nothing on it you would mind losing.
If you cannot find a statement at all, treat the support period as unknown rather than generous. Unknown is an honest entry. A guess written on the back of the phone is not.

What I could not establish

I could not settle the second-hand question from the documents I read, and I would rather leave a visible gap than fill it with a guess. I also have not checked whether OPPO published an extension for CPH2371 at the address its statement points to. The statement allows for one, and if it exists, the date in this piece is out of date for that model.

What is settled is narrower and more useful. For phones sold new in the UK since April 2024, the end of security support is a published fact with a legal floor under it. For a handset about to start a second career, reading that fact takes less time than charging the battery.

Try it: Background Camera RemoteStream on Google Play records with the screen off and keeps the footage on the phone. Setup notes and other write-ups are at superfunicular.com.

Sources. The PSTI security requirements regulations on legislation.gov.uk, the UK government guidance on consumer connectable product security, OPPO's UK statement of compliance for model CPH2371 and Google's UK statement of compliance for the Pixel 10a. Quotations are verbatim from those pages as fetched on 3 November 2026. The handset cannot tell you when its maker stops looking after it, but in the UK the maker now has to say so in writing.

Going Home for Diwali? How to Leave an Old Phone Watching a Locked House for a Week: Power, Storage, and an Offline Security Camera Without Internet

Super Funicular — Tue, 03 Nov 2026 08:14:14 +0000

Diwali falls on Sunday, 8 November this year, and a lot of families will lock the house a few days before and travel home. The same thing happens for weddings, for Eid, and for any long visit to family. The house sits empty for a week, and somebody says: "Can we leave the old phone in the drawer as a camera?"

You can. But a week is not one night, and the habits people have when they lock up a house can quietly stop the camera on the first day. The biggest one is the main switch.

This guide is for a simple setup: one old Android phone, no subscription, no cloud account, and a house that will be empty for five to ten days. It is written in plain steps, with the arithmetic shown so you can check it for your own phone.

Can an old phone work as an offline security camera while you travel for Diwali?

Yes, if you plan for three things before you leave: power, storage, and how (or whether) you will watch it from far away.

Recording works with no internet at all. An app like Background Camera RemoteStream records with the screen off and keeps the video on the phone itself. Nothing needs to be uploaded.
Watching live from another city needs an internet connection at the house, because the video has to leave the house somehow. If the Wi-Fi router is off, there is no remote view, whatever app you use.
A whole week is a long time for a phone's storage and battery. Most problems with holiday camera setups are not camera problems. They are a full storage chip or a phone that ran on battery until it died.

The rest of this guide takes those one by one.

The main switch problem: do not turn off the circuit the camera needs

Many families switch off the main switch (MCB) before a long trip. It is a sensible habit for safety and for the electricity bill. But think about what it does to the camera:

The charger loses power. The phone starts running on battery.
The Wi-Fi router turns off too. Any live view stops at that moment.
The phone keeps recording until the battery is empty, and then it stops. For an old battery that can be a few hours, not a week.

So the camera you set up so carefully may record the family loading the car, and then nothing.

What to do instead:

Leave one circuit on, the one with the socket for the phone charger (and the router, if you want live view). Many homes have separate MCBs for different rooms. Find out which one feeds the socket you will use, and switch off only the others.
If your home has only one main switch, decide honestly: either leave it on, or accept that the camera is a "first few hours only" camera.
Use the phone's original charger or a good branded one, and put the phone on a hard, open surface, not on a bed, sofa, or near curtains. During Diwali, keep it well away from where diyas and candles were placed.
Check the battery before you trust it as a backup. Power cuts happen in an empty house too. If the battery is weak, a short cut can be enough to stop recording. Our guide How to Check an Old Phone's Battery Before Using It as a Security Camera shows how to test it, including a simple timing test you can do tonight.

Storage: a week of non-stop video does not fit on most old phones

This is the part people do not calculate. Video size is easy to work out:

GB per day = bitrate in Mbps × 86,400 seconds ÷ 8 ÷ 1,000

Video bitrate	Per day	For 7 days	For 10 days
1 Mbps	10.8 GB	75.6 GB	108 GB
2 Mbps	21.6 GB	151.2 GB	216 GB
4 Mbps	43.2 GB	302.4 GB	432 GB

(These are example bitrates for illustration, not the settings of any particular phone or app. Your phone's actual bitrate depends on resolution, the camera, and what is in the picture.)

An old budget phone often has 32 GB or 64 GB in total, and much of that is already used by the system and apps. Even at a low 1 Mbps, a full week of non-stop recording needs about 76 GB. It will not fit.

What to do:

Check free space today. Go to Settings → Storage. Write the number down.
Delete what you don't need on that phone (old WhatsApp videos, downloads) or move it to a computer.
Choose the lowest resolution that still shows what you care about. For a front door 3 metres away, you need to see a person and their clothes, not read a newspaper.
Decide what happens when storage is full. Either the phone stops recording, or old video is deleted to make room. Check how your setup behaves before you leave, not after you come back. Storage, Not Heat, Is the Real Limit on 24/7 Android Recording explains the full storage arithmetic and why recording in many short files is safer than one long file.
Do a 24-hour test. Record for one full day before the trip. Then look at how many GB were used. Multiply by the number of days you will be away. That number, from your own phone, is better than any table.

Watching from far away: what needs internet and what does not

Be clear about what you want:

"I only want proof of what happened." Then you need no internet at all. Record locally, come home, check the footage. This is the simplest and most reliable setup, and it costs nothing every month.

"I want to look in while I am away." Then the house needs an internet connection that stays on: either the broadband router (on a circuit you leave on), or a SIM with mobile data.

With Background Camera RemoteStream, the live browser view works over your own Wi-Fi, so it is for when you are at home or on the same network. To watch from another city, the app can stream to YouTube Live, which needs internet at the house. (Both the browser view and YouTube Live are listed in the app's Pro tier; check the Play listing for the current free and Pro split.)

Two numbers from YouTube's own help pages matter for a week away:

Data use. YouTube's live encoder settings page gives a minimum of 0.4 Mbps for H.264 video at 360p or 480p. That is about 180 MB per hour (0.4 × 3,600 ÷ 8), or about 4.3 GB per day, before audio. A typical daily mobile data pack will not cover 24 hours of streaming. Stream for the hours that matter to you, such as night time, or rely on broadband. Our article on old 3G phones and mobile data has the full data-pack arithmetic.
The 12-hour archive limit. YouTube's archive help page says streams under 12 hours can be archived automatically, and a stream that goes past 12 hours "may not be captured at all." So one long stream for the whole week is not a backup. Keep the local recording on, and treat the live stream as a window, not a storage system.

Placement: where to put the phone in a locked house

Point it at the way in. The main door, the gate, or the back door that people forget. One phone watching the entry is more useful than one phone watching a whole room.
Do not put it where it can be seen from outside. A phone visible through a window is itself something worth stealing. If someone does take it, the recording goes with it. Our guide What If Someone Steals the Phone That Is Your Shop Camera? covers what Android's theft protection does and does not do on budget phones.
Think about light at night. A locked house with every light off is very dark. If you leave one small light on (on the circuit you keep on), the camera will see much more.
Screen off. The screen is the part that makes heat and draws the most battery. Recording with the screen off is the whole point.

Check the date and time before you leave

If the phone has no SIM and the Wi-Fi is off, it cannot correct its own clock. After a power cut that empties the battery, an old phone may come back with the wrong date. Then the footage from "Tuesday night" is labelled with some other date. Check Settings → Date & time against another phone before you leave, and read Your Offline Security Camera Is Guessing What Time It Is if the phone will be offline the whole time.

Tell one neighbour

A camera records. It does not call anyone. Tell one trusted neighbour that you are away, ask them to look at the house once a day, and give them a number to call. If something happens, a person who can walk to the door in five minutes is worth more than any footage. Two Keyholders, Twenty Minutes, and Holiday Cover is about exactly this part of the plan.

The night-before checklist

[ ] The circuit for the charger socket stays on (and the router's, if you want live view)
[ ] Phone on a hard surface, good charger, away from curtains and diyas
[ ] Battery tested; you know roughly how long it lasts without power
[ ] Free storage checked; 24-hour test done; you know how many days fit
[ ] Lowest resolution that still shows the door clearly
[ ] Phone not visible from outside
[ ] Date and time correct
[ ] Recording started, screen off, and checked once after 10 minutes
[ ] One neighbour knows you are away

If this is your first time turning an old phone into a camera, start with Turn an old Android phone into a screen-off security camera (no cloud, LAN-only), do the setup this week, and use the days before you travel as your test.

Happy Diwali, and safe travels.

Google Play: https://play.google.com/store/apps/details?id=com.superfunicular.digicam
Website: https://superfunicular.com

tar czf on a Folder of Camera Clips Saved 1.3%, and 96% of That Was One CSV Log

Super Funicular — Tue, 03 Nov 2026 01:57:11 +0000

A nightly job turns a folder of camera clips into one archive with tar czf. The z sends every byte through gzip. I measured what that bought on a test folder: the archive came out 1.31% smaller than plain tar cf, and 96% of that saving came from the one CSV log sitting next to the video. The six clips together gave up 12,171 bytes out of 36.9 million.

That result is not a surprise once you see where the bytes go, and the reason changes what the archive line should say. Below are the folder, five ways of archiving it, where the few kilobytes of clip savings actually come from, and a zip option that quietly cancels the fix.

Disclosure: I make an Android camera app. Nothing below uses its code or describes how it records, encodes or stores anything. The clips are synthetic, made with ffmpeg on a Linux machine, and every output is pasted from the scripts shown. Versions:

Linux 6.8.0-138-generic
GNU bash, version 5.1.16(1)-release (aarch64-unknown-linux-gnu)
tar (GNU tar) 1.34
gzip 1.10
*** zstd command line interface 64-bits v1.4.8, by Yann Collet ***
xz (XZ Utils) 5.2.5
This is Zip 3.0 (July 5th 2008), by Info-ZIP.
ffmpeg version 4.4.2-0ubuntu0.22.04.1

The test folder

Real footage would be a better test, and I do not have a day of it that I can publish. The stand-in is six 10-second 720p H.264 clips of ffmpeg's built-in test pattern with moving grain on top, so the encoder cannot treat the frames as easy, plus a CSV log with one line every five seconds for a full day:

#!/bin/bash
# Six 10-second 720p H.264 clips with moving grain, plus a CSV event log,
# standing in for a day of camera footage. Nothing here comes from a phone.
set -e
mkdir -p clips
for i in 1 2 3 4 5 6; do
  ffmpeg -nostdin -loglevel error -y \
    -f lavfi -i "testsrc2=size=1280x720:rate=30:duration=10" \
    -vf "noise=alls=8:allf=t:all_seed=$i" \
    -c:v libx264 -preset veryfast -crf 23 -pix_fmt yuv420p "clips/clip_0$i.mp4"
done
python3 -c '
import random
random.seed(1)
with open("clips/events.csv", "w") as f:
    f.write("time,clip,event,score\n")
    for s in range(0, 86400, 5):
        f.write("%02d:%02d:%02d,clip_0%d.mp4,%s,%.2f\n" % (s // 3600, s // 60 % 60, s % 60,
                1 + s % 6, random.choice(["motion", "none", "none", "sound"]), random.random()))
'
ls -l clips | awk 'NR > 1 {print $5, $9}'
du -cb clips/*.mp4 | tail -1

5705602 clip_01.mp4
6682703 clip_02.mp4
6397985 clip_03.mp4
6045601 clip_04.mp4
5830938 clip_05.mp4
6227074 clip_06.mp4
548675 events.csv
36889903    total

That is about 6 MB per 10-second clip. ffprobe reports 4,560,848 bit/s for the first one. The CSV is 1.47% of the folder's bytes.

Five ways to archive the same folder

Each archive is timed with date before and after, which is crude but enough to see the gaps:

#!/bin/bash
# The same folder archived five ways. Size in bytes, then seconds of wall time.
set -e
run() {  # run NAME OUTPUT COMMAND...
  local name=$1 out=$2; shift 2
  local t0=$(date +%s.%N)
  "$@"
  local t1=$(date +%s.%N)
  printf '%-22s %10d bytes  %6.2f s\n' "$name" "$(stat -c %s "$out")" "$(echo "$t1 - $t0" | bc)"
}
rm -f clips.tar clips.tgz clips.tgz9 clips.tar.zst clips.txz
run "tar cf (no compression)" clips.tar   tar cf clips.tar clips
run "tar czf (gzip -6)"       clips.tgz   tar czf clips.tgz clips
run "gzip -9"                 clips.tgz9  sh -c 'tar cf - clips | gzip -9 > clips.tgz9'
run "zstd -3"                 clips.tar.zst sh -c 'tar cf - clips | zstd -q -3 -o clips.tar.zst'
run "tar cJf (xz -6)"         clips.txz   tar cJf clips.txz clips

tar cf (no compression)   37447680 bytes    0.06 s
tar czf (gzip -6)        36958847 bytes    1.63 s
gzip -9                  36958643 bytes    1.55 s
zstd -3                  36968055 bytes    0.08 s
tar cJf (xz -6)          36924128 bytes   15.71 s

Every compressor lands within 1.4% of plain tar cf. The timings move from run to run: in two back-to-back runs tar czf took 0.99 s and then 1.63 s. The pattern held in both. xz at its default level took between ten and sixteen times as long as gzip to save 34,719 more bytes, gzip -9 saved 204 bytes more than the default -6, and zstd at level 3 finished in about the time plain tar did.

On a 37 MB folder none of those seconds matter. I measured only this folder, so I will not put a number on a full day of footage, but the per-clip saving is the part that does not grow into anything.

Which bytes actually shrank

Running gzip over each file on its own separates the clips from the log:

#!/bin/bash
# Each file through gzip -6 on its own: original bytes, gzipped bytes, change.
for f in clips/*; do
  a=$(stat -c %s "$f"); b=$(gzip -6 -c "$f" | wc -c)
  printf '%-12s %9d -> %9d  %+7.2f%%\n' "$(basename "$f")" "$a" "$b" "$(echo "scale=4; ($b - $a) * 100 / $a" | bc)"
done

clip_01.mp4    5705602 ->   5703509    -0.04%
clip_02.mp4    6682703 ->   6680775    -0.03%
clip_03.mp4    6397985 ->   6396034    -0.03%
clip_04.mp4    6045601 ->   6043511    -0.03%
clip_05.mp4    5830938 ->   5828857    -0.04%
clip_06.mp4    6227074 ->   6225046    -0.03%
events.csv      548675 ->     78688   -85.66%

Each clip shrank by about 2 KB, between 0.03% and 0.04%. The CSV shrank by 85.66%. Of the 488,833 bytes that tar czf saved, 469,987 are the CSV.

The gzip manual explains both numbers in one sentence. gzip uses "Lempel-Ziv coding (LZ77)", and "The amount of compression obtained depends on the size of the input and the distribution of common substrings." The CSV is made of common substrings: clip_0, .mp4,, none and the same few event names, thousands of times over. The clips are the output of a video encoder, whose whole job is to remove repetition before the file is written, so gzip finds very little left to match.

The 2 KB is the index, not the picture

An MP4 file is a sequence of boxes. Splitting the first clip at its top-level boxes and running each one through gzip on its own shows where the 2 KB came from:

# Split an MP4 into its top-level boxes and run each one through gzip -6 on its own.
import struct, subprocess, sys

data = open(sys.argv[1], "rb").read()
pos = 0
while pos < len(data):
    size, kind = struct.unpack(">I4s", data[pos:pos + 8])
    if size == 1:                      # 64-bit size follows the type
        size = struct.unpack(">Q", data[pos + 8:pos + 16])[0]
    elif size == 0:                    # box runs to the end of the file
        size = len(data) - pos
    box = data[pos:pos + size]
    z = len(subprocess.run(["gzip", "-6", "-c"], input=box, capture_output=True).stdout)
    print("%s %9d -> %9d  change %+6d bytes" % (kind.decode(), size, z, z - size))
    pos += size

ftyp        32 ->        48  change    +16 bytes
free         8 ->        28  change    +20 bytes
mdat   5701068 ->   5701904  change   +836 bytes
moov      4494 ->      1306  change  -3188 bytes

The mdat box holds the encoded frames, and gzip made it 836 bytes larger. The moov box holds the file's metadata, including the tables that say where each frame sits in mdat. Those tables are rows of similar numbers, and they shrank from 4,494 bytes to 1,306. The small saving on the whole clip is the index shrinking by more than the picture grew.

The growth on the picture is not a bug either. The manual states it outright: "Compression is always performed, even if the compressed file is slightly larger than the original. The worst case expansion is a few bytes for the gzip file header, plus 5 bytes every 32K block, or an expansion ratio of 0.015% for large files." 836 bytes on 5,701,068 is 0.0147%. The picture data sat right at gzip's documented worst case, which is what data gzip cannot compress looks like.

zip has an option for this, and -9 cancels it

zip has a list of file types it stores without trying to compress, and video is not on it. From the Info-ZIP man page: "By default, zip does not compress files with extensions in the list .Z:.zip:.zoo:.arc:.lzh:.arj". The -n option adds to that: "Do not attempt to compress files named with the given suffixes. Such files are simply stored (0% compression) in the output zip file, so that zip doesn't waste its time trying to compress them."

The same man page has a sentence a few lines further down that is easy to skip: "The maximum compression option -9 also attempts compression on all files regardless of extension." I tried all three:

#!/bin/bash
# zip with and without -n .mp4, and with -9 added. unzip -v shows the method per member.
rm -f plain.zip stored.zip stored9.zip
zip -q -r plain.zip clips
zip -q -r -n .mp4 stored.zip clips
zip -q -r -9 -n .mp4 stored9.zip clips
for z in plain.zip stored.zip stored9.zip; do
  printf '%-12s %9d bytes  ' "$z" "$(stat -c %s "$z")"
  unzip -v "$z" | awk '$8 ~ /clip_01|events/ {printf "%s %s  ", $8, $2} END {print ""}'
done

plain.zip     36957505 bytes  clips/events.csv Defl:N  clips/clip_01.mp4 Defl:N  
stored.zip    36969856 bytes  clips/events.csv Defl:N  clips/clip_01.mp4 Stored  
stored9.zip   36956640 bytes  clips/events.csv Defl:X  clips/clip_01.mp4 Defl:X

unzip -v prints the method for each member. In plain.zip the clips were deflated (Defl:N, normal). With -n .mp4 they were stored, and the archive came out 12,351 bytes larger, which is about the 12 KB the clips gave up under gzip. Adding -9 to the same command put Defl:X, maximum, back on the clips. Someone who adds -9 because they want the smallest archive turns off the one option that told zip to leave the video alone.

What I would change in the archive line

If the folder is almost all video, drop the z. tar cf here was 9,102 bytes larger than the files it holds, which is tar's own headers and padding.
If there are text logs worth shrinking, compress those and not the clips. Either gzip the logs on their own, or pipe the whole tar through zstd -3, which on this folder kept 479,625 of gzip's 488,833 saved bytes at close to plain tar's speed.
With zip, use -n .mp4 and leave out -9. Check with unzip -v that the clips say Stored.
Keep a checksum if you drop compression. One thing the z does give you besides size: the manual says that for gzip and zip files, "gunzip checks a 32 bit CRC" when it decompresses, so a damaged archive is noticed on extraction. Drop the z and that check goes with it, so keep a sha256sum of the archive next to it.

Things I did not test

Real phone footage. The clips here are a test pattern with added grain, encoded by ffmpeg's libx264. A phone's hardware encoder, a different bitrate, or HEVC instead of H.264 will give different sizes. I expect the picture data to behave the same way and have not measured it.
A large folder. Everything above is 37 MB. I did not test how the timings grow on a day of footage, or multi-threaded compressors.
Where moov sits. These clips have moov at the end of the file. I did not test whether moving it to the front changes the 2 KB.
Other tool versions. The quotes come from the gzip man page and the Info-ZIP zip 3.0 man page. Everything I ran matched them, on the versions listed at the top.

Sources. gzip quotes are from the gzip(1) manual page as published by Hurricane Electric. zip quotes are from the Info-ZIP zip 3.0 manual page source. Outputs are pasted unedited from the scripts above.

If you want an old Android phone recording in the background so there are clips for a job like this to archive, the app I make is Background Camera RemoteStream on Google Play. Nothing above depends on it.

On this folder tar czf spent its time on the video and got its savings from the log, so compress the logs and store the clips.

find -size -1M Matched Only the Empty File: Size Units in a Camera Clip Cleanup Script

Super Funicular — Mon, 02 Nov 2026 19:55:14 +0000

A cleanup job for a folder of camera clips had one line meant to remove the broken stubs a recorder leaves behind when it stops mid-write: find clips -size -1M -delete. Anything under a megabyte, gone. I tested that line on six files with exact byte counts, and it selected one of them: the empty one. A 500-byte stub survived it.

The same test turned up two more ways a size in a shell script is not the number it looks like. ls -lh and ls -l --si printed the same letter for different units, and both rounded up. And a storage estimate that mixes the two kinds of gigabyte comes out about 7% short. Below are the files, what each tool printed, what the GNU manuals say about it, and the lines I would use instead.

Disclosure: I make an Android camera app. Nothing below uses its code or describes how it records or stores anything. The files are random bytes made on a Linux machine, and every output is pasted from the scripts shown. Versions:

find (GNU findutils) 4.8.0
ls (GNU coreutils) 8.32
Python 3.10.12
Linux 6.8.0-138-generic

Six files with known sizes

The sizes are picked to sit on both sides of the two meanings of a megabyte: 1,000,000 bytes and 1,048,576 bytes.

#!/bin/sh
# Six stand-in clips with exact byte counts, from empty to just over one MiB.
set -e
rm -rf clips && mkdir clips && cd clips
truncate -s 0 empty.mp4
head -c 500     /dev/urandom > stub_500.mp4
head -c 1000000 /dev/urandom > mb_1000000.mp4
head -c 1048576 /dev/urandom > mib_1048576.mp4
head -c 1048577 /dev/urandom > mib_1048577.mp4
head -c 1500000 /dev/urandom > mb_1500000.mp4

Three ways to print one size

For each file: the byte count from stat, then the size column from ls -lh and from ls -l --si.

#!/bin/sh
# The same six files in three units: bytes, ls -h (1024) and ls --si (1000).
cd clips
for f in *.mp4; do
  printf '%-16s %8s  -h %5s  --si %5s\n' "$f" "$(stat -c %s "$f")" \
    "$(ls -lh "$f" | awk '{print $5}')" "$(ls -l --si "$f" | awk '{print $5}')"
done

empty.mp4               0  -h     0  --si     0
mb_1000000.mp4    1000000  -h  977K  --si  1.0M
mb_1500000.mp4    1500000  -h  1.5M  --si  1.5M
mib_1048576.mp4   1048576  -h  1.0M  --si  1.1M
mib_1048577.mp4   1048577  -h  1.1M  --si  1.1M
stub_500.mp4          500  -h   500  --si   500

Read down the two right-hand columns:

The letter does not say which unit. -h counts in 1024s and --si in 1000s. The coreutils manual describes -h as the format that "uses powers of 1024" and the SI format as one that "uses powers of 1000". Both printed a bare M here, so a column of 1.1M values from someone else's terminal does not tell you which one you are looking at.
Both round up. The file of exactly 1,048,576 bytes shows as 1.1M under --si, and the file one byte larger shows as 1.1M under -h. The manual says so in general terms: "Fractional block counts are rounded up to the nearest integer." A displayed size is a ceiling, not a floor.
A decimal megabyte is 977K under -h. Anyone checking by eye that a file is at least a decimal megabyte with ls -lh will think the 1,000,000-byte file is under.

None of this is wrong. It is just three numbers for one file, and a script that copies one of them into a threshold inherits whatever the display did to it.

Which files each find -size test picks

#!/bin/sh
# Which files each -size test selects.
cd clips
for t in -1M 1M +1M -1024k -1048576c +999999c; do
  printf '%-11s %s\n' "$t" "$(find . -type f -size "$t" -printf '%f\n' | sort | tr '\n' ' ')"
done

-1M         empty.mp4 
1M          mb_1000000.mp4 mib_1048576.mp4 stub_500.mp4 
+1M         mb_1500000.mp4 mib_1048577.mp4 
-1024k      empty.mp4 mb_1000000.mp4 stub_500.mp4 
-1048576c   empty.mp4 mb_1000000.mp4 stub_500.mp4 
+999999c    mb_1000000.mp4 mb_1500000.mp4 mib_1048576.mp4 mib_1048577.mp4

-size -1M matched only empty.mp4. -size 1M, which reads like exactly one megabyte, matched the 500-byte stub along with the two files that really are about a megabyte. And -size +1M left out the file of exactly 1,048,576 bytes.

The findutils manual explains all three with one rule. The test is "True if the file uses n units of space, rounding up", and later: "Bear in mind that the size is rounded up to the next unit." So with M as the unit, a 500-byte file counts as one MiB, and so does a 1,000,000-byte file. Nothing non-empty is less than one unit, which is why the manual's own example says of -size -1M against -size -1048576c: "The former only matches empty files, the latter matches files from 0 to 1,048,575 bytes."

One detail did not match my reading of the manual. It says a plus sign means the test succeeds "if the file uses at least n units of storage". The 1,048,576-byte file uses exactly one unit, and on findutils 4.8.0 -size +1M did not select it. What I saw is more than one unit, after rounding up. The same paragraph says of the minus sign that "an exact size of n units does not match", and on this build the plus sign behaved the same way at the boundary. If your script depends on that edge, test it on your own build rather than trusting either reading.

The two rows that worked are the ones with a small unit. -1048576c counts bytes, so there is no rounding at all, and -1024k rounds to the next KiB, which made no difference for these files. Both selected the empty file, the stub and the decimal megabyte, and left the 1,048,576-byte file alone.

The gigabyte on the card and the G in df -h

The same mismatch shows up in the arithmetic people do before leaving a phone recording: how many hours fit on the card. A card sold as 64 GB is counted in decimal gigabytes. df -h reports in powers of 1024 and prints a G. A stream bitrate is usually quoted in decimal megabits. Mix them and the estimate shifts:

# A card sold as 64 GB, in the units df -h prints, and hours of a stream at 8 Mbit/s.
card = 64 * 10**9                 # bytes, decimal gigabytes
gib = card / 2**30
per_hour = 8 * 10**6 / 8 * 3600   # bytes per hour at 8 Mbit/s
print("64 GB card      = %d bytes = %.2f GiB" % (card, gib))
print("8 Mbit/s for 1h = %d bytes = %.2f GB = %.2f GiB" % (per_hour, per_hour / 10**9, per_hour / 2**30))
print("hours, same units  : %.2f" % (card / per_hour))
print("hours, GiB / GB/h  : %.2f  (%.1f%% short)" % (gib / (per_hour / 10**9), 100 * (1 - (gib / (per_hour / 10**9)) / (card / per_hour))))

64 GB card      = 64000000000 bytes = 59.60 GiB
8 Mbit/s for 1h = 3600000000 bytes = 3.60 GB = 3.35 GiB
hours, same units  : 17.78
hours, GiB / GB/h  : 16.56  (6.9% short)

These numbers are arithmetic on a made-up stream, not a measurement of any recorder, and a real card also loses space to the file system, which I did not model. The point is the 6.9%: taking the figure df -h shows and dividing by an hourly size worked out in decimal gigabytes understates the hours by that much. The opposite mix, a card's label divided by an hourly size in GiB, overstates them, by 7.4% on these numbers. Neither error is visible in the output, because both sides print a plain G.

What I would write instead

Give find thresholds in bytes. find clips -type f -size -1048576c selects files under 1,048,576 bytes and nothing else. If you want the decimal megabyte, write -size -1000000c. Either way, check with -print before adding -delete.
Do not use -size -1M or -size -1G to mean small files. They only match empty files. If you do want empty files, -empty says so directly.
Read sizes with stat -c %s in scripts, not from the ls -lh column. The display rounds up and drops the unit.
Pick one unit for capacity math and say which. Convert the card's label to bytes, convert the bitrate to bytes per hour, and divide. If you start from df, use df -B1 or df --output=avail -B1 so the number is in bytes.

Things I did not test

BSD and macOS find and ls. Everything here is GNU findutils and coreutils on Linux. I have not checked whether other implementations round the same way.
Sparse files and allocated size. -size and ls -l both use the file's apparent length. Disk usage tools that count allocated blocks can disagree with both, which is a separate question.
Real recordings. The six files are random bytes with chosen lengths. A stub left by a real recorder may be larger or smaller than 500 bytes; the rounding rule is the same either way.

Sources. find -size quotes are from the GNU findutils manual, section 2.6 Size. Block size quotes are from the GNU coreutils manual, section on block size. Outputs are pasted unedited from the scripts above.

If you want an old Android phone recording in the background so there is a folder of clips for a job like this to clean up, the app I make is Background Camera RemoteStream on Google Play. Nothing above depends on it.

In a cleanup script, a size written in megabytes is rounded before it is compared, so write the threshold in bytes and check what it selects before it deletes anything.

comm -23 Said Nine Camera Clips Were Missing From the Backup. Two Were.

Super Funicular — Mon, 02 Nov 2026 14:07:49 +0000

I set up a test folder of camera clips and a backup folder with two of them missing, then ran the line a nightly backup check usually rests on, the one that prints what is in one list and not the other: comm -23 phone.txt backup.txt. It reported nine missing clips.

comm did not hide the problem. It printed a warning and exited with status 1. A job that only wants a number throws both away. Below are the test folders, what comm printed, what the GNU manual says about it, a brute-force check of when comm stays quiet, and the version of the job I would run instead.

Disclosure: I make an Android camera app. Nothing below uses its code or describes how it records, names or stores anything. The clips are random bytes made on a Linux machine, and every output is pasted from the scripts shown. Versions:

comm (GNU coreutils) 8.32
find (GNU findutils) 4.8.0
GNU bash, version 5.1.16(1)-release (aarch64-unknown-linux-gnu)
Python 3.10.12

Twelve clips, ten backed up

One clip per hour from 06:00 to 17:00 in a phone folder, and a backup folder where the 09:00 and 12:00 clips did not arrive.

#!/bin/bash
# A "phone" folder with twelve hourly clips, and a "backup" folder
# where the 09:00 and 12:00 clips never arrived.
mkdir -p phone backup
for h in 06 07 08 09 10 11 12 13 14 15 16 17; do
  head -c 2048 /dev/urandom > "phone/2026-11-01_${h}00.mp4"
done
for h in 06 07 08 10 11 13 14 15 16 17; do
  cp "phone/2026-11-01_${h}00.mp4" backup/
done
ls phone | wc -l; ls backup | wc -l

12
10

So the right answer is two files: 2026-11-01_0900.mp4 and 2026-11-01_1200.mp4.

The usual comparison

#!/bin/bash
# The usual way: list both sides, ask comm for lines only in the first.
find phone -name '*.mp4' -printf '%f\n' > phone.txt
ls backup > backup.txt
comm -23 phone.txt backup.txt
echo "exit status: $?"

comm: file 1 is not in sorted order
2026-11-01_0800.mp4
2026-11-01_1000.mp4
2026-11-01_1200.mp4
2026-11-01_0700.mp4
2026-11-01_1500.mp4
2026-11-01_1100.mp4
2026-11-01_0900.mp4
2026-11-01_1400.mp4
2026-11-01_0600.mp4
comm: input is not in sorted order
exit status: 1

Nine names, including seven that are sitting in the backup folder. The two clips that really are missing are in there, mixed in with the others, so a person reading the list would not know which to trust.

The cause is the first input. find printed the names in the order the directory handed them back, which on this machine was not by name. ls sorts its output, so the backup list was in order and the phone list was not. comm walks both files once, top to bottom, and decides what is unique by comparing the current line of each. That only works if both files are in the same order.

What the manual says

The coreutils manual puts the requirement first: "Before comm can be used, the input files must be sorted using the collating sequence specified by the LC_COLLATE locale."

It also says what the warning and the status 1 mean: "If an input file is diagnosed as being unsorted, the comm command will exit with a nonzero status (and the output should not be used)."

And it says when the check runs. With neither --check-order nor --nocheck-order on the command line, "wrongly sorted inputs are diagnosed only if an input file is found to contain unpairable lines." The --help text on this machine words the stricter flag as "check that the input is correctly sorted, even if all input lines are pairable".

One more line from the manual matters for a nightly job. In the section on --total, it suggests portable scripts count with wc, and gives comm -23 file1 file2 | wc -l as the example. That example assumes sorted files. Point it at an unsorted one and wc -l counts whatever comm printed, the warning goes to the terminal or the log, and the count looks like any other count.

The job that only wanted a number

#!/bin/bash
# The same comparison inside a nightly job that only wants a number.
missing=$(comm -23 phone.txt backup.txt 2>/dev/null | wc -l)
echo "clips missing from backup: $missing"

clips missing from backup: 9

This is the shape a nightly check tends to take: 2>/dev/null to keep the cron mail quiet, and a count for the log. With the warning discarded, and the pipeline's status coming from wc rather than comm, nothing in the job's output says the nine is unusable. The number is also plausible: nine missing clips out of twelve is a bad night, not an unbelievable one.

When does comm stay quiet?

The manual's wording left me with a question. If the check runs only when there are unpairable lines, can an unsorted input slip through with a wrong answer and exit status 0? I tried every ordering of up to four names on the phone side against every ordering of up to three names on the backup side, and compared comm -23 with the true set difference each time.

# Every ordering of up to four names on the phone side, every subset
# on the backup side (in any order). Count the runs where comm printed
# the wrong answer AND exited 0, and the unsorted runs that exited 0.
import itertools, subprocess
names = "abcd"
runs = wrong = silent_wrong = unsorted_quiet = 0
for n1 in range(1, 5):
    for p in itertools.permutations(names, n1):
        for n2 in range(1, 4):
            for b in itertools.permutations(names, n2):
                open("p.txt", "w").write("\n".join(p) + "\n")
                open("b.txt", "w").write("\n".join(b) + "\n")
                r = subprocess.run(["comm", "-23", "p.txt", "b.txt"],
                                   capture_output=True, text=True,
                                   env={"LC_ALL": "C"})
                want = sorted(x for x in p if x not in b)
                runs += 1
                unsorted = list(p) != sorted(p) or list(b) != sorted(b)
                if unsorted and r.returncode == 0:
                    unsorted_quiet += 1
                if sorted(r.stdout.split()) != want:
                    wrong += 1
                    if r.returncode == 0:
                        silent_wrong += 1
print("runs:", runs)
print("wrong answers:", wrong)
print("wrong answers with exit status 0:", silent_wrong)
print("unsorted input, exit status 0:", unsorted_quiet)

runs: 2560
wrong answers: 1692
wrong answers with exit status 0: 0
unsorted input, exit status 0: 128

In these 2560 runs, every wrong answer came with a nonzero exit status. That fits my reading of the manual: a wrong answer means some line was misjudged as unique, and a line judged unique is an unpairable line, which turns the check on. Unsorted input did pass quietly 128 times, but in each of those the answer happened to come out right anyway.

That is a small test with single-letter names, on one version. It is not proof that the default check catches every case. It is enough to say the warning is worth reading.

The version I would run

#!/bin/bash
# Sort both lists the same way comm will compare them, and stop on error.
export LC_ALL=C
sort phone.txt > phone.sorted
sort backup.txt > backup.sorted
if ! missing=$(comm --check-order -23 phone.sorted backup.sorted); then
  echo "comm failed; not trusting the list" >&2
  exit 1
fi
printf '%s\n' "$missing"
echo "count: $(printf '%s\n' "$missing" | grep -c .)"
echo "== order-free cross-check"
grep -Fxv -f backup.txt phone.txt | sort

2026-11-01_0900.mp4
2026-11-01_1200.mp4
count: 2
== order-free cross-check
2026-11-01_0900.mp4
2026-11-01_1200.mp4

What changed, line by line:

export LC_ALL=C makes sort and comm compare names by byte value, the same way. The manual ties the order comm expects to LC_COLLATE, so the safe move is to sort and compare under one locale in one script, rather than trust that two programs or two machines agree.
Both lists go through sort, including the one from ls that already looked sorted. It costs nothing and removes the question.
--check-order makes the check unconditional, which is the stricter behavior the help text describes.
The exit status is tested before the output is used. If comm fails, the job says so and stops, instead of reporting a count.
The count comes from the stored result, so the number and the list are the same thing.

The last block is a cross-check that does not depend on order at all. grep -Fxv -f backup.txt phone.txt prints every line of the phone list that is not an exact, whole-line match for some line in the backup list. It treats every line of the backup list as a pattern, and I only ran it on a dozen names, so I have no numbers for a large archive. Here it gave the same two names from the unsorted files.

What I would check in an existing job

Find every comm call, and look at where each input comes from. find, a database query, a file written by an app, or a list someone edited by hand are all inputs that may not be sorted.
Look for 2>/dev/null or a pipe into wc -l right after it. Those are the two places the warning and the status get lost.
Run it once with --check-order on real data. If it fails, the old output was not safe to use.
Keep the sort and the compare under the same locale. Setting LC_ALL=C at the top of the script is the simplest way.
Spot-check the count against one known-missing file. Delete one clip from a test backup and confirm the job names it.

What I did not test

Other comm implementations. This was GNU coreutils 8.32 on Linux. BSD and macOS comm, and BusyBox, may check order differently or not at all.
Larger names and real collation. The brute-force test used four single letters under LC_ALL=C. Names with spaces, mixed case or non-ASCII characters under another locale were not part of it.
File names with newlines. A name with a newline in it breaks any one-name-per-line list. The manual's -z option and find -print0 exist for that case; I did not test them here.
Directory order on other file systems. The phone list came out unsorted on this machine. On another file system find may return names in a different order, sorted or not, which is the reason to sort rather than rely on it.

Sources. Quotes about ordering, the order check and exit status are from the GNU coreutils manual, comm invocation. The --check-order wording is from comm --help on the machine above. Outputs are pasted unedited from the scripts shown.

If you want an old Android phone recording in the background so there is a folder of clips to back up and check, the app I make is Background Camera RemoteStream on Google Play. Nothing above depends on it.

Before a backup check trusts a list from comm, sort both inputs the same way and read its exit status, because an unsorted input makes it print a confident wrong answer.

Why Is My AlfredCamera Camera Disabled? The 2026 Two-Camera Free Limit, Legacy Pricing, and an Offline Option for Camera #3

Super Funicular — Mon, 02 Nov 2026 08:12:45 +0000

You open AlfredCamera and one of your old phones shows as disabled. Nothing is broken, the phone is still on the shelf, it still has Wi-Fi. Or you try to add a third phone and the app asks you to upgrade.

If that sounds familiar, the likely reason is not a bug. AlfredCamera announced a change to its plans for 2026, and part of that change is a limit on how many cameras can be online at once on each tier. This guide explains what the limit is, how the rollout handles phones that are over it, how to rotate cameras without paying, and what you can do with a third phone if you would rather not rotate at all.

Everything below about AlfredCamera comes from its own Help Center announcement, linked at each point. Prices and dates can differ by country and can change, so the app itself is always the final word.

Why is my AlfredCamera camera disabled on the free plan?

Because the free tier now allows up to 2 online cameras. If your account has more cameras than that when the rollout reaches it, the extra ones are switched off for you.

AlfredCamera's 2026 plan and pricing announcement sets these limits:

AlfredCamera tier	Online cameras
Free	Up to 2
Premium Standard	Up to 4
Premium Plus	Unlimited

The announcement says the limits arrive in a "gradual, phased rollout" later in 2026, and that you get "a personalized notification in the app well before any changes affect your specific account." So if you never saw that notification, your account may not have been reached yet, and a disabled camera may have another cause (battery saver, a killed app, a lost connection).

Your cameras are not deleted. The announcement's FAQ is clear on this. When the rollout finds more active cameras than your plan allows, it keeps "cameras with recent activity online," and cameras "that haven't been updated for a longer period will be temporarily disabled." In plain words: the phones you used least recently are the ones that get switched off.

If you just want the short version: on free, two phones at a time stay online. You can choose which two. Or you can put the third phone on a different setup that does not count against any limit. Both options are below.

What changed in AlfredCamera's 2026 pricing?

Two things, both from the same announcement:

Price. In the United States, the annual price for new Premium Standard subscriptions went from $29.99 to $35.99 per year, effective March 16, 2026. That is a $6 rise, about 20%. Other regions see local prices in the app from April 7, 2026, and the announcement notes that prices "may vary across different countries due to exchange rates and local taxes."
Camera limits. The tier limits in the table above.

AlfredCamera explains the change as covering costs after "nearly half a decade" at the same price, plus investment in encrypted FHD streaming and AI detection. That is a reasonable thing for a cloud service to do. Running servers costs money, and a service that relays video through the internet has to pay for it somehow.

A quick piece of arithmetic, if you are deciding whether to pay: at $35.99 a year for up to 4 online cameras, a full Premium Standard setup works out to about $9.00 per camera per year. If you only run 2 cameras, free already covers you, and paying buys features rather than slots.

What is AlfredCamera's "Legacy Protection"?

This is the part people miss, and it matters if you already pay.

According to the announcement, if you subscribed before your region's effective date (US: March 16; other regions: April 7) and you keep the subscription active:

Your renewal price is locked. "Your renewal price is guaranteed at your current rate."
Camera limits come later for you. Legacy users "will be prioritized with the longest available buffer periods" when the camera limits roll out.

There is one catch, and it is worth writing down:

If your subscription is cancelled or expires due to a payment failure, your Legacy status will be lost, and any resubscription will follow the 2026 pricing and plan rules.

So if you are a legacy subscriber, an expired card can cost you the old price. Check that the card on your Google Play or App Store account is current before your renewal date. That one step protects the old rate.

How to rotate cameras on the free plan

If you have three or more phones and want to stay on free, AlfredCamera gives you a manual method. From the announcement's FAQ: go to the settings of any active camera and select "Disable" to release its slot, then "Enable" another camera within your plan's limit.

A simple routine that works for a lot of homes:

Decide your two "always" cameras. Usually the front door and the room where valuables or a pet live.
Treat the third phone as a "sometimes" camera. For example, the back gate only when you travel, or the shop counter only at night.
Swap before you leave, not after. Disable one and enable the other while you are still at home, and check that the live view loads. Doing it from a café on mobile data is where things go wrong.
Keep the rotated phone charged. A disabled camera is still a phone. If it sits off the charger for a week, it will be flat when you need it.

Don't confuse this with Remote Switch, which is a separate AlfredCamera feature. Remote Switch lets the owner turn a camera off and on from the viewer device, from the camera thumbnail's settings (Remote Switch help page). The help article is about pausing a camera, not about the plan's slot count, so don't assume one replaces the other. Use the "Disable"/"Enable" steps from the announcement for slots.

What can I do with camera #3 without paying?

Rotation works, but it means one area is never watched while the other two are. If the third phone covers a spot you want recorded every night, there is another route: run that phone as a local, offline camera that doesn't sign in to any service, so there is no online-camera count to run out of.

This is a different kind of setup from AlfredCamera, and it is fair to be clear about the trade-off:

	AlfredCamera (cloud relay)	Local, offline phone camera
Account	Required	None
Where video is kept	Depends on plan and features	On the phone's own storage
Watching from far away	Built in (through Alfred's service)	Not by default; you check the files, or watch on your own network
Counts against a camera limit	Yes	No account, so no count
Works with no internet	Needs a connection to view remotely	Records with no internet at all

The mixed setup a lot of people end up with: keep your two most important views on AlfredCamera's free tier, where remote viewing is the point, and let the third phone record locally all night, every night. In the morning, or when something happens, you look at the files.

How to set up the third phone as a local, offline camera

I build Background Camera RemoteStream, so this is the one I'll describe. It needs no account, records with the screen off, and keeps recordings on the phone.

Install it from Google Play on the third phone. No sign-up step.
Give it the camera permission (and microphone if you want sound).
Turn off battery optimisation for the app. On many Android brands, especially budget ones, the system closes background apps to save power. Our guide Why Your Old Phone Security Camera Dies After 4 Hours walks through the settings by brand.
Start recording, then turn the screen off. The app runs as an Android foreground service, so recording continues with the display dark. A dark screen also stops the phone lighting up the room at night.
Leave it on a charger and do a one-hour test before trusting it overnight. Play the file back the next morning.
Check storage. A long recording fills a cheap card faster than people expect. If your card is 32 GB or smaller, read why a recording can stop at almost 4 GB.

Watching live is optional. The app's Pro tier adds a live view in any web browser on your own Wi-Fi, and YouTube Live streaming. Check the Play listing for the current free and Pro split before you rely on either. If you only need a record of what happened, the free recording is enough.

For the full first-time setup, start with Turn an old Android phone into a screen-off security camera (no cloud, LAN-only).

Which option should I choose?

You have 2 phones or fewer: nothing changes for you on AlfredCamera free. Stay put.
You already pay and joined before the effective date: keep the subscription active and the card current to hold Legacy pricing.
You have 3+ phones and need remote viewing on all of them, all the time: Premium Standard (up to 4) or Premium Plus (unlimited) is built for exactly that. On Standard that works out to about $9 per camera per year.
You have 3+ phones and the extra ones mostly need to record: keep two on AlfredCamera free and run the rest as local, offline cameras.
You don't want any account or cloud service at all: run every phone locally. You give up easy viewing from far away, and in return nothing about your setup depends on a company's plan rules.

For a broader comparison of free apps and what "free" means in each, see What "Free" Actually Gets You in a Camera App (2026).

Quick checklist

Look for AlfredCamera's in-app notice before assuming the limit hit you
Pick your two "always" cameras
Rotate with Disable/Enable before you leave home
Legacy subscriber? Keep the card current; a lapse resets you to 2026 pricing
Third phone recording locally: battery optimisation off, screen off, charger on, one-hour test

Google Play: https://play.google.com/store/apps/details?id=com.superfunicular.digicam
Website: https://superfunicular.com

AlfredCamera details are taken from AlfredCamera's Help Center as of November 2026. Prices and limits may differ in your country; the app shows the current terms.

DEV Community: Super Funicular

((count++)) Stopped My Clip Counter Under set -e Before It Printed a Line: Bash Arithmetic Returns 1 on Zero

What the manual says (( )) returns

Why it printed nothing

The version that only fails on some nights

What I changed, and what each fix covers

A short checklist for clip scripts with set -e

Things I did not test

Six Camera Clips, Three in the Archive, Every mv Exited 0: Testing Same-Name Moves From Two Folders

The setup

One mv, both folders

One mv per camera

A loop, one mv per clip

What the manual says

mv -n

mv -i with nobody at the keyboard

mv --backup=numbered

What I would run instead

What I would check in an existing job

What I did not test

Why Does My Phone Camera's Live Stream Stop After a Few Hours on Mobile Data? The 1.5 GB/Day Limit and the 64 Kbps Speed After It

Why does my phone camera stream stop after a few hours on mobile data?

How to read your own plan

How many hours of live streaming does 1.5 GB per day give?

What still works after the daily limit?

How to set up a phone camera on a daily data plan

1. Decide which hours need a live stream

2. Remember when the day resets

3. Use the lowest stream quality you can accept

4. Stop other things from eating the camera's data

5. Know what an add-on pack buys you

6. If a phone hotspot is the uplink, the same rule applies

7. Test one night before you trust it

What this means if you are on an old 3G phone

Quick answers

Get the app

Sources

An Empty Folder Made My Upload Loop Report One Clip: What Bash Does With a Glob That Matches Nothing

The loop on an empty night

What the manual says

Turning on nullglob

Turning on failglob

Under /bin/sh

The version I would run

What I would check in an existing job

What I did not test

Does VOICE_RECOGNITION Make Breaking Glass Sound Duller? What a 4 kHz Ceiling Costs a Phone Camera's Sound Detection

What the compatibility rules promise, by frequency

The simulation

Results

What that answers

Ahmed's runtime check, extended

Where this fits

Sources

Why Does My Samsung Phone Camera Stop Recording at Night? Auto Restart, the 30% Battery Rule, and What to Turn Off

Why does my Samsung phone restart by itself at night?

Why a camera phone is the perfect target for Auto restart

What actually breaks after the restart

How to turn off Auto restart on a Samsung camera phone (step by step)

Turning it off does not stop every restart

If you want to keep a scheduled restart

The 10-minute test: what does your camera do after a restart?

Quick checklist for a Samsung camera phone

Sources

UK Law Makes Phone Makers Publish When Security Updates End. One Statement I Read Ran Out in February 2025

What the law asks a phone maker for

Statement one: a date that has already passed

Statement two: a period with no calendar date in it

What the published date covers, and what it leaves out

The password rule, briefly

A check that takes about five minutes

What I could not establish

Going Home for Diwali? How to Leave an Old Phone Watching a Locked House for a Week: Power, Storage, and an Offline Security Camera Without Internet

Can an old phone work as an offline security camera while you travel for Diwali?

The main switch problem: do not turn off the circuit the camera needs

Storage: a week of non-stop video does not fit on most old phones

Watching from far away: what needs internet and what does not

Placement: where to put the phone in a locked house

Check the date and time before you leave

Tell one neighbour

What the manual says `(( ))` returns

A short checklist for clip scripts with `set -e`