📝 Checkpoint_PDFviewer_Chunks_20261020_1910_2.mdTheme:

Checkpoint 2 — PDF viewer, chunked loading — 20/10/2026, 19:10 Sydney

Another collaboration between Andrew.human and Claude.ai

Follows Checkpoint_PDFviewer_LinkSpeed_20261020_1738.md (its open items 1–5 are still open). Live's clock runs 3 hours behind Sydney.

1. State of the site

Item	State
listatt	6.18 installed by Andrew (replaced 6.16)
`view_attach.php`	v1.8, untouched
`view_attach_range.php`	v1.0, installed with listatt, untouched
PDF.js (`Themes/default/pdfjs`)	6.2.108, untouched
6.17	built, never installed, do not install (its link did not work)

PDF rows now show: filename link (PDF.js on dlattach), [native], and [pdf in chunks] (PDF.js on view_attach_range.php).

The right log for these requests is /var/log/httpd/ssl_access_log, not access_log.
[native in chunks] (6.17) did not read in chunks. Chrome's built-in viewer asked for the whole file (200, full size) alongside small 206 range requests. The script supports ranges; the browser's built-in viewer ignores that.
Attachment 7638 (topic 7599, 3,086,416 bytes) is stored at /var/www/html/attachments2/7638_77a2743b… and is not linearized.
[pdf in chunks] (6.18) works as a range reader: the log shows a run of 206 responses of 65,536 bytes, plus one full 200 at the start (PDF.js's first request).
Those 206 responses arrived about one per second from Andrew's PC. The server takes 0.16 s per chunk (measured on Live), so the script is not the slow part. The pace comes from the link and from PDF.js asking for one chunk at a time.
In a test with the real PDF.js 6.2.108, the real sending code and a 110 MB non-linearized PDF, page 1 drew in 1.4 s while a full download would have taken about 70 s.

"Read 5 pages, then the next 5." PDF.js fetches by byte ranges, not page counts. The nearest switch is disableAutoFetch (stop fetching ahead).
disableAutoFetch could not be switched on for one link. Tried: a one-line script in a separate viewer_chunks.html set at load (overwritten by PDF.js's stored defaults), set just before open (no effect seen), and #disableautofetch=true in the link (ignored: PDF.js only reads address-fragment options when its debug mode is on). Nothing from these attempts was shipped.
On my test PDF, PDF.js read the whole file even with the option set, going from the end of the file back to the start. Cause not found. The untouched viewer does the same.
Not measured: how long page 1 takes on Andrew's phone, [pdf in chunks] against plain [pdf].
The "No available adapters" error on the phone (Opera Android) was not revisited today after the morning. Still open.

Named a link [native in chunks] and sent it before testing. It did not do what its label said.
Said chunked delivery would show pages early; that holds only for PDF.js and, for page 1, only if the viewer asks for ranges.
Guessed that each range request ran slowly because of SMF's start-up. Measured: 0.16 s. Wrong.
Made changes in the work folder without saying exactly what they were. Rule going forward: state each change before making it.

From Checkpoint 1: encoded links on 7255, 7441, 7530 — run grep -n "is_pdf0urlencode" /var/www/html/Themes/default/Display.template.php /var/www/html/Sources/Display.php on Live.
From Checkpoint 1: load history 08:00–14:33 (/root/load_by_hour.txt), test files from the 17:23–17:38 run, the 10:40 change to Sources/Load.php, and the empty-body GET on view_attach.php.
Stopwatch test on the phone: [pdf] against [pdf in chunks], same PDF, empty cache.
If a real "stop fetching ahead" is still wanted, it needs a PDF.js preference changed inside the PDF.js package (affects every link), or a different approach. Andrew's call.
Package release-card gaps: listatt_bbcode_v6.18.zip was built with plain zip -X (no data descriptors or extra fields, verified), not the legacy zipper; no standalone manual for view_attach_range.php.

Clone repair after the rollback (Python 3.15 install, cleanISE): "DM2S_NX Master Post Chapter 4". Attach this file only if the PDF work resumes.