DEV Community: Super Funicular

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

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

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.

wc -l Says 2, grep Says 3: A Missing Final Newline Drops the Last Clip From a while read Loop

Super Funicular — Sun, 01 Nov 2026 13:57:18 +0000

wc -l says a list of camera clips has two lines. grep, awk and sed say three. The file holds three clip names, and the while read loop that uploads them handles two.

All three answers come from one missing byte: the list does not end with a newline. A short Python script writes it for the shell loop to read:

names = ["clip_0700.mp4", "clip_0715.mp4", "clip_0730.mp4"]
with open("upload.txt", "w") as f:
    f.write("\n".join(names))
print("bytes written:", len("\n".join(names)))

bytes written: 41

join() puts its separator between names, not after the last one. Three names, two newlines.

Disclosure: I make an Android camera app. Nothing below uses its code or describes how it records, names or uploads anything. The clip names are made up, and every output is pasted from the scripts shown. Versions:

GNU bash, version 5.1.16(1)-release (aarch64-unknown-linux-gnu)
wc (GNU coreutils) 8.32
grep (GNU grep) 3.7
GNU Awk 5.1.0, API: 3.0 (GNU MPFR 4.1.0, GNU MP 6.2.1)
sed (GNU sed) 4.8
Python 3.10.12

Four tools, two answers

First, ask a few common tools how many lines the file has:

#!/bin/bash
echo "wc -l:        $(wc -l < upload.txt)"
echo "grep -c '':   $(grep -c '' upload.txt)"
echo "awk END{NR}:  $(awk 'END { print NR }' upload.txt)"
echo "sed -n '\$=':  $(sed -n '$=' upload.txt)"
echo "last byte:    $(tail -c 1 upload.txt | od -An -c)"

wc -l:        2
grep -c '':   3
awk END{NR}:  3
sed -n '$=':  3
last byte:       4

wc -l says 2. grep, awk and sed say 3. The last check shows why they disagree: the final byte of the file is the character 4 from clip_0730.mp4, not a newline.

None of these tools is broken. They are counting different things, and only one of them says so in its name.

What a line is, according to POSIX

POSIX defines a line as "A sequence of zero or more non- characters plus a terminating character." The newline is part of the line, not a separator between lines.

It also has a name for what is left over at the end of this file. An incomplete line is "A sequence of one or more non- characters at the end of the file." So by the standard's own words, upload.txt holds two lines and one incomplete line.

The GNU manual for wc is just as plain about what -l does: "Print only the newline character counts. If a file ends in a non-newline character, its trailing partial line is not counted."

So wc -l is right, and it was answering the question its manual says it answers. It counts newline characters. A script that treats that number as the count of clips in the list is the thing that is wrong.

grep, awk and sed are more forgiving and treat the trailing text as a last line. That is useful, but it means a quick sanity check with one of them will agree with the eye and disagree with wc -l, and the check that happens to be in the script decides which answer you get.

The loop that skips the last clip

The upload loop is the usual safe form, with IFS= and -r:

#!/bin/bash
n=0
while IFS= read -r f; do
  n=$((n + 1)); echo "upload $f"
done < upload.txt
echo "loop body ran $n times; leftover f='$f'"

upload clip_0700.mp4
upload clip_0715.mp4
loop body ran 2 times; leftover f='clip_0730.mp4'

The body ran twice. After the loop, f still holds clip_0730.mp4, so the name was read. The body just did not get it.

The Bash manual explains this in the read entry. read does assign what it got, and then: "The exit status is zero, unless end-of-file is encountered, read times out (in which case the status is greater than 128), a variable assignment error (such as assigning to a readonly variable) occurs, or an invalid file descriptor is supplied as the argument to -u."

Reading the last name hits end-of-file before a newline, so read returns non-zero, and while takes any non-zero status as the signal to stop. Here it is with the loop removed:

#!/bin/bash
printf 'clip_0730.mp4' | { IFS= read -r f; echo "no newline:   status=$? f='$f'"; }
printf 'clip_0730.mp4\n' | { IFS= read -r f; echo "with newline: status=$? f='$f'"; }

no newline:   status=1 f='clip_0730.mp4'
with newline: status=0 f='clip_0730.mp4'

Same name, same variable, different status. The loop looks at the status and nothing else.

A non-zero status at end-of-file is how every while read loop is meant to finish, so the short pass and a complete one end the same way. There is no error to catch, which is why this kind of bug tends to be found by someone counting files by hand.

Two fixes on the reading side

If you cannot control the writer, make the reader tolerate the missing newline:

#!/bin/bash
n=0
while IFS= read -r f || [ -n "$f" ]; do
  n=$((n + 1)); echo "upload $f"
done < upload.txt
echo "loop body ran $n times"

mapfile -t clips < upload.txt
echo "mapfile got ${#clips[@]} entries: ${clips[*]}"

upload clip_0700.mp4
upload clip_0715.mp4
upload clip_0730.mp4
loop body ran 3 times
mapfile got 3 entries: clip_0700.mp4 clip_0715.mp4 clip_0730.mp4

The -n test after || keeps the loop going for one more pass when read hit end-of-file but still put text in f. On the next pass read gets nothing, f is empty, and the loop stops. The order matters: the test has to come after read in the same condition, because it is checking what that read just assigned.

mapfile -t reads the whole file into an array and kept all three names here. The manual describes -t as "Remove a trailing delim (default newline) from each line read." It is a good fit when the list is small enough to hold in memory and the body does not need to run while the file is still being read.

The same byte breaks concatenation

Lists like this often get joined, for example a day's file appended to a weekly one. cat copies bytes and adds nothing between files:

#!/bin/bash
printf 'clip_0800.mp4\nclip_0815.mp4\n' > tuesday.txt
cat upload.txt tuesday.txt > week.txt
while IFS= read -r f; do echo "[$f]"; done < week.txt

[clip_0700.mp4]
[clip_0715.mp4]
[clip_0730.mp4clip_0800.mp4]
[clip_0815.mp4]

There were four clips across the two files. The loop sees three names, and one of them is two clips glued together. An upload step would try to open a file called clip_0730.mp4clip_0800.mp4, fail on it, and if that failure is handled per file, carry on. This is worse than the skipped clip because two clips are lost from one missing byte, and the error that does appear names a file nobody made.

A check for the end of a file

tail -c 1 prints the last byte. Command substitution strips trailing newlines from what it captures, so if that byte is a newline the result is empty, and if it is anything else the result is not:

#!/bin/bash
for file in upload.txt tuesday.txt; do
  if [ -s "$file" ] && [ -n "$(tail -c 1 "$file")" ]; then
    echo "$file: last line has no newline"
  else
    echo "$file: ends cleanly"
  fi
done

upload.txt: last line has no newline
tuesday.txt: ends cleanly

The -s test skips empty files, which have no last byte to check. This is cheap enough to run before every loop over a list you did not write.

The fix on the writing side

The real fix is to have the writer end every line with a newline, including the last one:

names = ["clip_0700.mp4", "clip_0715.mp4", "clip_0730.mp4"]
with open("upload.txt", "w") as f:
    for name in names:
        f.write(name + "\n")

After running that, the same counting and loop scripts agree:

wc -l:        3
grep -c '':   3
awk END{NR}:  3
sed -n '$=':  3
last byte:      \n
upload clip_0700.mp4
upload clip_0715.mp4
upload clip_0730.mp4
loop body ran 3 times; leftover f=''

Every tool says 3, the loop uploads all three clips, and f is empty after the loop because the last read found nothing left.

If you keep the join, write one more newline after it. The point is the same either way: in a list of lines, the newline belongs to each line, not between them.

What to change in a script like this

Write every line with its own newline, the last one included. In Python, add the newline to each name as you write it, or write one more after a join.
In Bash, read lists with the read -r loop plus its -n test, or with mapfile -t, so a list from somewhere else does not lose its last entry.
Do not use wc -l as a count of records unless you know the file ends with a newline. It counts newline characters, as its manual says.
Check the last byte before concatenating lists, or join them with a tool that adds the missing newline, rather than plain cat.
Compare the number of items processed with the number expected and log both. A loop that ends cleanly one item short gives no other sign.

Things I did not test

Other shells. I ran Bash 5.1. dash, zsh and others have their own read. The quote above is from the Bash manual, and I did not check another shell's.
Other versions of the tools. The wc quote is from the current GNU manual, and I ran coreutils 8.32. The output matched the quote, but I did not run another version. I did not read POSIX's page for wc itself, so I make no claim about non-GNU wc here.
Other awk and grep builds. I ran GNU awk and GNU grep. Other builds may treat a trailing incomplete line differently, and I did not test any.
Windows line endings. A list written with carriage returns has a separate problem, a stray \r on every name. I did not mix that in here.

Sources. Definitions are from POSIX.1-2024 Base Definitions, chapter 3: Definitions (3.172 Incomplete Line, 3.185 Line). The wc quote is from the GNU coreutils manual page wc invocation. The read and mapfile quotes are from the GNU Bash Reference Manual page Bash Builtins. 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 list like this to name, the app I make is Background Camera RemoteStream on Google Play. Nothing above depends on it.

Before blaming the upload loop, look at the last byte of the list it reads: join() puts the newline between names, so the last name it writes is, to wc -l and while read, not yet a line.

Why Does My Phone Security Camera Only Show a Reflection at Night? Recording Through a Window, Double Glazing and Mosquito Mesh

Super Funicular — Sun, 01 Nov 2026 08:13:12 +0000

You set an old phone on the windowsill, point it at the gate, and check the footage the next morning. The daytime part looks fine. The night part shows your own living room: the ceiling light, the TV, the shelf, and maybe the phone itself, floating over a faint, dark street.

Nothing is wrong with the phone. This is plain physics, and it happens to every camera that records through glass from a lit room. The good news is that the fixes are free, and most of them take a minute.

This guide covers three things people run into when they put a phone camera behind a window: night reflections, the "double image" from double glazing, and the mosquito mesh or window grille that sits in front of so many windows in homes and shops.

Why does my phone security camera only show a reflection at night?

Because at night, the inside of your room is much brighter than the outside, and window glass is a weak mirror.

Ordinary uncoated glass reflects about 4% of the light that hits it straight on, at each surface. That number comes from the Fresnel equations: with glass at a refractive index of about 1.5, the reflectance is ((1.5 − 1) / (1.5 + 1))² = 0.04. A single pane has two surfaces, front and back, so it reflects roughly 8% in total (Wikipedia: Fresnel equations).

In daylight, 8% does not matter. The street is thousands of times brighter than your room, so the weak mirror image of the room is lost under it.

At night the balance flips. Here are some typical light levels from the Wikipedia table on lux:

Scene	Illuminance
Full moon on a clear night	0.05–0.3 lux
Dark limit of civil twilight	3.4 lux
Public areas with dark surroundings	20–50 lux
Family living room lights	50 lux

Now put those together in a simple model. I am treating the room and the street as if their surfaces reflect light equally well, which real scenes don't, so read these as rough ratios, not measurements:

Outside scene	Glass	Room reflection vs. outside scene
Moonlit yard (0.3 lux)	Single pane	reflection ≈ 14× brighter
Moonlit yard (0.3 lux)	Double glazing	reflection ≈ 30× brighter
Dusk (3.4 lux)	Single pane	about equal (1.25×)
Lit street (20 lux)	Single pane	scene ≈ 5× brighter

(For double glazing I used four surfaces: 1 − 0.96⁴ ≈ 15% reflected. The script that made these numbers is one line of arithmetic per row; the room is 50 lux in every case.)

That table explains almost every complaint. If the outside is lit by a streetlight, you usually see the street with a faint ghost of the room on top. If the outside is lit only by the moon, the room wins by a wide margin and the camera records a picture of your ceiling light.

The camera's auto-exposure makes it worse, not better. It sets brightness for the whole frame, and the brightest thing in the frame is now the reflection, so it exposes for that. (If faces or objects come out black for a different reason, a bright background, see the companion piece: Why Do Faces Come Out Black on My Phone Security Camera?)

The one fix that matters most: lens flat against the glass

A reflection reaches the lens only if light from the room hits the glass in front of the lens and bounces back into it. If the lens is touching the glass, or nearly touching it, the patch of glass in front of the lens is covered by the phone itself. Room light cannot reach that patch, so there is nothing to bounce.

In practice:

Put the camera lens right against the glass. A few millimetres is fine; a few centimetres is not. Every centimetre of gap lets room light in from the sides.
Block the sides with something dark. A ring cut from black foam, a folded black cloth, or a strip of dark tape around the lens. Photographers use rubber lens hoods pressed against windows for exactly this reason. Your version can cost nothing.
Keep the phone square to the glass. A small tilt is fine. A steep angle is not: glass reflects more as the angle gets shallower, which is why a window looks like a mirror when you look along it.

If you only do one thing from this article, do this one. It removes the problem rather than reducing it.

Turn off the light behind the camera

If the lens can't sit flat on the glass (a deep window ledge, a curtain rail in the way), the next best fix is to take away the thing being reflected.

