Checkpoint — PDF viewing and link speed — 20/10/2026, 17:38 Sydney

Another collaboration between Andrew.human and Claude.ai

All times are Sydney time unless marked. Live's clock runs 3 hours behind Sydney (server shows 12:30 when it is 15:30). Clone's clock matches Sydney.

---

1. What happened

• 07:45–about 08:30: PDFs would not open (Opera on the phone downloaded them, "No available adapters" in the PDF.js viewer), and everything felt slow.
• 08:30–14:33: you were away. Nothing was measured in this window.
• By 14:33 the link was already fast (the mirrors ran fast right after the NUC started). You noticed at about 15:25.
• Since then PDFs open in about 5 seconds, music plays without breaks, and the site is quick even with 3,413 guests online (almost certainly crawler bots).

2. What we established (checked, not guessed)

The link is the main variable.

• Ping from the PC at 15:48: 0 of 20 lost, about 200 ms (average 221 ms). Your usual bad signature is about 390–400 ms with about 10% lost.
• Speed test at 16:04: 22.2 Mbps down, 8.5 Mbps up, 12 ms to Sydney.
• The 5.3 MB PDF (attachment 7629) downloaded in 9.2 seconds by curl (578 KB/s).
• A 57-page PDF never opened before opened in about 5 seconds in a private window (empty cache). The 100+ page test was served from the browser's cache and does not count.
• pathping always stops at 192.0.0.1, your carrier's gateway, which does not answer probe packets. It cannot see past it, so use ping for this link.

The server was not the bottleneck.

• Live has been up 2 days 11 hours (no restart). Nothing under /etc/httpd, /etc/php.ini or /etc/php.d changed in the last 3 days.
• Live has 2 CPU cores. Load about 2.3 over 15 minutes, swap flat at about 300 MB, steal time 0.5%. PDFs were still fast under that load.
• Files changed in the last 8 hours: the ISE indexers rewrote their stores (about 14:50–15:31), attachment 7629 was written at 07:35, attachment 7635 (110 MB) at 15:54, and Sources/Load.php at 10:40 (unexplained, see section 4).

How PDFs are actually delivered.

• PDF.js reads through SMF's dlattach. It answered a request for bytes 0–99 with 200 and the whole 5,293,139 bytes, although it advertises Accept-Ranges: bytes. So the viewer always receives the whole file; speed is link plus server, with no chunking.
• It also sends Cache-Control: max-age=31536000, so browsers keep a PDF for a year after one full download.
• Sources/view_attach.php v1.8 (listatt's script) sent correct headers on a HEAD request, but a GET from Live returned an essentially empty body. Cause not confirmed. The leading theory is an output buffer left open by SSI.php.

Link tracking is now in place. Clone's /etc/crontab has a line every 5 minutes writing to /root/linkwatch.log (packet loss, round trip, home page time). Baseline: 0% loss, average 209–219 ms, page 3.3–3.6 s. It only records while the NUC is on, and it restarts itself at each boot.

3. Mistakes made today (so they are not repeated)

• Suggested a percent-encoded viewer link. Wrong: PDF.js 6.2.108 needs the raw link (your v2.24 finding).
• Claimed "No available adapters" has a single cause. Overreach.
• Told you to ping from Live. That is loopback (0.04 ms) and measures nothing.
• Wrote a crontab line with one unescaped %. Cron cut the command off. Fixed.

4. Open items (nothing below has been done)

1. Encoded links on attachments 7255, 7441 and 7530 (the rest are raw and fine). The v4.4.1 package has no urlencode in active code, but the legacy pdf_display_patch.xml does, and the installer only removes the newer block. If Live's Display.template.php still carries the old block, that is the cause. Not yet checked. Run on Live: grep -n "is_pdf0urlencode" /var/www/html/Themes/default/Display.template.php /var/www/html/Sources/Display.php
2. Load history for 08:00–14:33 (the unmeasured window). Run the redirected awk to /root/load_by_hour.txt on Live (last 48 hours, server clock, add 3 hours for Sydney) and send the file.
3. Test files from the 17:23–17:38 run: /root/pdftest_ping.txt on Clone (real link record), /root/pdftest_load.txt on Live. Ignore the stray pdftest_ping.txt on Live (loopback). Click times were about 17:25.
4. Sources/Load.php changed at 10:40 with no matching backup in Packages/backups. Not necessarily a problem. Worth knowing whether a package install did it.
5. view_attach.php empty-body GET. Unexplained. Left alone.
6. Install listatt_bbcode_v6.17.zip? Your call and your timing. Nothing depends on it today.

5. What was built (none of it deployed except where stated)

Item	State
view_attach.php v1.9 (fix plus range support)	Built, superseded, not deployed
view_attach_range.php v1.0 (side-by-side copy, original untouched)	Built; arrives with listatt 6.16 and 6.17
listatt_bbcode_v6.16.zip (Viewer dropdown)	Installed on Live (banner shows v6.16). The dropdown was confusing; replaced by 6.17
listatt_bbcode_v6.17.zip ([native] plus [native in chunks] links, no dropdown)	Built, not installed
listatt_bbcode_v6.16.1 (layout fix)	Never sent; not needed

Release-card gaps carried forward: zips made with plain zip -X (no data descriptors or extra fields), not your legacy zipper; no standalone manual for view_attach_range.php.

6. Next time it goes slow, capture these (5 minutes)

1. Speed test: down, up, latency (today: 22.2 / 8.5 / 12 ms).
2. ping -n 20 128.199.200.202 from the PC (today: 0% lost, about 200 ms).
3. The 5 MB Chapter 3 CLOSED2.pdf in a private window with a stopwatch (today: about 5–9 s).
4. grep -v " 0% packet loss" /root/linkwatch.log on Clone for the same time.
5. Live: uptime and top -bn1 | head -12.

7. Starting the next conversation

Attach this file, /root/load_by_hour.txt, both test files, and the grep output from item 1. Say which of items 1–6 you want to pursue first.