coinosv3.git/tools, branch fdroid-v1.9

Ark: a double-tapped zap no longer spends one coin twice

2026-10-04T15:58:34Z

A reconcile pass that began before the first zap took its coin handed it back as spendable (the server still said so) while the zap was in flight; the second zap picked it and the server refused: 'vtxo … already spent'. Coins whose state changed during the pass are left alone. And a payment refused for an already-spent coin now reconciles and pays once more instead of failing with the raw error. Co-Authored-By: Claude Opus 5.5 Claude-Session: https://claude.ai/code/session_011bvzKaZosXGHkigcGcSzAR

Renewing asks first, and a renewal links to its round's transaction

2026-10-03T23:05:42Z

- The coins page's Renew button opens a confirmation instead of renewing at once: how many coins, their amount, the fee, and what is left to spend meanwhile — with a red notice when that is nothing (the button selects every coin by default, which is how a user locked their whole balance for an hour on 2026-10-03). It says the coins can't be spent until the round's transaction confirms and that a renewal can't be cancelled; the wallet renews for free near expiry anyway. The inline notice from 328f2db moves into it. - A renewal keeps its round's transaction id as soon as the round has run (before it confirms): the in-progress card on the coins page links to it, and the finished renewal's history row carries it, so its detail shows the id with View/Copy like any on-chain movement. Renewals finished before this change have no id recorded. tools/ark/renew-confirm-ui-test.js, tools/ark/renew-txid-test.js Co-Authored-By: Claude Fable 5.1 Claude-Session: https://claude.ai/code/session_01ULQZS9MQa6iAsXnrJUD9Du

A Lightning payment that can't be covered says why, not 'Payment failed'

2026-10-03T23:00:39Z

A user renewed all ten of their coins (55,611 sats) from the coins page, tried to pay a 55,300-sat invoice three minutes later, and was told only 'Payment failed'. Nothing had failed: the renewal's round ran at once, but its coins stay unspendable until the round's transaction confirms on-chain, and that block took 64 minutes. The quote found no spendable coin and gave up with the generic message; nothing reached the server. - The quote now tells apart (lnShortfall): money held by another payment (wait, as before — now by sum, not one coin covering it all), money a renewal holds ('Nothing was sent. N sats are being renewed…'), and a real shortfall ('needs X sats with its fee, Y available'). Coins leaving in an offboard or exit are never waited for. - The manager's 'insufficient ark balance' names a renewal too. - The coins page says before the tap that renewed coins can't be spent until the round confirms, and that renewing every coin leaves nothing to pay with meanwhile. tools/ark/ln-shortfall-test.js Co-Authored-By: Claude Fable 5.1 Claude-Session: https://claude.ai/code/session_01ULQZS9MQa6iAsXnrJUD9Du

Video frames from bytes, not from a CORS player; pager clips load plainly again

2026-10-03T22:52:38Z

Regression from 6488806: pager clips were loaded crossorigin so their frame could be kept, and on a phone the large clip's slide went black. Some hosts (Primal's R2 bucket) send CORS headers only to a request with an Origin and don't Vary on it, so a copy the browser cached from a plain player load answers a later CORS load without them, and it fails. The same thing made the size probe fail for any clip that had played in the feed. - Pager clips load plainly again; the still under a tap-to-play cover is restored on every return. - The probe (and its HEAD) go past the browser cache (no-store). - A clip's frame is now made from bytes: the opening of the file (index plus about 1 MB, no-store) decoded from a blob and kept as a JPEG — for tiles and as the pager's poster. No CORS player anywhere. Files whose index trails, or hosts whose bytes can't be read, keep the plain player still (shown, not kept). - Kept frames are 480 px wide (were 270) and capped at 600. - Probe failures are stored as failedAt, so earlier failures are asked again at once. - Test: an R2-style host, its clip cached by a plain load first, is still measured and its frame kept (failed before this change). Co-Authored-By: Claude Fable 5.1 Claude-Session: https://claude.ai/code/session_01ULQZS9MQa6iAsXnrJUD9Du

Pager: a large clip keeps its picture when you come back to it

2026-10-03T22:41:42Z

Leaving a slide lets go of its file, and coming back skipped the still because the cover was already there — black again. The still is now restored on every return. Pager clips also load CORS-readable (a plain retry for hosts without CORS), so their frame is kept the first time — the still under a cover and any clip that plays — and from then on the poster alone covers it. Co-Authored-By: Claude Opus 5.5 Claude-Session: https://claude.ai/code/session_01ULQZS9MQa6iAsXnrJUD9Du

Pager: a large clip shows its frame under the tap-to-play cover