Switch off or dim the light directly behind the phone. Ceiling lights and tube lights are the worst offenders, because they are the brightest objects in the room.
Move lamps to the side. A light that is out of the camera's reflected view does not appear in the footage, even if it is on.
Watch for small, bright sources. A TV, a router's LEDs, a charger light, or a lit phone screen all show up as bright spots in a dark night frame.

That last one is worth a moment. A phone recording with its screen on is itself a light source, sitting a few centimetres from the glass, aimed straight at it. Recording with the screen off removes that source entirely. That is one of the reasons Background Camera RemoteStream records with the screen off: no glowing screen on the windowsill, no screen reflection in the footage, and less heat and battery drain on top.

Double glazing: why you see a ghost of every streetlight

Double-glazed windows have two panes and four surfaces. Putting the lens on the inner pane stops room reflections, but there is a second effect you can't fix the same way: bright outdoor lights bounce between the two panes and show up as a faint second copy, slightly offset from the real one.

You'll notice it as a "ghost" streetlight or a double headlight. For a security camera, it is mostly cosmetic. It does not hide a person walking past. What helps:

Aim so the brightest streetlight is near the edge of the frame or out of it. Ghosts are offset in a consistent direction, so a light at the edge often has its ghost pushed out of the frame.
Clean both inner surfaces you can reach. Smudges and dust spread a bright light into a haze that covers far more of the picture than a ghost does.
Check for condensation. A damp morning can fog the inner pane on the room side. Fog turns every outdoor light into a big glowing blob.

Mosquito mesh and window grilles

In many homes and shops, the window has a mosquito mesh, a metal grille, or both. These cause different problems depending on how far they are from the lens.

Mesh pressed against the lens. Any object much closer than the lens's minimum focus distance is rendered as a heavy blur. So a mesh touching the lens does not appear as a sharp pattern. Instead it blocks some of the light and lowers contrast, like looking through a dirty glass. At night it also scatters streetlight into a soft glow. A phone camera's opening is only a few millimetres across (for example, a lens with a 4.7 mm focal length at f/1.8 has an entrance opening of about 4.7 / 1.8 ≈ 2.6 mm), so a mesh strand crossing it blocks a meaningful share of the light.

Mesh or grille further away. If the grille is, say, 20–40 cm in front of the phone, it may be far enough away that the camera can focus on it. In low light, autofocus has less to work with and may settle on the grille bars instead of the street, leaving the gate soft all night.

What works:

Find a gap. If the grille has openings bigger than the phone's lens, put the lens through a gap or right in the middle of one, so the bars are out of the view.
If you can't avoid the mesh, make it touch. A mesh pressed flat against the lens is better than a mesh 5 cm away. Up close, it becomes a light blur; a short distance away, it becomes a visible pattern over everything.
Open the mesh panel if it slides. Many mesh frames slide or hinge. A small opening in one corner, with the phone inside it, solves the problem entirely, and mosquitoes will not care about a gap the size of a phone.
Test focus at night, not in the daytime. Autofocus that looks fine at noon can behave differently at 11 pm.