2026-10-03T22:36:58Z

The slide's poster was fixed when the pager was built, and a clip over budget held no source, so a clip whose frame was kept a moment later (or never) was a black screen with a button. Now the kept frame is looked up as a slide comes near; without one, the clip's first frame is loaded under the cover (only the start of the file, when it leads with its index or is served in ranges) and kept for next time. A tap plays it from the start. Co-Authored-By: Claude Opus 5.5 Claude-Session: https://claude.ai/code/session_01ULQZS9MQa6iAsXnrJUD9Du

Video tiles: a frame even when the size check fails; retry it later

2026-10-03T22:32:41Z

Efrat's clip (blossom.primal.net → r2a.primal.net) showed a blank tile on a phone: the 64 KB probe failed there (slow connection), the failure was kept for good, and a tile with a failed probe never tried for a frame. - A failed probe is dated and asked again after an hour (it was kept forever; old 'failed: true' entries are retried). The probe waits 10 s. - A tile whose probe failed still tries for a first frame, giving up and letting go of the file after 8 s. - Primal's CDN lets scripts read the bytes but not Content-Range, so the size was unknown: a HEAD's Content-Length (readable by any page) fills it in. - No size in imeta but a bitrate and duration (Primal posts those): the size is estimated from them. 'dim 1080.0x1920.0' is understood. - A tile with nothing to show is dark, like a video, not a pale gap. Co-Authored-By: Claude Opus 5.5 Claude-Session: https://claude.ai/code/session_01ULQZS9MQa6iAsXnrJUD9Du

Media views keep their own cache and crawl for media directly

2026-10-03T22:05:52Z

Videos was slow because the grid read from the feed's page of posts: the feed cache holds 30, so after every reload the grid re-crawled the relays, ten posts a step, each post first waiting (up to 8 s) for its avatar, pictures and link cards — none of which the grid shows. - Each feed now keeps a media index (IndexedDB, src/media-cache.js): the posts carrying pictures and those carrying clips, 400 of each, and how far back it has looked. The grid and pager read from it; a reload paints them at once. - The crawl reads older posts straight into the index, 100 at a time, without the readiness wait and without touching the feed's own page; it resumes from where it stopped. The bottom of a feed is looked for again after a day. Curated feeds still page the usual way. - A tile's first frame is kept (a small JPEG in the Cache API, when the host lets its pixels be read) and painted as a picture from then on: in the grid, as the pager's poster and the feed's. - Probe results kept for 2000 clips (was 600). - Forgetting a wallet wipes the index and the frames. tools/feed-media-cache-test.js Co-Authored-By: Claude Opus 5.5 Claude-Session: https://claude.ai/code/session_01ULQZS9MQa6iAsXnrJUD9Du

Videos opens on a grid of thumbnails; the pager waits for a tap

2026-10-03T21:49:57Z

Choosing Videos no longer jumps into the full-screen pager: it shows the vertical clips as a grid, like Images, and a tile opens the pager on that clip. Every tile gets a first frame when that costs only the start of the file (the index leads, or the server serves ranges), whatever the clip's size; a clip over budget wears its cost as a badge. Only an index-last file from a server without ranges shows its cost instead. Co-Authored-By: Claude Opus 5.5 Claude-Session: https://claude.ai/code/session_01ULQZS9MQa6iAsXnrJUD9Du

Videos: know what a clip costs before fetching it; vertical clips only

2026-10-03T20:38:13Z

- What a clip costs is learned up front: the post's imeta (size, dim, image) when it says, else one 64 KB ranged request — the total from Content-Range, whether ranges are served, whether the MP4's index (moov) comes before its data, and the picture size from the track header. Up to three at a time; remembered across sessions. It also replaces the player-based shape probe the feed ran on every clip. - Clips over 25 MB (8 MB on 2G/3G, 3 MB with data saver), above 1080p, index-last files over 8 MB from servers without ranges, or clips that couldn't be measured wait for a tap: a cover saying what they cost ("50 MB", "4K"). Settings → Nostr → Videos: Autoplay large videos. - The pager loads only the clip on screen in full; the next gets its opening if within budget; everything else holds nothing. Sizes are asked three slides ahead. - Feed clips fetch nothing until they're about to play (preload none), with the post's still as a poster. - Video grid tiles show a first frame only for small clips that start quickly; others show their cost. - Videos lists only clips known to stand taller than wide; one of unknown shape is measured and joins when it qualifies; choosing Videos with none known yet opens the pager on the first that turns up. Co-Authored-By: Claude Opus 5.5 Claude-Session: https://claude.ai/code/session_01ULQZS9MQa6iAsXnrJUD9Du