For developers: on Android's Camera2 API, LENS_INFO_MINIMUM_FOCUS_DISTANCE tells you the closest distance a lens can focus, in diopters, and is 0 for a fixed-focus lens. Setting CONTROL_AF_MODE_OFF and choosing a LENS_FOCUS_DISTANCE lets an app hold focus at a set distance so it can't drift onto a grille in low light. (There's more on how focus, exposure and white balance behave over long recordings in Camera2 API: Handling Orientation, Focus, and Exposure in Background.)

Offline security camera through a window: the night test

Here is a five-minute test that tells you whether your setup works, without guessing. It needs no internet, no account, and no cloud.

Set up the phone in the exact spot, lens against the glass, at the time you'll actually use it: after dark, with the room lights as they normally are.
Start recording with the screen off.
Look at the live picture from another device on the same Wi-Fi. Background Camera RemoteStream has a built-in web server, so you can open the live view in a browser on a second phone or laptop on your home network (the Play listing puts this browser view in the Pro tier). Without it, record for five minutes and play the clip back instead. The camera's video stays on the camera phone; nothing is uploaded anywhere. This also lets you check the frame without walking up to the window and lighting it with your own phone screen.
Walk past the window outside while someone watches the live view, or review the recording afterwards.
Change one thing at a time: lights off behind the phone, a dark cloth around the lens, lens moved to a grille gap. Re-check after each change.

If you want an off-site copy as well, the app can also stream to YouTube Live (also listed under Pro), but that needs a working internet connection. Local recording and the LAN live view work without one.

What the glass cannot fix

Being honest about the limits saves wasted evenings:

Glass blocks some light. Each surface reflects about 4%, so a single pane passes about 92% and double glazing about 85%. On a moonlit night, that loss sits on top of a scene that is already very dark. For what phones can and can't see at night in general, read Can an Old Android Phone See in the Dark?
Tinted or coated glass is different. Some windows have coatings or films that reflect more than plain glass. The lens-on-glass fix still works best, but expect a darker picture.
Most phones have no infrared light of their own. A dedicated CCTV camera with infrared LEDs behind glass has the opposite problem: its own IR bounces straight back off the window. A phone without an IR illuminator doesn't have that issue, but it also can't light up a dark yard. A small outdoor light on a sensor helps more than any setting.

Quick checklist

Lens touching the glass (or within a few millimetres)
Dark foam, cloth or tape around the lens
Light directly behind the phone off or moved
Screen off while recording
Lens in a grille gap, or mesh pressed flat against it
Glass clean on both sides you can reach
Night test done, checked live or from a playback

If you're setting up an old phone as a 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 here for the window.

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

clip_08.mp4 Stopped My Bash Loop and the Script Still Exited 0: A Leading Zero Means Octal in Bash Arithmetic

Super Funicular — Sun, 01 Nov 2026 07:55:12 +0000

A small Bash loop takes zero-padded camera clip names, pulls out the number, and works out the number of the clip that comes next. It handles clip_07.mp4. At clip_08.mp4 it prints one error line, skips clip_08, clip_09 and clip_10 without another word, carries on with the rest of the script, and exits 0.

Here is the loop:

#!/bin/bash
# for each clip, work out the number of the clip that follows it
for f in clip_07.mp4 clip_08.mp4 clip_09.mp4 clip_10.mp4; do
  n=${f#clip_}; n=${n%.mp4}
  echo "start $f"
  next=$((n + 1))
  echo "  next is $next"
done
echo "after the loop"

Run with bash next_clip.sh, then print $?:

start clip_07.mp4
  next is 8
start clip_08.mp4
next_clip.sh: line 6: 08: value too great for base (error token is "08")
after the loop
exit status: 0

Two things went wrong, and the second is the one that costs you clips. The first is that Bash read 08 as an octal number and rejected it. The second is that the error did not stop the script. It abandoned the loop, and the script went on to its last line as if the loop had finished.

Disclosure: I make an Android camera app. Nothing below uses its code or describes how it names, numbers or stores clips. The clip names are made up, 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
date (GNU coreutils) 8.32
expr (GNU coreutils) 8.32
GNU Awk 5.1.0, API: 3.0 (GNU MPFR 4.1.0, GNU MP 6.2.1)
Python 3.10.12

A leading zero means octal

The Bash Reference Manual's section on shell arithmetic is short about this: "Constants with a leading 0 are interpreted as octal numbers." That sentence has been in the manual since at least the 2.05a edition, which is the copy I read it in.

Octal digits run from 0 to 7. So 07 is a fine octal number, 08 and 09 are not numbers at all, and 010 is a number, but it is eight, not ten:

#!/bin/bash
for n in 07 08 09 010 012; do
  echo "n=$n  \$((n + 1)) -> $( (echo $((n + 1))) 2>&1 )"
done

n=07  $((n + 1)) -> 8
n=08  $((n + 1)) -> constants.sh: line 3: 08: value too great for base (error token is "08")
n=09  $((n + 1)) -> constants.sh: line 3: 09: value too great for base (error token is "09")
n=010  $((n + 1)) -> 9
n=012  $((n + 1)) -> 11

The errors are the lucky case. 08 and 09 fail loudly. 010 and 012 do not fail. They come back as 9 and 11, the right answers for octal eight and ten, plus one. A loop that walks clip_010.mp4, clip_011.mp4 and so on with three-digit padding will compute wrong numbers with no error at all, until it reaches a name with an 8 or a 9 in it.

This is why the bug looks random. With two-digit padding, clips 01 to 07 work, clips 08 and 09 break, and from clip 10 onward everything works again, because 10 has no leading zero.

The error abandons the loop, not the script

The part I did not expect was what happened after the error. clip_08.mp4 printed start, then the error, and then nothing else from the loop. clip_09 and clip_10 did not print start at all. The line after the loop ran, and the exit status was 0.

That 0 is the status of the last command, the final echo. The failure left one line on stderr and nothing in the exit status. In a cron job whose stderr goes nowhere, that is a silent skip.

Bash has a mode that treats this differently. In the list of things that change in POSIX mode, the same manual says: "Non-interactive shells exit if a syntax error in an arithmetic expansion results in an invalid expression." I ran the same script three ways:

#!/bin/bash
for sh in "bash" "bash --posix" "dash"; do
  echo "== $sh next_clip.sh"
  $sh next_clip.sh 2>&1
  echo "exit status: $?"
done

== bash next_clip.sh
start clip_07.mp4
  next is 8
start clip_08.mp4
next_clip.sh: line 6: 08: value too great for base (error token is "08")
after the loop
exit status: 0
== bash --posix next_clip.sh
start clip_07.mp4
  next is 8
start clip_08.mp4
next_clip.sh: line 6: 08: value too great for base (error token is "08")
exit status: 1
== dash next_clip.sh
start clip_07.mp4
  next is 8
start clip_08.mp4
next_clip.sh: 6: Illegal number: 08
exit status: 2

Default Bash abandoned the loop and kept going. bash --posix stopped the script with status 1. dash, which is /bin/sh on this system, stopped with status 2. So the same file behaves differently depending on which shell runs it, and the one that hid the failure here was plain bash.

I did not test set -e here. I am not making a claim about whether it would have stopped this script.

Not every comparison does arithmetic

The next surprise is that the three common ways to compare numbers in Bash do not agree about 08 or about 010:

#!/bin/bash
for n in 08 010; do
  printf 'n=%-4s' "$n"
  printf '[ -lt 9 ]: '; [ "$n" -lt 9 ] && printf 'yes  ' || printf 'no  '
  printf '[[ -lt 9 ]]: '; ( [[ $n -lt 9 ]] && printf 'yes  ' || printf 'no  ' ) 2>&1 | tr '\n' ' '
  printf '(( n < 9 )): '; ( (( n < 9 )) && printf 'yes' || printf 'no' ) 2>&1 | tr '\n' ' '
  echo
done

n=08  [ -lt 9 ]: yes  [[ -lt 9 ]]: compare.sh: line 5: [[: 08: value too great for base (error token is "08") no  (( n < 9 )): compare.sh: line 6: ((: 08: value too great for base (error token is "08") no
n=010 [ -lt 9 ]: no  [[ -lt 9 ]]: yes  (( n < 9 )): yes

The single-bracket test read 08 as eight and 010 as ten. It compared them as decimal integers here.
The double-bracket test and (( )) both read them as arithmetic. 08 was an error, and 010 was eight, so it came out less than 9.

So for 010 the single-bracket test said no and the double-bracket test said yes, on the same shell and the same value. Moving a test from single to double brackets changes the answer for zero-padded input.

The hour field does this every morning

The most common place to meet this is date +%H, which pads the hour to two digits. An hourly job that does arithmetic on the hour works all day except at 8 and 9 in the morning:

#!/bin/bash
# what an hourly job sees at half past each hour
for h in 07 08 09 10; do
  hh=$(date -u -d "2026-10-29 $h:30" +%H)
  bare=$(date -u -d "2026-10-29 $h:30" +%-H)
  echo "%H=$hh  \$((hh + 1)) -> $( (echo $((hh + 1))) 2>&1 )"
  echo "       %-H=$bare  \$((bare + 1)) -> $((bare + 1))"
done

%H=07  $((hh + 1)) -> 8
       %-H=7  $((bare + 1)) -> 8
%H=08  $((hh + 1)) -> hours.sh: line 6: 08: value too great for base (error token is "08")
       %-H=8  $((bare + 1)) -> 9
%H=09  $((hh + 1)) -> hours.sh: line 6: 09: value too great for base (error token is "09")
       %-H=9  $((bare + 1)) -> 10
%H=10  $((hh + 1)) -> 11
       %-H=10  $((bare + 1)) -> 11

The times are pinned with -d and -u so the output does not depend on when you run it. %H gives 08 and 09, and both fail. GNU date also accepts %-H, where the hyphen asks for no padding, and that version works for every hour. The same hyphen worked on other fields I tried, %-M for minutes and %-d for the day of the month.

Forcing base ten

Bash lets you name the base of a number with base#value, and the manual describes that form in the sentences right after the octal rule. 10#08 is eight read in base ten, and with it the loop works for every name:

#!/bin/bash
for f in clip_07.mp4 clip_08.mp4 clip_09.mp4 clip_10.mp4; do
  n=${f#clip_}; n=${n%.mp4}
  next=$((10#$n + 1))
  printf '%s -> clip_%02d.mp4\n' "$f" "$next"
done

clip_07.mp4 -> clip_08.mp4
clip_08.mp4 -> clip_09.mp4
clip_09.mp4 -> clip_10.mp4
clip_10.mp4 -> clip_11.mp4

printf '%02d' puts the padding back for the next name. Note that this is printing a number that is already decimal, so the octal problem does not apply to it.

10# has edges of its own. On this version it rejects an empty value and a value with a sign in front, and it fails on anything that is not digits:

#!/bin/bash
for n in "08" "" "-08" "x8"; do
  echo "n='$n'  \$((10#\$n + 1)) -> $( (echo $((10#$n + 1))) 2>&1 )"
done

n='08'  $((10#$n + 1)) -> 9
n=''  $((10#$n + 1)) -> edges.sh: line 3: 10#: invalid integer constant (error token is "10#")
n='-08'  $((10#$n + 1)) -> edges.sh: line 3: 10#: invalid integer constant (error token is "10#")
n='x8'  $((10#$n + 1)) -> edges.sh: line 3: 10#x8: value too great for base (error token is "10#x8")

An empty value is what you get when the name does not match the pattern you stripped, so in a real loop it is the likely case, not an exotic one. A minus sign could come from a name like clip_-08.mp4 or from a subtraction earlier in the script. Newer Bash releases may handle the signed case differently. I did not test any other version, and I make no claim about them.

The safest shape I found is to check that the value is digits before any arithmetic, and to make the check fail in a way the caller can see:

#!/bin/bash
next_number() {
  local n=$1
  [[ $n =~ ^[0-9]+$ ]] || { echo "not a clip number: '$n'" >&2; return 1; }
  echo $((10#$n + 1))
}
for n in 08 09 "" x8; do
  out=$(next_number "$n") && echo "'$n' -> $out" || echo "'$n' -> skipped, status $?"
done

'08' -> 9
'09' -> 10
not a clip number: ''
'' -> skipped, status 1
not a clip number: 'x8'
'x8' -> skipped, status 1

Bad input now produces a message and a non-zero status for that one call, and the loop moves on to the next name on purpose rather than by accident.

What to change in a script like this

Assume a padded value is a string, not a number, until it is converted. Clip numbers, hours from date +%H, minutes, days of the month and parts of a file name are all likely to be padded.
Convert with $((10#$n)), and check that $n is only digits before you do.
When you only need the number for display or comparison, ask for it unpadded, as in date +%-H.
Do not switch a numeric test from single to double brackets on padded input without checking, because the two can give different answers.
Count the items your loop processed and compare that with the number you expected, and log both. A loop that is abandoned partway leaves no other sign in the exit status.
If a script must stop on an arithmetic error, test it under the shell that actually runs it. Default Bash, bash --posix and dash did three different things here.

Things I did not test

Other Bash versions. I ran Bash 5.1. The octal sentence is old and I expect it to hold, but I did not run another release, and the behavior of 10# with a sign or an empty value is the part most likely to differ.
set -e and errexit traps. I did not check whether either would have stopped the default-mode script.
zsh, ksh and BusyBox. I ran Bash and dash only. Other shells have their own rules for leading zeros, and I make no claim about them.
Non-GNU date, expr and awk. The %-H hyphen is a GNU date feature here, and I did not test any other date.

Sources. Both quotes are from the GNU Bash Reference Manual, read in the archived 2.05a edition, chapter 6: Bash Features (sections 6.5 Shell Arithmetic and 6.11 Bash POSIX Mode). The current manual's section is Shell Arithmetic; that page did not load for me while checking, so the quotes are from the archived copy. Outputs are pasted unedited from the scripts above.

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

Until 10# turns it into a decimal, a padded clip number is octal to Bash, and the clip after clip_07 is where the loop quietly stops.

Why Do Faces Come Out Black on My Phone Security Camera? Backlight, Auto-Exposure, and Where to Point the Phone

Super Funicular — Sat, 31 Oct 2026 17:26:46 +0000

You set up an old Android phone as a camera at the shop door or the front entrance. The picture looks fine on the shelf. Then you check the recording: the street outside is bright and clear, and the person who walked in is a dark shape with no face.

This is not a broken camera, and it is not low light. It is backlight, and it is one of the most common reasons a phone security camera records footage you cannot use.

Why do faces come out black on a phone security camera?

Short answer: the phone sets one brightness for the whole picture. If a bright doorway, window, glass shop front or sky fills a large part of the frame, the camera darkens everything to keep that bright area from turning white. The person standing in front of it is much darker than the background, so they drop to near-black. The fix is mostly placement: put the bright light behind or beside the camera, not behind the person, and keep bright areas small in the frame.

The rest of this guide explains why, shows the numbers, gives a 10-minute test, and (for developers) lists the Camera2 controls that affect it.

What the phone is actually doing

Every Android camera runs an auto-exposure routine (AE). Its job is to pick a shutter time and sensor gain so the picture is "correctly" bright. In Android's Camera2 API, when AE is on, Google's reference says it overrides the exposure time, sensitivity and frame duration the app asks for. The phone, not the app, decides.

To decide, AE measures the brightness of the scene. How each phone weighs the frame is the manufacturer's own algorithm, and it is not published. But the basic behaviour is the same everywhere: a large bright area pulls the whole exposure down.

Brightness in photography is counted in EV (exposure value). Android's own documentation puts it simply: one EV step doubles the image brightness, and minus one EV halves it. So:

Difference	Brightness factor
1 EV	2×
2 EV	4×
3 EV	8×
4 EV	16×
5 EV	32×

A sunny street seen through a shop door is easily several EV brighter than the shaded room inside. That is the gap the camera has to deal with.

A simple model of the problem

Real phones do not just average the frame, so treat this as an illustration, not a measurement of any phone. Imagine the phone averages brightness and sets the average to its target.

70% of the frame is the room (brightness 1).
30% of the frame is the doorway, 5 EV brighter (brightness 32).

The average is 0.7 × 1 + 0.3 × 32 = 10.3. To bring that average to the target, the camera darkens everything by about 10×. The room, and the person in it, end up at roughly one tenth of normal brightness, about −3.4 EV. That is a silhouette.

The same model with other numbers:

Bright area of frame	Bright area is…	Room/person ends up at
10%	3 EV brighter	−0.8 EV (slightly dark)
10%	5 EV brighter	−2.0 EV (dark)
30%	3 EV brighter	−1.6 EV
30%	5 EV brighter	−3.4 EV (silhouette)
50%	5 EV brighter	−4.0 EV (silhouette)

Two things stand out. Size matters: a small bright patch does little harm. Brightness gap matters: the same doorway at dusk is fine, and at noon it ruins the shot. That is why a camera can look perfect when you set it up in the evening and fail the next afternoon.

(These figures were computed with a short script for this article. They come from the simplified averaging model above, not from any real phone.)

Why "just make it brighter" is not enough

Many camera apps and phones offer exposure compensation (the +/− brightness slider). In the model above, +2 EV brings the room from −3.4 EV to about −1.4 EV. Better, but still dark.

And the doorway, which was already above target, goes from about +1.6 EV to about +3.6 EV: now the street is plain white. You traded a black face for a white background. With a strong backlight, the phone's sensor cannot hold both ends at once. Changing the brightness only chooses which end you lose.

So the real fixes are about light and position.

Fix 1: Put the light behind the camera, not behind the person

This is the single most effective change.

Shop with a glass front: do not mount the phone at the back of the shop looking out at the street. Mount it near the front, high up, looking in toward the counter and the door from the inside edge. Customers walking in are then lit by the daylight coming through the glass, instead of standing in front of it.
Home entrance: point the camera at the door from the side, not from the far end of a hallway with the door's window in the middle of the frame.
Window: a window in the frame is a bright panel all day. Turn the phone so the window is at the edge of the picture, or out of it.

Fix 2: Make the bright area smaller

If you cannot move the camera, change what it sees.

Tilt the phone down a little so less sky, street or doorway is in frame.
Frame tighter on the area that matters: the counter, the cash drawer, the inside of the door.
A curtain, a blind half-closed, or a tinted film on a glass door reduces the brightness gap. You are lowering the 5 EV, not fighting it.

Fix 3: Add light on the person's side

A cheap LED bulb or tube light inside the entrance, on the camera's side, lifts the face toward the background's brightness. Narrowing the gap by even 1–2 EV can turn a silhouette into a recognisable face. In shops this often costs less than any camera upgrade.

Fix 4: Test at the worst hour

A backlit camera fails at a particular time of day, so test then.

Find the hour when the bright area is brightest: midday for a door facing the sun, late afternoon for a west-facing window, evening if headlights shine in.
Start the recording and stand where a visitor would stand, facing the camera, for 30 seconds. Then walk in and out once.
Stop and play the clip. Pause on your own face. Can you recognise yourself? Can you read printed text held at chest height?
Change one thing (angle, tilt, light) and repeat. Keep the setup that passes.

Ten minutes at the worst hour tells you more than a full day of guessing. If the camera supports live view in a browser on your Wi-Fi, you can watch the result from another phone while you adjust, without touching the camera phone.

Does this work as an offline security camera without internet?

Yes. Backlight is about light and position, and none of these fixes need internet or a cloud service. A phone recording to its own storage on a local network, or fully offline, behaves exactly the same. The test above works with no data plan at all. If you are setting up a shop camera with no internet plan, see how to watch your shop with an old Android phone, no internet plan, no subscription.

For developers: the Camera2 controls involved

If you build camera apps, here is what Android's Camera2 reference says about the controls that touch this problem. All of this is from Google's public API documentation for CaptureRequest and CameraCharacteristics.

CONTROL_AE_REGIONS, metering areas. An app can tell AE which part of the frame to measure, using weighted rectangles. A region on the doorway's inside edge, or the counter, would tell AE to expose for the person rather than the street. Two catches:

It is only available if CONTROL_MAX_REGIONS_AE is greater than 0. The docs only guarantee at least 1 region on FULL-capability devices. On many older budget phones (often LEGACY or LIMITED), you may get zero metering regions. Check before relying on it.
The coordinates are in the sensor's active array, not your preview. The docs warn that if the preview aspect ratio differs from the crop region (for example 16:9 preview from a 4:3 sensor), you must account for the extra crop. Get this wrong and your region meters the wrong part of the scene.

CONTROL_AE_EXPOSURE_COMPENSATION, the brightness offset. Counted in steps of CONTROL_AE_COMPENSATION_STEP (often 1/3 or 1/2 EV). If CONTROL_AE_COMPENSATION_RANGE is [0, 0], compensation is not supported. For LIMITED and FULL devices that support it, the range must reach at least −2 EV and +2 EV; the docs say LEGACY devices may support a smaller range. After a change, AE can take several frames to settle. As shown above, compensation alone cannot rescue a strong backlight.

CONTROL_AE_LOCK, freezing exposure. Tempting: set it once when the scene looks right and lock it. For a 24/7 camera that is a trap. A lock keeps the exposure from one moment, and daylight changes for hours afterwards. A setting locked at noon will be far too dark at dusk. Support is reported by CONTROL_AE_LOCK_AVAILABLE, which is guaranteed true only on devices with MANUAL_SENSOR or BURST_CAPTURE capability.

The practical lesson for app developers matches the one for users: metering tricks help at the margin, but on old phones you cannot assume they exist, and no software setting removes a 5 EV gap. Placement guidance is worth more than an exposure slider.

Related: low light is a different problem from backlight. For dark scenes, see our correction on brightening live video in low light and why night footage looks smeary. If your frame looks narrower in the recording than in the camera app, that is video stabilization cropping the edges, which also changes how much bright area ends up in the shot.

Where Background Camera RemoteStream fits

Background Camera RemoteStream turns a spare Android phone into a camera that keeps recording with the screen off, stores the video on the phone itself (no cloud account needed), and can show the camera live in a browser on your own Wi-Fi. If you want people outside your Wi-Fi to watch live, it can stream to YouTube Live. Check the Play listing for which features are in the free version and which are in Pro.

Live view is useful for exactly this job: you can stand at the door and check on another phone whether your face is visible, then move the camera until it is. More setup guides: superfunicular.com.

What this guide does not tell you

How your phone's auto-exposure weighs the frame. That algorithm is the manufacturer's and is not published. The table above is a simplified averaging model, not a measurement.
Whether your phone supports metering regions or exposure compensation. That depends on the camera hardware level. The only reliable answer is to query the device.
How a specific app uses these controls. This guide describes the Android API, not any app's internals.

Sources: Android Developers API reference, CaptureRequest (CONTROL_AE_MODE, CONTROL_AE_REGIONS, CONTROL_AE_EXPOSURE_COMPENSATION, CONTROL_AE_LOCK) and CameraCharacteristics (CONTROL_AE_COMPENSATION_RANGE, CONTROL_AE_COMPENSATION_STEP, CONTROL_MAX_REGIONS_AE, CONTROL_AE_LOCK_AVAILABLE), read on 31 October 2026. EV tables computed with a short script for this article.

Python's round() and JavaScript's Math.round() Disagree on Half the Days in a Footage Summary

Super Funicular — Thu, 29 Oct 2026 16:56:50 +0000

Here is a four-day summary of camera footage, in minutes, rounded to whole hours. Python and Node are given the same numbers and the same job:

# footage.py: hours of footage per day, rounded to whole hours for a summary
minutes = {"Mon": 150, "Tue": 90, "Wed": 210, "Thu": 30}

total = 0
for day, m in minutes.items():
    hours = m / 60
    print(day, hours, "->", round(hours))
    total += round(hours)
print("sum of rounded:", total, "| true total:", sum(minutes.values()) / 60)

// footage.js: the same summary in a Node dashboard
const minutes = { Mon: 150, Tue: 90, Wed: 210, Thu: 30 };

let total = 0;
for (const [day, m] of Object.entries(minutes)) {
  const hours = m / 60;
  console.log(day, hours, "->", Math.round(hours));
  total += Math.round(hours);
}
console.log("sum of rounded:", total, "| true total:", Object.values(minutes).reduce((a, b) => a + b) / 60);

python3 footage.py
node footage.js

Mon 2.5 -> 2
Tue 1.5 -> 2
Wed 3.5 -> 4
Thu 0.5 -> 0
sum of rounded: 8 | true total: 8.0
Mon 2.5 -> 3
Tue 1.5 -> 2
Wed 3.5 -> 4
Thu 0.5 -> 1
sum of rounded: 10 | true total: 8

Two of the four days disagree, and the totals differ by two hours. Neither program has a bug. They round halves by different rules, and every day in this example lands exactly on a half.

Python's total happens to match the true total of eight hours. The per-day values do not look like school rounding at all: Monday's 2.5 hours became 2 and Thursday's half hour became 0. If a reader checks one row by hand, Python looks wrong. If the reader adds up the rows, Node looks wrong.

Disclosure: I make an Android camera app. Nothing below uses its code or describes how it counts or stores anything. The minutes are typed in by hand, the scripts are a desktop Python and Node, and every output is pasted from the scripts shown. Versions:

Python 3.10.12
v22.23.4

What round() is documented to do

Python's built-in docs state the rule plainly: "if two multiples are equally close, rounding is done toward the even choice". Their own examples are that round(0.5) and round(-0.5) are both 0, and round(1.5) is 2. This is often called banker's rounding, or half to even.

Running a few halves through both languages shows each rule:

# cases.py: what round() and format() do with halves
from decimal import Decimal

for x in (0.5, 1.5, 2.5, 3.5, -0.5, -2.5):
    print("round(%s) = %s" % (x, round(x)))
print("round(2.675, 2) =", round(2.675, 2))
print("stored value of 2.675:", Decimal(2.675))
print("f'{2.5:.0f}' =", f"{2.5:.0f}")
print("f'{2.675:.2f}' =", f"{2.675:.2f}")

round(0.5) = 0
round(1.5) = 2
round(2.5) = 2
round(3.5) = 4
round(-0.5) = 0
round(-2.5) = -2
round(2.675, 2) = 2.67
stored value of 2.675: 2.67499999999999982236431605997495353221893310546875
f'{2.5:.0f}' = 2
f'{2.675:.2f}' = 2.67

// cases.js: the JavaScript side of the same halves
for (const x of [0.5, 1.5, 2.5, 3.5, -0.5, -2.5]) {
  console.log(`Math.round(${x}) = ${Math.round(x)}`);
}
console.log("(2.675).toFixed(2) =", (2.675).toFixed(2));
console.log("(2.5).toFixed(0) =", (2.5).toFixed(0));

Math.round(0.5) = 1
Math.round(1.5) = 2
Math.round(2.5) = 3
Math.round(3.5) = 4
Math.round(-0.5) = 0
Math.round(-2.5) = -2
(2.675).toFixed(2) = 2.67
(2.5).toFixed(0) = 3

Read the two lists side by side:

Python's round() sends each exact half to the even neighbour: 0.5 to 0, 2.5 to 2, 3.5 to 4, and -2.5 to -2.
JavaScript's Math.round sent every positive half up, and sent -2.5 to -2, not -3. So in this run it does not round away from zero either. Halves went toward the larger number.
Python's string formatting with .0f printed 2 for 2.5, the same as round(). Switching from round() to an f-string does not change the rule.
JavaScript's toFixed(0) printed 3 for 2.5. So even inside one language, two built-in ways to round a half gave different answers here.

The case that is not about halves at all

round(2.675, 2) printed 2.67, and so did JavaScript's toFixed(2). That looks like half to even again, since 7 is odd and 8 is even. It is not. The docs give this exact example in a note: "This is not a bug: it’s a result of the fact that most decimal fractions can’t be represented exactly as a float."

The line in cases.py that prints the stored value shows why. Converting the float to Decimal writes out the binary value it really holds, and that value is a little below 2.675. There is no tie to break. The nearest two-place answer to the stored number is 2.67, and both languages return it.

So there are two separate effects, and they are easy to confuse:

A tie rule decides what happens when a value is exactly halfway. Python and JavaScript use different rules.
Float storage means many values you type as halves, at two or more decimal places, are not halfway in memory. No tie rule applies to them, because there is no tie.

Halves like 0.5, 1.5 and 2.5 are exact in binary, which is why the first list behaves according to the tie rule. Values like 2.675 are not, which is why they surprise people who already know about the tie rule.

Getting school rounding on purpose

The decimal module names its modes in words. ROUND_HALF_EVEN is documented as "Round to nearest with ties going to nearest even integer." and ROUND_HALF_UP as "Round to nearest with ties going away from zero."

ROUND_HALF_UP is the rule most people learned in school:

# half_up.py: school rounding with decimal, from the string and from the float
from decimal import Decimal, ROUND_HALF_UP

def half_up(x, places="1"):
    return Decimal(str(x)).quantize(Decimal(places), rounding=ROUND_HALF_UP)

for x in (0.5, 1.5, 2.5, -2.5):
    print(x, "->", half_up(x))
print("2.675 via str   ->", half_up(2.675, "0.01"))
print("2.675 via float ->", Decimal(2.675).quantize(Decimal("0.01"), rounding=ROUND_HALF_UP))

0.5 -> 1
1.5 -> 2
2.5 -> 3
-2.5 -> -3
2.675 via str   -> 2.68
2.675 via float -> 2.67

Building the Decimal from str(x) gives 2.68, because the string is the short decimal 2.675. Building it from the float directly gives 2.67, because the decimal docs say construction from a float "performs an exact conversion", and the exact value is the one just below 2.675. If you want school rounding, the conversion step matters as much as the rounding mode.

That str() step only helps when the float already holds the decimal you meant. When the value comes out of arithmetic, str() faithfully prints the arithmetic's result:

# str_caveat.py: str() only helps when the float already holds the decimal you meant
from decimal import Decimal, ROUND_HALF_UP

x = 1.1 + 1.2 + 0.05
print("x =", x)
print("half up to 0.1 via str ->", Decimal(str(x)).quantize(Decimal("0.1"), rounding=ROUND_HALF_UP))

x = 2.3499999999999996
half up to 0.1 via str -> 2.3

On paper, 1.1 + 1.2 + 0.05 is 2.35, which rounds half up to 2.4. The float sum is 2.3499999999999996, str() keeps those digits, and the answer is 2.3. To avoid that, the inputs have to be decimals from the start, for example by reading them from text as Decimal('1.1') rather than converting floats after the fact.

The one-line half up that is not one

A common shortcut is math.floor(x + 0.5). It looks like school rounding:

# floor_trick.py: the one-line "round half up" that is not one
import math

for x in (2.5, -2.5, 0.49999999999999994):
    print(repr(x), "-> floor(x + 0.5) =", math.floor(x + 0.5))

2.5 -> floor(x + 0.5) = 3
-2.5 -> floor(x + 0.5) = -2
0.49999999999999994 -> floor(x + 0.5) = 1

It does round 2.5 to 3. It rounds -2.5 to -2, which is the JavaScript result, not school rounding. And the third line is the one that breaks it: the largest float below one half goes to 1. Adding 0.5 to it produces a sum that cannot be stored exactly, the sum is rounded up to 1.0 by the float addition itself, and the floor of 1.0 is 1. A value that is less than one half rounds up.

Why the default is half to even

Half to even is not an oddity in Python. It exists to stop rounding from pushing totals in one direction. This script rounds every half from 0.5 up to 99.5 both ways and compares the sums:

# bias.py: round every half from 0.5 to 99.5, then compare the sums
from decimal import Decimal, ROUND_HALF_UP

halves = [k + 0.5 for k in range(100)]
true_sum = sum(halves)
even_sum = sum(round(x) for x in halves)
up_sum = sum(int(Decimal(str(x)).quantize(Decimal("1"), rounding=ROUND_HALF_UP)) for x in halves)
print("true sum:", true_sum)
print("half-even sum:", even_sum, "| off by", even_sum - true_sum)
print("half-up sum:", up_sum, "| off by", up_sum - true_sum)

true sum: 5000.0
half-even sum: 5000 | off by 0.0
half-up sum: 5050 | off by 50.0

Half up adds half a unit for every tie, so with a hundred ties the total is off by fifty. Half to even sends half of them up and half down, and the errors cancel. That is the same effect as the footage example at the top, where Python's per-day numbers looked wrong but the total came out right.

That is a good property for sums, and a confusing one for a single displayed number. Which one you want depends on who reads the result.

Often the better fix: do not round floats at all

The footage data started as whole minutes. Keeping it in integers until the last step gives an exact answer with a rule you choose:

# integer.py: keep minutes as integers and round once, exactly
minutes = {"Mon": 150, "Tue": 90, "Wed": 210, "Thu": 30}

for day, m in minutes.items():
    print(day, m, "min ->", (m + 30) // 60, "h")
total = sum(minutes.values())
print("total:", total, "min ->", (total + 30) // 60, "h")

Mon 150 min -> 3 h
Tue 90 min -> 2 h
Wed 210 min -> 4 h
Thu 30 min -> 1 h
total: 480 min -> 8 h

(m + 30) // 60 is half up for minutes that are zero or positive, with no float involved. It is not a general rounding function, and it would need a different formula for negative values, but footage durations are not negative. The total is rounded once, from the exact sum, instead of being built from rounded parts.

Checklist

Decide which tie rule each number needs, and write it down in the code, not in a comment about what round() is assumed to do.
When two programs show the same number, check that they round it the same way. Python's round() and JavaScript's Math.round do not.
For display rules like school rounding, use decimal with ROUND_HALF_UP, and build the Decimal from text, not from a float.
Do not use math.floor(x + 0.5) as a rounding function.
If the data starts as whole units, such as seconds, minutes or bytes, do the arithmetic in integers and round once at the end.
For totals, round the sum, not the parts. If the parts must also be shown, expect them to not add up exactly, and say so in the report.

Things I did not test

Newer Python. I ran 3.10. The quotes come from the current online documentation. The behaviour matched what I saw, but I did not run a newer interpreter.
Browsers. The JavaScript ran in Node. I did not run these lines in a browser.
Other tools. Spreadsheets, databases and other languages each have their own rounding functions and rules. I did not test any of them, and I make no claim about what they do.
NumPy and pandas. Their rounding functions are separate from the built-in round(). Nothing here covers them.

Sources. Quotes are from the Python documentation pages Built-in functions (the round entry) and decimal — Decimal fixed-point and floating-point arithmetic. Outputs are pasted unedited from the scripts above.

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

When durations come in half-hour steps, as all four days here do, every odd half hour is a tie, and the tie rule, not the footage, decides the total a reader sees.

A Crontab Line That Works in Your Terminal Fails Under cron: What % Means in a Crontab

Super Funicular — Thu, 29 Oct 2026 12:55:57 +0000

I wanted a nightly crontab line that archives a folder of camera clips into a file named for the date: tar czf backup/clips-$(date +%F).tgz clips. Typed into a terminal, it made clips-2026-10-29.tgz. Pasted into a crontab, the same text would not make a file, and nothing about the line looks wrong.

The reason is one character. In a crontab, % is not plain text.

Disclosure: I make an Android camera app. Nothing below uses its code or describes how it stores or backs up files. I could not run the cron daemon in this environment (it needs root, and I do not have it here), so I did the next best thing: I took the rules the Debian crontab(5) manual page states, applied them with a short script, and ran the result through /bin/sh the way cron would. Read every cron result below as the manual's description of cron, not as a test of the daemon itself.

What the tests showed:

An unescaped % ends the command. Everything after it becomes standard input. A date format string cuts the line in half.
The shell then sees half a command and fails with a syntax error, so no archive is written.
\% fixes it, but inside double quotes the backslash may survive into the output.
Two day fields are ORed, not ANDed. A first-Sunday-of-the-month line runs on eleven days in November 2026, not one.
A day field that starts with * changes that rule on Debian's cron, which is not what POSIX says.
PATH=$HOME/bin:$PATH in a crontab is taken literally, so every command on the line after it goes missing.

Setup

#!/bin/bash
# Scratch folder with two clips and a backup target.
set -eu
D=/tmp/cron_demo
rm -rf "$D"; mkdir -p "$D/clips" "$D/backup"
head -c 4096 /dev/urandom > "$D/clips/clip_0001.mp4"
head -c 4096 /dev/urandom > "$D/clips/clip_0002.mp4"
uname -sr
readlink -f /bin/sh
bash --version | head -1
python3 --version

Linux 6.8.0-138-generic
/usr/bin/dash
GNU bash, version 5.1.16(1)-release (aarch64-unknown-linux-gnu)
Python 3.10.12

/bin/sh here is dash. The manual says cron runs commands with /usr/bin/sh unless the crontab sets SHELL, and on Debian and Ubuntu that is normally dash too.

The emulator

This is the whole of the cron behaviour I am relying on. It follows the manual's sentence: "Percent-signs (%) in the command, unless escaped with backslash (), will be changed into newline characters, and all data after the first % will be sent to the command as standard input."

#!/usr/bin/python3
# Applies the crontab(5) rule for the command field, then runs it:
#   text up to the first unescaped % goes to the shell,
#   every later unescaped % becomes a newline,
#   everything after the first % is sent to the command as standard input.
# A backslash before % is kept here; the shell removes it (see below).
import subprocess, sys

def split(field):
    cmd, stdin, cur, i, seen = "", "", [], 0, False
    while i < len(field):
        c = field[i]
        if c == "\\" and field[i+1:i+2] == "%":
            cur.append("\\%"); i += 2; continue
        if c == "%":
            if not seen:
                cmd, cur, seen = "".join(cur), [], True
            else:
                cur.append("\n")
        else:
            cur.append(c)
        i += 1
    if seen:
        stdin = "".join(cur)
    else:
        cmd = "".join(cur)
    return cmd, stdin

field = sys.argv[1]
cmd, stdin = split(field)
print("shell gets : %s" % cmd)
print("stdin gets : %r" % stdin)
r = subprocess.run(["/bin/sh", "-c", cmd], input=stdin, text=True,
                   capture_output=True, cwd="/tmp/cron_demo")
print("exit status: %d" % r.returncode)
for line in (r.stdout + r.stderr).splitlines():
    print("output     : %s" % line)

Test one: the date in the file name

#!/bin/bash
cd /tmp/cron_demo
LINE='tar czf backup/clips-$(date +%F).tgz clips'
echo "--- typed in a terminal"
bash -c "$LINE"; echo "exit status: $?"; ls backup
rm -f backup/*
echo "--- the same text as a crontab command field"
python3 /tmp/cron_demo_code/cronsplit.py "$LINE"
ls backup | wc -l

Output:

--- typed in a terminal
exit status: 0
clips-2026-10-29.tgz
--- the same text as a crontab command field
shell gets : tar czf backup/clips-$(date +
stdin gets : 'F).tgz clips'
exit status: 2
output     : /bin/sh: 1: Syntax error: end of file unexpected (expecting ")")
0

In the terminal the line worked. As a crontab command, the shell received tar czf backup/clips-$(date + and nothing else. The rest, F).tgz clips, went to standard input, which tar ignores here. Dash reported a syntax error and exited 2, and the backup folder stayed empty.

On a real system the error text would not reach your terminal either. The manual says "Command output is mailed to the crontab owner". If the machine has no working mail setup, I do not know where that message ends up, and I did not test it. The practical result is the same: a backup job that has not produced a single file, and nothing on screen saying so.

Test two: escaping it

#!/bin/bash
cd /tmp/cron_demo
rm -f backup/*
LINE='tar czf backup/clips-$(date +\%F).tgz clips'
python3 /tmp/cron_demo_code/cronsplit.py "$LINE"
ls backup | sed '/^output/s/[0-9]/N/g'
echo "--- the same escape inside double quotes"
python3 /tmp/cron_demo_code/cronsplit.py 'date "+\%F"' | sed '/^output/s/[0-9]/N/g'

Output:

shell gets : tar czf backup/clips-$(date +\%F).tgz clips
stdin gets : ''
exit status: 0
clips-2026-10-29.tgz
--- the same escape inside double quotes
shell gets : date "+\%F"
stdin gets : ''
exit status: 0
output     : \NNNN-NN-NN

With \% outside quotes the archive was written. The shell's own rule removes a backslash in front of an ordinary character, so +\%F reaches date as +%F whether or not cron strips the backslash first.

Inside double quotes it is different. A backslash before % is not special there, so the shell keeps it, and date printed a literal backslash in front of the date. The manual says to escape % with a backslash but does not say whether cron removes that backslash before the shell sees it. My emulator keeps it, which is the worse case. I did not test which one Debian's cron actually does, so I keep the escaped % outside quotes, where both cases give the same answer.

Why `%` works this way

It is a feature, not an accident. The manual's own example file uses it to write a mail body on one line: mail -s "It's 10pm" joe%Joe,%%Where are your kids?%. The same mechanism, smaller:

#!/bin/bash
# % used on purpose, as in the manual's mail example: lines on standard input.
python3 /tmp/cron_demo_code/cronsplit.py 'cat -n%first line%second line%'

shell gets : cat -n
stdin gets : 'first line\nsecond line\n'
exit status: 0
output     :      1 first line
output     :      2 second line

That is useful for a one-line mail or a short input, and it is the reason a date format in a crontab needs care.

Test three: the two day fields

A crontab has two day fields, day of month and day of week. A common first try at 03:00 on the first Sunday of the month is 0 3 1-7 * sun. The manual: "If both fields are restricted (i.e., aren't *), the command will be run when either field matches the current time."

There is a second rule hiding in the same page. Debian's cron "only checks if the first character is a ", so a field like `/2 counts as unrestricted, and then both fields have to match. POSIX would treat */2` as restricted.

This script lists the November 2026 days each line would match, under Debian's rule and under the POSIX one:

#!/usr/bin/python3
# Which days in November 2026 match a crontab's two day fields?
# Rule from crontab(5): if both day fields are restricted, run when EITHER
# matches. Debian's cron decides "restricted" by the field's first character
# only: a field starting with * counts as unrestricted, so the two are ANDed.
import calendar, datetime

DOW = {"sun":0,"mon":1,"tue":2,"wed":3,"thu":4,"fri":5,"sat":6}

def expand(field, lo, hi, names=None):
    out = set()
    for part in field.split(","):
        step = 1
        if "/" in part:
            part, s = part.split("/"); step = int(s)
        if part == "*":
            a, b = lo, hi
        elif "-" in part:
            a, b = part.split("-")
            a = int(names.get(a, a)) if names else int(a)
            b = int(names.get(b, b)) if names else int(b)
        else:
            a = b = int(names.get(part, part)) if names else int(part)
        out |= set(range(a, b + 1, step))
    return {0 if v == 7 else v for v in out} if names else out

def days(dom, dow, rule):
    D = expand(dom, 1, 31); W = expand(dow, 0, 7, DOW)
    hit = []
    for d in range(1, calendar.monthrange(2026, 11)[1] + 1):
        wd = (datetime.date(2026, 11, d).weekday() + 1) % 7   # Sunday = 0
        a, b = d in D, wd in W
        if rule == "debian":
            star_dom, star_dow = dom[0] == "*", dow[0] == "*"
        else:  # POSIX: unrestricted only if the field IS *
            star_dom, star_dow = dom == "*", dow == "*"
        ok = (a and b) if (star_dom or star_dow) else (a or b)
        if ok: hit.append(d)
    return hit

for dom, dow in [("1-7", "sun"), ("1-7", "*"), ("*/2", "sun")]:
    for rule in ("debian", "posix"):
        h = days(dom, dow, rule)
        print("%-4s %-3s %-6s -> %2d runs: %s" % (dom, dow, rule, len(h),
              " ".join(str(x) for x in h)))

Output:

1-7  sun debian -> 11 runs: 1 2 3 4 5 6 7 8 15 22 29
1-7  sun posix  -> 11 runs: 1 2 3 4 5 6 7 8 15 22 29
1-7  *   debian ->  7 runs: 1 2 3 4 5 6 7
1-7  *   posix  ->  7 runs: 1 2 3 4 5 6 7
*/2  sun debian ->  3 runs: 1 15 29
*/2  sun posix  -> 17 runs: 1 3 5 7 8 9 11 13 15 17 19 21 22 23 25 27 29

The first-Sunday line matches eleven days: every day from the 1st to the 7th, plus every Sunday in the month. Only one of those is the day I meant. The */2 sun line shows the first-character rule: three runs under Debian's reading, seventeen under the POSIX one. The manual describes that same line the same way: it "runs every Sunday that's an uneven date while the POSIX standard would have it run every Sunday and on every uneven date." The same line can mean a different schedule on a different cron.

The fix the manual suggests

Use one day field and put the other test in the command. The manual's own example does this for the second Saturday, and its test uses date +\%u, escaped, for the reason in test one.

#!/bin/bash
# The fix the manual suggests: one day field, plus a test inside the command.
# Here the test runs for each of November 1-7, 2026 instead of waiting for cron.
cd /tmp/cron_demo
for d in 01 02 03 04 05 06 07; do
  LINE="test \$(date -d 2026-11-$d +\%u) -eq 7 && echo 2026-11-$d would run"
  python3 /tmp/cron_demo_code/cronsplit.py "$LINE" | grep -E '^output'
done

Output:

output     : 2026-11-01 would run

Of the seven days the line would wake up in that week, the test let exactly one through.

Test four: a PATH line

Crontabs accept NAME=value lines, and it is natural to write PATH=$HOME/bin:$PATH. The manual says the value "is not parsed for environmental substitutions or replacement of variables or tilde(~) expansion", and gives that exact line as one that "will not work as you might expect".

#!/bin/bash
# crontab(5): values are not expanded, so PATH=$HOME/bin:$PATH is taken literally.
cd /tmp/cron_demo
env -i 'PATH=$HOME/bin:$PATH' /bin/sh -c 'echo "PATH is: $PATH"; tar --version'
echo "exit status: $?"
env -i 'PATH=/usr/local/bin:/usr/bin:/bin' /bin/sh -c 'tar --version' | head -1
echo "exit status: $?"

Output:

PATH is: $HOME/bin:$PATH
/bin/sh: 1: tar: not found
exit status: 127
tar (GNU tar) 1.34
exit status: 0

With the literal value, PATH held the text $HOME/bin:$PATH, no real directory, and tar was not found (exit 127). Writing the directories out in full fixed it. The manual also offers an eval workaround (P=PATH=/a/b/c:$PATH, then eval $P && some commands in the command field), which I did not test.

What to do instead

Escape every % in a crontab command as \%, and keep it outside double quotes.
Better, move anything with a date format into a script and have the crontab call the script. The script is ordinary shell, and % means nothing special there.
For a rule like the first Sunday of the month, restrict one day field and test the other inside the command.
Start a day field with * only when you mean any day for that field.
Write PATH= in full, with real directories.
After installing a new line, check the next morning that the file it should write exists. A job that fails at the shell stage leaves no file and no error on your screen.

Things I did not test

The cron daemon itself. Every cron result here is the manual's rule applied by a script. A different cron build could behave differently.
cronie, BusyBox crond, systemd timers. Their manuals may differ, and BusyBox crond was not checked at all.
Whether cron strips the backslash in \%. I worked around it rather than answering it.
Mail delivery of the error. Not tested.

Sources. Quotes are from the Debian crontab(5) manual page (cron 3.0pl1-212). Results come from the scripts above, each run once, with output pasted unedited.

If you want an old phone recording clips in the background so there is a folder worth backing up every night, the app I make is Background Camera RemoteStream on Google Play. Nothing above depends on it.

The line was fine as shell. It just was not shell yet.

Sending Phone Security Camera Footage on WhatsApp: Why the Clip Looks Blurry, the 100 MB / 720p Limit, and When to Send It as a Document

Super Funicular — Thu, 29 Oct 2026 07:52:55 +0000

Something happened in front of your shop camera. Maybe a customer walked out without paying, maybe a scooter was knocked over, maybe a delivery went missing. The recording is safe on the old phone. Now your brother, your landlord or the police station wants to see it, and the quickest way to send anything is WhatsApp.

You send the clip. It arrives looking soft and smeared, and the face or the number plate you needed is a blur.

Nothing is wrong with your camera phone. This guide explains what WhatsApp does to video, using only what WhatsApp's own Help Center says, and gives you a simple way to send the clip so the other person gets the file you actually recorded.

Why does my security camera clip look blurry on WhatsApp?

Because a normal video message is not the original file. WhatsApp's Android help page for sending media says it plainly: "The quality of media uploaded to WhatsApp might be lower than the original version because media files are usually compressed when shared."

The same page gives the default limits for a video message:

With a faster internet connection: 100 MB and 720p resolution.
With a slower internet connection: 64 MB and 480p resolution.

So on a weak mobile data signal, a clip recorded at 1080p can be sent at 480p. That matters more than it sounds.

What 480p does to a face or a number plate

Resolution is just a count of pixels. Here is the arithmetic for the three sizes involved (width × height, standard 16:9 frames):

Resolution	Pixels per frame	Share of a 1080p frame	A 100-pixel-wide object becomes
1080p (1920 × 1080)	2,073,600	100%	100 px
720p (1280 × 720)	921,600	44.4%	66.7 px
480p (854 × 480)	409,920	19.8%	44.5 px

A 480p frame has about one fifth of the pixels of a 1080p frame. A number plate that was 100 pixels wide in your recording is about 44 pixels wide after scaling to 480p, before any compression is applied on top. Small details like a plate or a face across the shop are exactly what gets lost first.

This is the same reason we told you in our H.264 vs H.265 guide to keep footage in a format the other person can actually open. Sharing is part of the recording plan, not an afterthought.

How big is your clip? A quick estimate

WhatsApp's limit is in megabytes, so it helps to know how big your clip is. The rule is simple:

size in MB ≈ bitrate in Mbit/s × seconds ÷ 8

Bitrate depends on your phone and settings, so the numbers below are examples, not a measurement of any particular phone:

If the recording bitrate is	1 minute	5 minutes	10 minutes	Fits in 64 MB	Fits in 100 MB
4 Mbit/s	30 MB	150 MB	300 MB	128 s	200 s
8 Mbit/s	60 MB	300 MB	600 MB	64 s	100 s
12 Mbit/s	90 MB	450 MB	900 MB	43 s	67 s

To find your own number, open the clip in your phone's Files app, check its size and its length, and divide. At 8 Mbit/s, roughly one minute of video is already at the slow-connection limit.

The lesson: a full hour-long recording is never going to go as a normal video message. You need to either cut it down or send it a different way.

Option 1: Trim first, then send in HD

Most of the time, the person only needs the 20 or 30 seconds where the thing happened.

Find the moment. Write down the time shown in the recording, or the time on the clock in the shop.
Open the chat, tap the attach button and pick the clip from your gallery.
WhatsApp's editor lets you trim a video by dragging the slider at the top (from WhatsApp's "How to edit photos and videos" help page). Keep a few seconds before and after the event.
Before sending, tap the quality button and choose HD quality. WhatsApp's help page says HD photos and videos "are clearer than Standard quality photos and videos, but use more data and take longer to send."
If your signal is weak, wait until you are on Wi-Fi or a stronger signal. The help page links the 480p default to a slower connection.

WhatsApp's help pages do not promise that HD sends the full original resolution, so treat HD as "better", not "the original".

Do not add stickers, text, filters or drawings to a clip you may need as proof. The editor can do all of these, and every one changes the picture.

Option 2: Send it as a document (the original file)

WhatsApp has a second path that is meant for files, not video messages. On Android: tap the attach button, choose Document, and pick the video file. The Help Center says this route accepts "a document of up to 2 GB".

The compression note on the help page talks about media files. Documents have their own separate 2 GB limit. In practice, this is the route people use when the file itself has to arrive. You do not have to trust that, you can check it:

Before sending, note the exact file size in your Files app.
Ask the other person to save the document and check its size on their side.
If the two sizes match, they have your original file.

Things to know about the document route:

It costs real data. A 300 MB file uses about 300 MB of your data to send, and about the same for the person downloading it. On a daily data pack, check your balance first. Wi-Fi is better.
It does not play as a video bubble. The other person sees a file and taps it to open it with their video player.
2 GB is the ceiling. At 8 Mbit/s, 2 GB is roughly half an hour of video. If your phone records long single files (and on an older SD card a single file can run close to 4 GB, see our FAT32 guide), you will need to cut out the part that matters before sending.

Option 3: Do not use WhatsApp for the main copy

If the clip may be needed later by the police, an insurer or a court, the safest copy is the one that never went through a messaging app at all. Copy the original file off the phone with an SD card or a USB cable, which our guide on getting recordings off an old-phone camera without a cloud account walks through step by step.

Then use WhatsApp for a short HD preview, so people can see what happened today, while the original stays safe.

We are not lawyers, and rules for evidence are different in every country. If an official asks for footage, ask them how they want to receive it. Many will want the original file on a pen drive or a disc, not a forwarded chat message.

Tips for the person receiving the clip

The other side of the chat matters too, especially in a family or shop group:

Auto-download can eat their data. WhatsApp's "How to configure auto-download" page says you can choose which media downloads automatically on mobile data, on Wi-Fi and when roaming, under Settings > Storage and data > Media auto-download. It also warns that roaming data "is often expensive."
Downloaded media goes to the gallery. The help page says downloaded media is saved to the phone's gallery by default, and each chat has a Media visibility option to change that. On a shared family phone, a shop clip in the gallery may be seen by everyone who uses that phone.
Forwarding does not re-upload. WhatsApp says that when you forward media or documents, "you don't have to upload them again." So forwarding a clip around a group does not cost the sender extra data each time. It still spreads the clip further than you may want, so think before forwarding footage of real people.

The 5-minute test to do before you ever need it

Do this on a quiet day, not on the day something goes wrong:

Record a 1-minute test clip on the camera phone. Hold up a page with a phone number written on it in normal-sized handwriting, at the distance of your shop door.
Send it to a family member three ways: a normal video message (Standard), a video message in HD, and as a Document.
Ask them to pause each one on the page and read the number.
Ask them to check the size of the Document copy. It should match your original.

Now you know which route gives a readable number, and how much data each costs on your connection.

Where Background Camera RemoteStream fits

That means the full-quality recording is already sitting on your own phone when you need it. What happens to it after that, including how you share it, is your choice. Pick the route that keeps the details you need.

More guides for shop and home setups on old phones: superfunicular.com. If you are worried about the camera phone itself being taken, read what happens if someone steals the phone that is your shop camera.

What this guide does not tell you

Exactly what WhatsApp does to an over-size clip on your phone. The help page gives default limits (100 MB / 720p, 64 MB / 480p) and a separate help topic is titled "I get a message that my video is too long and it won't send." It does not publish the full rules, and they may change. Run the test above.
Whether HD sends the original resolution. WhatsApp says HD is clearer than Standard. It does not say HD equals the original.
Anything about your phone's bitrate. The size table uses example bitrates. Measure your own clip.
Legal advice. Ask the person or office requesting the footage how they want it delivered.

Sources: WhatsApp Help Center, "How to send media, contacts, or location" (Android), "How to edit photos and videos" (Android) and "How to configure auto-download" (Android), all read on 29 October 2026. Pixel and file-size figures are arithmetic, computed with a short script for this article.

Is Camera 1 Still Recording? A 15-Minute Check That Doesn't Lie When the Clip Folder Is Full

Super Funicular — Wed, 28 Oct 2026 08:01:15 +0000

A camera phone that stops recording does not tell you. The folder just stops growing. So the job is a small check that runs every 15 minutes and asks one question: has camera 1 written a clip lately? If not, send an alert.

This is a companion to set -o pipefail Failed My Clip Script on Some Nights and Not Others, which showed why a pipeline ending in head or grep -q exits 141 under pipefail once there is more output than a pipe holds. A reader, c-wind, added the case that post skipped: what to do when the early exit is not something find can express, and how a real error can hide behind the 141. They also asked a direct question. This post builds the 15-minute check and answers it.

Disclosure: I make an Android camera app. Nothing below uses its code or describes how it names or stores files. The folder is fake, the log is fake, and every result comes from the scripts shown, run on this machine:

GNU bash, version 5.1.16(1)-release (aarch64-unknown-linux-gnu)
find (GNU findutils) 4.8.0
CPUs: 2

The fake folder

Same generator as the first post: empty files, one minute apart, all from camera 1, all dated October 2025, so every clip is stale.

#!/bin/bash
# mk.sh N : make N empty clip files, one minute apart, oldest first.
n=$1
rm -rf clips && mkdir clips
for i in $(seq 1 "$n"); do
  f=$(printf 'clips/cam1_%05d.mp4' "$i")
  : > "$f"
  touch -d "@$((1761000000 + i * 60))" "$f"
done

The answer to the question first

The question was: on the 3000-clip grep -q runs, was PIPESTATUS 141 0, the same as the sort | head trace? Here it is, 100 runs per folder size:

#!/bin/bash
set -o pipefail
for n in 10 3000; do
  ./mk.sh "$n"
  declare -A seen=()
  for k in $(seq 1 100); do
    find clips -name '*.mp4' | grep -q 'cam1_'
    s="${PIPESTATUS[*]}"
    seen["$s"]=$(( ${seen["$s"]:-0} + 1 ))
  done
  for s in "${!seen[@]}"; do echo "clips=$n  PIPESTATUS=$s  ${seen[$s]}/100"; done
  unset seen
done

clips=10  PIPESTATUS=0 0  100/100
clips=3000  PIPESTATUS=141 0  100/100

Yes. grep -q matched and exited 0; find, still listing, took SIGPIPE. On 10 clips find finished before grep left, so both are 0.

Version one: the newest clip, by `ls -t`

The obvious first draft asks for the newest clip and checks its age. Before any age check, the name lookup itself:

#!/bin/bash
set -euo pipefail
# Name of the newest camera 1 clip, by modification time.
newest=$(ls -t clips/cam1_*.mp4 | head -n 1)
echo "newest: $newest"

newest_ls clips=50 failed=0/100
newest_ls clips=3000 failed=95/100

On 3000 clips, a single run printed nothing and exited 141. It is the same failure as the first post with ls as the writer: 95 of 100 runs died before the check ever looked at a time. If the scheduler treats a non-zero exit as "alert", that is 95 false alarms; if it ignores non-zero exits, that is 95 checks that never happened.

Version two: let `find` ask the whole question

The question is not "what is the newest clip". It is "is there at least one camera 1 clip modified in the last 15 minutes". find can say that directly with -mmin -15, and stop at the first hit with -quit. No pipe, nothing left writing into a closed one:

#!/bin/bash
set -euo pipefail
dir="${1:-clips}"
# Any camera 1 clip modified in the last 15 minutes? find stops at the first one.
recent=$(find "$dir" -name 'cam1_*.mp4' -mmin -15 -print -quit)
if [ -n "$recent" ]; then echo "OK: $recent"; else echo "ALERT: no cam1 clip in 15 min"; fi

Three cases: the stale 3000-clip folder, the same folder after touching one clip so it is fresh, and a folder that does not exist.

--- stale folder (all clips from 2025) ---
ALERT: no cam1 clip in 15 min
exit 0
--- after touching newest now ---
OK: clips/cam1_03000.mp4
exit 0
--- missing dir ---
find: ‘no_such_dir’: No such file or directory
exit 1

Right answer on the stale folder, right answer on the fresh one, and a missing folder is an error (exit 1), not a quiet "OK" and not a quiet "ALERT". That last one matters: "the folder is gone" and "the camera stopped" need different fixes, and the exit status is the only thing that tells them apart.

For a clip folder, this is the whole check. Most of the time, the fix is to stop asking a pipeline a question the first command can answer itself.

When `find` can't express it

c-wind's point was that -quit only works when the test is a find predicate. Sometimes it isn't. Say the recorder writes a text log, and the real signal is a line like cam1 segment closed in the last 5000 lines. That is a content test, so it needs grep:

tail -n 5000 rec.log | grep -q ' cam1 segment closed'

The fake log is 20,000 lines, alternating camera 1 and camera 2, about 1.3 MB. The 5000 lines tail sends are more than a pipe holds, so grep -q leaves early and tail takes SIGPIPE.

Their approach: keep pipefail, and branch on each side's status yourself.

#!/bin/bash
set -uo pipefail
# Did camera 1 close a segment in the last 5000 log lines? Branch on each side's status.
tail -n 5000 rec.log | grep -q ' cam1 segment closed'
st=("${PIPESTATUS[@]}")
case "${st[0]} ${st[1]}" in
  "0 0"|"141 0") echo "MATCH   (tail=${st[0]} grep=${st[1]})" ;;
  "0 1")         echo "NOMATCH (tail=${st[0]} grep=${st[1]})" ;;
  *)             echo "ERROR   (tail=${st[0]} grep=${st[1]})"; exit 2 ;;
esac

set -e is off here on purpose: the script reads the statuses instead of dying on them. PIPESTATUS has to be copied on the very next line, because the next command overwrites it.

100 runs on the log, then a log with every cam1 changed to cam3, then no log at all:

MATCH   (tail=141 grep=0)  100/100
--- log with no cam1 ---
NOMATCH (tail=0 grep=1)
--- log missing ---
tail: cannot open 'rec.log' for reading: No such file or directory
ERROR   (tail=1 grep=1)
exit 2

All three come out right. A match is 141 0 every time on this log, so a case that only accepted 0 0 would have called every one of those 100 runs an error.

The error that 141 hides

The same thread had the catch: "a real find error (EACCES, directory gone) after grep has already left still gets hidden, because pipefail reports the 141 and drops the 1." Here is that case. The 3000-clip folder gets a subfolder that find cannot read:

mkdir clips/locked && touch clips/locked/cam2_x.mp4 && chmod 000 clips/locked

Then the same question two ways. grep -q leaves at the first match; grep -c counts, so it reads to the end:

#!/bin/bash
set -uo pipefail
find clips -name '*.mp4' | grep -q 'cam1_'
echo "PIPESTATUS=${PIPESTATUS[*]}"

#!/bin/bash
set -uo pipefail
# grep -c reads to the end, so find finishes and its own status survives.
n=$(find clips -name '*.mp4' | grep -c 'cam1_')
st=$?
echo "count=$n  pipeline status=$st"

With the subfolder locked, then unlocked:

PIPESTATUS=141 0
find: ‘clips/locked’: Permission denied
count=3000  pipeline status=1
--- unlocked ---
PIPESTATUS=141 0
count=3000  pipeline status=0

With grep -q, the locked and unlocked runs are identical: 141 0, nothing on stderr. In this run find was killed before it reported the folder at all, so there was no error message to lose; the status could not have shown it either. With grep -c, find gets to the locked folder, prints Permission denied, exits 1, and pipefail carries that 1 out.

So the PIPESTATUS branch is correct about what grep saw, and blind to anything the writer would have hit after the reader left. Whether that matters depends on the check:

"Is there at least one?" A match is a match. A permission error further down does not change the answer, so grep -q plus the branch is fine.
"Did we look everywhere?" Then a reader that leaves early can never give you that, because the writer never finishes. Use a reader that drains (grep -c, grep ... > /dev/null, awk with an END), and accept that it reads the whole stream.

For a camera heartbeat, "at least one fresh clip" is the question, so early exit is fine. For a nightly job that counts clips before deleting old ones, it is "did we look everywhere", and a hidden Permission denied means it counted less than the folder holds.

The check I'd schedule

#!/bin/bash
set -euo pipefail
dir="${1:-clips}"
recent=$(find "$dir" -name 'cam1_*.mp4' -mmin -15 -print -quit)
if [ -n "$recent" ]; then
  exit 0
else
  echo "camera 1: no new clip in 15 minutes" >&2
  exit 3
fi

Exit 0 means fresh clip. Exit 3 means the camera stopped. Exit 1 (from find under set -e) means the folder itself is broken. Three different problems, three different numbers, and no pipe for a 141 to come out of.

Checklist

Ask find the whole question when you can: -mmin, -newer, -name, then -print -quit.
When you need a content test, copy PIPESTATUS on the next line and treat 141 0 as a match, not an error.
Know which question you're asking. "At least one" tolerates a reader that leaves early. "Did we look everywhere" does not.
Give "camera stopped" and "folder broken" different exit codes, so the alert says which one it is.

Things I did not test

Clock jumps. -mmin uses the system clock. A phone or server whose clock jumps will make clips look older or newer than they are.
Clips still being written. A clip that is open and growing has a fresh mtime; one written to a temp name and renamed at the end may not match cam1_*.mp4 until it closes. Check how your recorder writes before picking the window.
Network shares. Over SMB or NFS, mtime and caching may differ. I only tested a local folder.
Other shells and find builds. bash 5.1 and GNU findutils 4.8 only. -printf, -mmin and -quit are GNU; BSD find differs.
Order. find lists in directory order, not sorted. Here the locked subfolder came 655th of 3002 entries, about 13 KB of names in, and grep -q had already left. In another folder it could come first, and the error would show.

Sources. The quote is c-wind's comment on the first post. PIPESTATUS and pipefail are documented in the Bash manual; -mmin and -quit in the GNU find manual. Related: find -mtime +7 keeps eight days and rm *.mp4 said Argument list too long. Outputs are pasted unedited.

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

A heartbeat check should fail for one reason at a time. Let find answer the question, and keep the pipe out of it.

Why Does My Phone Security Camera's Audio Hiss in a Quiet Room? Android Audio Sources, Automatic Gain Control, and an Offline Test

Super Funicular — Wed, 28 Oct 2026 07:14:04 +0000

You set an old phone up as an offline security camera, play back a night recording, and the picture is fine. The sound is not. In the quiet stretches there's a hiss that seems to swell, as if the room is breathing. When a door finally slams, it doesn't sound as loud as it should.

Usually nothing is broken. You're hearing the audio processing Android chose for the recording, and that choice starts from one value an app passes before recording begins: the audio source.

This post covers what Android's documentation says about audio sources, what automatic gain control (AGC) does to a quiet room, a small reproducible simulation with real numbers, and a test you can run on your own recordings without an internet connection.

Why does my phone security camera's audio hiss in a quiet room?

Most likely, automatic gain control is raising the level when nothing is happening. AGC is built for speech. It turns quiet input up and loud input down so a voice lands at a steady level. Point it at an empty room at night and the only thing it can turn up is the room's own noise floor: the fridge, the fan, the microphone's own self-noise. So the hiss gets louder during the quiet minutes. When a real sound arrives, AGC pulls the gain back down, and that sound ends up less dominant than it was in the room.

Whether AGC is applied, and how strongly, depends on the audio source the app records from and on the phone maker's own audio tuning. The next sections cover both.

An audio source is a use case, not a microphone

Android apps don't pick a physical microphone. They pick an AudioSource, which describes what the recording is for. Android's own audio implementation guide says this directly:

"In Android app development, a use case is referred to as an AudioSource instance; and app developers request to use the AudioSource abstraction instead of the actual audio hardware device. The Android Audio Policy Manager maps an AudioSource instance to a given capture path configuration (including device, gain, and pre processing) according to product-specific rules."

The important phrase is product-specific rules. The same source can sound different on a Samsung, a Xiaomi and a Pixel, because each maker decides which microphone, which gain and which preprocessing go with it. The default effects for each source live in a vendor file, /vendor/etc/audio_effects.xml.

The guide's own example config turns on AGC for the camcorder source:

<preprocess>
    <stream type="voice_communication">
        <apply effect="aec"/>
        <apply effect="ns"/>
    </stream>
    <stream type="camcorder">
        <apply effect="agc"/>
    </stream>
</preprocess>

It also lists example tunings: a noise suppressor "tuned for wind noise suppressor for CAMCORDER", a stationary-noise suppressor for VOICE_COMMUNICATION, and AGC "tuned for far-talk for CAMCORDER".

So it would be reasonable, and fully documented, for a phone to apply far-talk AGC and wind-noise suppression to anything recorded with the camcorder source. That's a sensible choice for someone filming a birthday party. For a camera watching an empty shop at 3 a.m., it's the choice that produces the breathing hiss.

What the documentation actually guarantees per source

Here are the sources a security-camera app would realistically choose between, and what is written down about each:

Source	What the docs say	What a camera owner should expect
`MIC`	General microphone input	Whatever the maker tuned as the default path; not specified
`CAMCORDER`	"Microphone audio source tuned for video recording, with the same orientation as the camera if available"	AGC and wind suppression are the documented example tuning; actual effects are product-specific
`VOICE_RECOGNITION`	Tuned for voice recognition; the CDD requires noise reduction and automatic gain control to be disabled by default	The only source with a written promise of no default AGC or noise reduction
`UNPROCESSED`	"Microphone audio source tuned for unprocessed (raw) sound if available, behaves like DEFAULT otherwise" (added in Android 7.0)	Raw, if the phone supports it, and you have to check
`VOICE_COMMUNICATION`	Tuned for calls; Android 10+ implementations should provide echo cancellation	Built for a two-way call, not for a room

Two details matter here.

VOICE_RECOGNITION is the one written guarantee. Android's compatibility rules (the CDD) say devices must, by default, disable any noise reduction and any automatic gain control on this source. The AOSP guide adds a warning: turning noise suppression on by default for this source "causes the device to fail the compatibility requirement." The same section also sets tuning targets for it, including a flat frequency response (±3 dB) from 100 Hz to 4 kHz and "Effects/preprocessing disabled by default".

UNPROCESSED is optional. A phone that doesn't support it quietly behaves like DEFAULT. The CDD has devices report support through AudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED), which returns null when there's no support. On older and budget phones, check before relying on it.

A simulation: what AGC does to an empty room

I wanted real numbers, so I built a 60-second test file with ffmpeg: a pink-noise room floor and a single 1.5-second loud event at the 20-second mark. Then I ran it through ffmpeg's dynaudnorm filter as a stand-in for AGC.

To be clear about the limits: this isn't any phone's AGC, and it doesn't show what your phone does. dynaudnorm is a dynamic normaliser that, like AGC, raises quiet passages and holds back loud ones. It shows the shape of the effect. The test at the end of this post measures your own phone.

# Room: pink noise floor + one loud 1.5 s event at t=20 s
ffmpeg -f lavfi -i "anoisesrc=color=pink:amplitude=0.003:duration=60:sample_rate=48000:seed=7" \
       -f lavfi -i "anoisesrc=color=white:amplitude=0.35:duration=1.5:sample_rate=48000:seed=3" \
       -filter_complex "[1]adelay=20000|20000,apad=whole_len=2880000[e1];[0][e1]amix=inputs=2:normalize=0[m]" \
       -map "[m]" -ac 1 room.wav

# AGC stand-in
ffmpeg -i room.wav -af dynaudnorm=f=500:g=31:m=30 agc.wav

Levels measured with astats (dBFS, RMS):

Stretch	Raw room	After AGC stand-in	Change
Quiet, 0–15 s	−64.8	−42.9	+21.9 dB
Quiet, 21.5–36.5 s (just after the event)	−64.7	−39.0	+25.7 dB
Quiet, 45–60 s	−64.6	−38.7	+25.9 dB
The event, 20–21.5 s	−13.9	−5.3	+8.6 dB

The quiet room went up by roughly 22 to 26 dB. The event went up by less than 9 dB. In the raw file the event stood about 51 dB above the room. After processing it stood about 33 to 37 dB above it. The event didn't get quieter. Everything else got louder.

That gap is what a sound detector depends on. I ran ffmpeg's silencedetect at −50 dB with a 2-second minimum on both files:

Raw room: silent 0–20 s, silent 21.5–60 s. The event is isolated exactly.
AGC stand-in: silent only for the first 2.2 s and the last 2 s. Everything from 2.2 s to 58 s counts as one long stretch of "activity", and the event can't be told apart from the room.

If you've tried to find the noises in a long overnight recording, this is part of why a fixed threshold can let you down. I wrote up the threshold side of that problem in ffmpeg's silencedetect Found Nothing at -40 dB: Finding the Noises in a Long Recording. With gain control in the chain, the room's level moves too, so no single threshold fits the whole night.

For developers: check before you choose

If you build a recorder, the platform lets you inspect, and partly control, what's applied. These are the documented calls:

// 1. Does this phone support a truly raw source?
val am = context.getSystemService(AudioManager::class.java)
val rawSupported = am.getProperty(
    AudioManager.PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED
) != null

// 2. Which preprocessing effects does this phone expose at all?
val agcAvailable = AutomaticGainControl.isAvailable()
val nsAvailable  = NoiseSuppressor.isAvailable()

// 3. For an AudioRecord session, explicitly turn an exposed effect off
val agc = AutomaticGainControl.create(audioRecord.audioSessionId)
agc?.enabled = false
agc?.release() // when the session ends

A few cautions, all from how the docs are worded:

create() can return null. An effect that isn't exposed through audiofx can't be controlled through it. The CDD's control requirement is written for speech-tuned noise suppression ("MUST allow this audio effect to be controllable with the android.media.audiofx.NoiseSuppressor API"). It doesn't promise that every vendor processing step is reachable.
Your choice of source can differ from what the capture path actually does. The Audio Policy Manager maps your source to a path "according to product-specific rules." Measure on real hardware.
There's no universally right source. VOICE_RECOGNITION gives you the written no-AGC promise, but it's tuned around voice frequencies. UNPROCESSED gives you raw sound where it's supported. CAMCORDER matches the camera's orientation and may suit a moving, handheld recording better. For a fixed camera in a quiet room, the documented no-AGC option is the one to test first.

One more thing that silently breaks audio on unattended recorders: the microphone needs its own foreground service type. Declaring camera doesn't cover it. The details, including Android 17's change to how the failure shows up, are in Android's camera Foreground Service Type Does Not Include the Microphone.

The offline test: measure your own phone in ten minutes

You don't need the internet, an account or a cloud service for this. You need the camera phone, a laptop on the same Wi-Fi (or a USB cable), and ffmpeg.

Record ten quiet minutes. Put the phone where it will actually live. Start recording, leave the room, and make one known sound at about the five-minute mark, like a single clap or a door closing. Then stay out.
Copy the file off the phone over your local network or by cable.
Measure the quiet before and after the sound:

# Quiet stretch before the clap (minute 1 to 4)
ffmpeg -ss 60  -t 180 -i night.mp4 -vn -af astats=measure_perchannel=none:measure_overall=RMS_level -f null - 2>&1 | grep "RMS level"

# Quiet stretch well after the clap (minute 6 to 9)
ffmpeg -ss 360 -t 180 -i night.mp4 -vn -af astats=measure_perchannel=none:measure_overall=RMS_level -f null - 2>&1 | grep "RMS level"

Read the result. If both quiet stretches are within a dB or two of each other and clearly below the clap, your audio path is behaving like a plain recorder. If the quiet level drifts, or sits only a little below the clap, gain control is very likely working on the room.
Listen to the minute right after the clap. A dip followed by hiss that slowly swells back is the "breathing" sound AGC is known for.

Run it once in the day and once at night. A fan or fridge that switches on changes the floor, and that's useful to know too.

Setup tips that help no matter which source is used

Keep the microphone holes clear. Most phones have more than one. Check the bottom edge and near the top camera. Don't stand the phone on its bottom edge in a groove, and don't tape over a hole to stop wind.
Don't put the phone in a closed box. A box muffles the sound and traps heat. Heat is the bigger long-term risk for a 24/7 phone, as covered in The Hardest Part of Running a Phone as a 24/7 Camera Isn't the Camera — It's Heat and the Battery.
Move the phone away from steady noise. A fridge compressor, a ceiling fan or a router fan gives AGC something to amplify all night.
Point the bottom microphone toward the room, not toward the wall it's mounted on.
Check the law where you are. Many places treat recording sound more strictly than recording video. Some people turn audio off entirely for that reason.

Where Background Camera RemoteStream 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, with no cloud account. You can watch live from any browser on the same Wi-Fi through the phone's built-in web server, and you can stream to YouTube Live when you do want an off-site copy. It's a normal install from Google Play, with no subscription and no card.

I'm not going to claim a particular audio source for it here. Every point in this post depends on the phone the app runs on, so the honest answer is to run the ten-minute test above on your own device. That works the same way for any recording app.

More on the project at superfunicular.com.

Sources

AOSP — Configure preprocessing effects (AudioSource as use case, Audio Policy Manager "product-specific rules", audio_effects.xml, CAMCORDER far-talk AGC / wind-noise examples, VOICE_RECOGNITION tuning and the noise-suppression warning)
Android Developers — MediaRecorder.AudioSource (CAMCORDER, UNPROCESSED, VOICE_RECOGNITION definitions)
AOSP — Android 16 Compatibility Definition (§5.4 VOICE_RECOGNITION defaults; §5.11 unprocessed capture and PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED)
Android Developers — AutomaticGainControl, NoiseSuppressor
Simulation: ffmpeg 4.4.2 anoisesrc, dynaudnorm, astats, silencedetect; commands above, run 2026-10-28

Python Wrote NaN Into My JSON and Only Python Could Read It Back

Super Funicular — Wed, 28 Oct 2026 04:56:12 +0000

I had a small Python script writing one JSON line per camera clip, with a temperature reading next to each file name. Sometimes there was no reading, so the script stored float('nan') as a placeholder. Python read the file back without a complaint. A Node dashboard reading the same file threw on two of the three lines:

# write_log.py: one JSON line per clip, with a temperature reading that may be missing
import json

clips = [
    {"clip": "clip_0001.mp4", "temp_c": 31.5},
    {"clip": "clip_0002.mp4", "temp_c": float("nan")},  # sensor gave no reading
    {"clip": "clip_0003.mp4", "temp_c": float("inf")},  # "no limit" placeholder
]
with open("clips.jsonl", "w") as f:
    for c in clips:
        f.write(json.dumps(c) + "\n")

python3 write_log.py
cat clips.jsonl

{"clip": "clip_0001.mp4", "temp_c": 31.5}
{"clip": "clip_0002.mp4", "temp_c": NaN}
{"clip": "clip_0003.mp4", "temp_c": Infinity}

# read_py.py: the Python side reads its own file back
import json

with open("clips.jsonl") as f:
    for line in f:
        print(json.loads(line))

// read_node.js: a dashboard reads the same file
const fs = require("fs");

for (const line of fs.readFileSync("clips.jsonl", "utf8").trim().split("\n")) {
  try {
    console.log(JSON.parse(line));
  } catch (e) {
    console.log(e.name + ": " + e.message);
  }
}

python3 read_py.py
node read_node.js

{'clip': 'clip_0001.mp4', 'temp_c': 31.5}
{'clip': 'clip_0002.mp4', 'temp_c': nan}
{'clip': 'clip_0003.mp4', 'temp_c': inf}
{ clip: 'clip_0001.mp4', temp_c: 31.5 }
SyntaxError: Unexpected token 'N', ...""temp_c": NaN}" is not valid JSON
SyntaxError: Unexpected token 'I', ...""temp_c": Infinity}" is not valid JSON

The file is not valid JSON. Python wrote NaN and Infinity as bare words, and the JSON grammar has no such values. Python's own reader accepts them, so a test that writes with Python and reads with Python passes, and the problem shows up only when another program opens the file.

Disclosure: I make an Android camera app. Nothing below uses its code or describes how it stores anything. The scripts here are a desktop Python and Node writing and reading a hand-made file, and every output is pasted from the scripts shown. Versions:

Python 3.10.12
v22.23.4

What the Python docs say about this

This is documented, not a bug. The json module's page describes the allow_nan parameter of dump and dumps like this: "If True (the default), their JavaScript equivalents (NaN, Infinity, -Infinity) are used."

The same page is direct about the result. Under its section on infinite and NaN values, the example comment reads "Neither of these calls raises an exception, but the results are not valid JSON". The page also says the module "does not comply with the RFC in a strict fashion, implementing some extensions that are valid JavaScript but not valid JSON."

So the default favours a round trip inside Python over a file that any JSON parser can read. If Python is the sole reader, you may not notice. If the reader is a browser, a dashboard, JSON.parse in a serverless function, or a strict parser in another language, the line is rejected.

The docs call these "JavaScript equivalents", but JavaScript's own JSON writer does not produce them. Asked to write the same values, it writes null:

// js_writes.js: what the JavaScript side writes for the same values
console.log(JSON.stringify({ clip: "clip_0002.mp4", temp_c: NaN }));
console.log(JSON.stringify({ clip: "clip_0003.mp4", temp_c: Infinity }));

{"clip":"clip_0002.mp4","temp_c":null}
{"clip":"clip_0003.mp4","temp_c":null}

So the two sides do not agree. Python writes a token that JavaScript's parser rejects, and JavaScript, given the same value, writes something different that Python reads as None.

Make the writer fail instead

allow_nan=False turns the silent write into an error at the moment the bad value is produced:

# strict_write.py: same records, allow_nan=False
import json

for c in [{"clip": "clip_0001.mp4", "temp_c": 31.5},
          {"clip": "clip_0002.mp4", "temp_c": float("nan")}]:
    try:
        print(json.dumps(c, allow_nan=False))
    except ValueError as e:
        print("ValueError:", e)

{"clip": "clip_0001.mp4", "temp_c": 31.5}
ValueError: Out of range float values are not JSON compliant

The first record is written and the second raises ValueError. That is usually where you want the failure: in the script that produced the value, with the record still in memory, not later in a dashboard that cannot say where the value came from.

The check is not limited to top-level fields. A value nested inside a list inside an object is caught too:

# nested.py: allow_nan=False also covers values nested deep in the object
import json

summary = {"day": "2026-10-26", "stats": {"clips": 3, "temps": [31.5, float("nan")]}}
try:
    json.dumps(summary, allow_nan=False)
except ValueError as e:
    print("ValueError:", e)

ValueError: Out of range float values are not JSON compliant

Note what the message leaves out. It does not name the key or the position of the bad value. On a large object you will need to find it yourself, so it helps to clean values before they reach dumps rather than relying on the error alone.

Decide what a missing reading should be

Raising an error tells you there is a problem. It does not decide what the file should contain. For a reading that is missing, null is the value JSON has for the absence of a value, and it is also what JavaScript's writer produced above. One way to get there is to replace any float that is not finite before writing:

# clean_write.py: write a missing or out-of-range reading as null
import json, math

def clean(v):
    return None if isinstance(v, float) and not math.isfinite(v) else v

for c in [{"clip": "clip_0001.mp4", "temp_c": 31.5},
          {"clip": "clip_0002.mp4", "temp_c": float("nan")},
          {"clip": "clip_0003.mp4", "temp_c": float("inf")}]:
    row = {k: clean(v) for k, v in c.items()}
    print(json.dumps(row, allow_nan=False))

{"clip": "clip_0001.mp4", "temp_c": 31.5}
{"clip": "clip_0002.mp4", "temp_c": null}
{"clip": "clip_0003.mp4", "temp_c": null}

Every line is now valid JSON, and allow_nan=False stays on as a guard in case a value slips past the cleaning step.

Two things to decide deliberately rather than by default:

null loses the difference between NaN and infinity. In the original records, one value meant the sensor gave nothing and the other was a placeholder for no limit. After cleaning they are both null. If a reader needs to tell them apart, write a separate field, such as a status string, instead of overloading one number.
This version only cleans top-level values. The clean function above does not walk into nested lists or objects. That is why allow_nan=False stays on: if a nested value is not finite, the write fails loudly instead of producing a bad line.

Make the Python reader as strict as the dashboard

The other half of the problem is that Python's reader accepted the bad file, which is why the bug got past a Python-only test. The docs describe the parse_constant hook on loads as a function called with "'-Infinity', 'Infinity', or 'NaN'" that "can be used to raise an exception if invalid JSON numbers are encountered." Using it in a test makes Python reject what the Node reader rejected:

# strict_read.py: make the Python reader refuse what the dashboard would refuse
import json

def reject(name):
    raise ValueError("non-standard JSON constant: " + name)

with open("clips.jsonl") as f:
    for line in f:
        try:
            print(json.loads(line, parse_constant=reject))
        except ValueError as e:
            print("ValueError:", e)

{'clip': 'clip_0001.mp4', 'temp_c': 31.5}
ValueError: non-standard JSON constant: NaN
ValueError: non-standard JSON constant: Infinity

The output matches the Node run line for line: the first record loads, the other two fail. A test that reads files this way will catch a writer that has gone back to the default.

Checklist

Pass allow_nan=False to every json.dump and json.dumps call whose output another program will read.
Decide what a missing or out-of-range number should be in the file, and write that on purpose, usually null plus a status field if the reason matters.
Clean nested values too, or keep allow_nan=False on so that nested ones fail loudly.
In tests, read with parse_constant set to a function that raises, so Python is at least as strict as the other readers.
If a file has already been written with the default, it is not valid JSON. Fix it at the writer; changing every reader to accept NaN spreads the problem.

Things I did not test

Newer Python. I ran 3.10. The quotes come from the current online documentation, which covers newer releases. The behaviour matched what I saw, and the default has been the same for a long time, but I did not run a newer interpreter, and the exact error message text may differ.
Browsers. The JavaScript runs were in Node. Browser engines implement the same JSON.parse and JSON.stringify rules, but I did not run these lines in a browser, and their error messages are worded differently.
Other parsers and tools. Command-line tools and other languages' JSON libraries vary in whether they accept these tokens. I did not test any of them.
NumPy and pandas. Their own export functions have separate options for missing values. Nothing here covers them.

Sources. Quotes are from the Python documentation page json — JSON encoder and decoder. 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 script like this to log, the app I make is Background Camera RemoteStream on Google Play. Nothing above depends on it.

Python's json module will write a file that only Python can read unless you tell it not to, so tell it not to.

DEV Community: Super Funicular

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

Twelve clips, ten backed up

The usual comparison

What the manual says

The job that only wanted a number

When does comm stay quiet?

The version I would run

What I would check in an existing job

What I did not test

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

Why is my AlfredCamera camera disabled on the free plan?

What changed in AlfredCamera's 2026 pricing?

What is AlfredCamera's "Legacy Protection"?

How to rotate cameras on the free plan

What can I do with camera #3 without paying?

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

Which option should I choose?

Quick checklist

wc -l Says 2, grep Says 3: A Missing Final Newline Drops the Last Clip From a while read Loop

Four tools, two answers

What a line is, according to POSIX

The loop that skips the last clip

Two fixes on the reading side

The same byte breaks concatenation

A check for the end of a file

The fix on the writing side

What to change in a script like this

Things I did not test

Why Does My Phone Security Camera Only Show a Reflection at Night? Recording Through a Window, Double Glazing and Mosquito Mesh

Why does my phone security camera only show a reflection at night?

The one fix that matters most: lens flat against the glass

Turn off the light behind the camera

Double glazing: why you see a ghost of every streetlight

Mosquito mesh and window grilles

Offline security camera through a window: the night test

What the glass cannot fix

Quick checklist

clip_08.mp4 Stopped My Bash Loop and the Script Still Exited 0: A Leading Zero Means Octal in Bash Arithmetic

A leading zero means octal

The error abandons the loop, not the script

Not every comparison does arithmetic

The hour field does this every morning

Other tools read the same string as decimal

Forcing base ten

What to change in a script like this

Things I did not test

Why Do Faces Come Out Black on My Phone Security Camera? Backlight, Auto-Exposure, and Where to Point the Phone

Why do faces come out black on a phone security camera?

What the phone is actually doing

A simple model of the problem

Why "just make it brighter" is not enough

Fix 1: Put the light behind the camera, not behind the person

Fix 2: Make the bright area smaller

Fix 3: Add light on the person's side

Fix 4: Test at the worst hour

Does this work as an offline security camera without internet?

For developers: the Camera2 controls involved

Where Background Camera RemoteStream fits

What this guide does not tell you

Python's round() and JavaScript's Math.round() Disagree on Half the Days in a Footage Summary

What round() is documented to do

The case that is not about halves at all

Getting school rounding on purpose

The one-line half up that is not one

Why the default is half to even

Often the better fix: do not round floats at all

Checklist

Things I did not test

A Crontab Line That Works in Your Terminal Fails Under cron: What % Means in a Crontab

Setup

The emulator

Test one: the date in the file name

Test two: escaping it

Why % works this way

Test three: the two day fields

The fix the manual suggests

Test four: a PATH line

What to do instead

Things I did not test

Why `%` works this way

Version one: the newest clip, by `ls -t`

Version two: let `find` ask the whole question

When `find` can't express it