Some videos that also have images are now really slow

[glenrobson]

This example:

https://archive.org/details/taboca_201002_03

now has 500 canvases 251 videos and the rest images. We should at least remove it from the test suite as it takes a long time to generate.

[glenrobson]

Looks like tests are failing on:

test_multitype_video

• 2025-highland-house-walkthrough-ma - Manifest
• Live version has 1 video. dev version has 1 video and 27 images since we fixed Support Mixed-Media Manifests for Items with both Images and Video #157

test_v3_h264_MPEG4_OGG_Theora

• taboca_201002_03 - Manifest
• 500 canvases and 251 videos

test_v3_single_video_manifest

• youtube-7w8F2Xi3vFw - Manifest
• 1 video and 1 image. Maybe the image server wasn't available at this time.

[glenrobson]

Options:

• Report to IA that the image server is a bit flaky
• Only add images to video manifest if it has less than x images
• Stop adding images to video manifests.

[avalyset]

The three options aren't addressing the same cost, and that's worth separating before picking one.

The slowness isn't driven by images existing in the manifest. It's driven by each image canvas triggering a synchronous dimension/info.json lookup against the image server at build time — taboca's 500 canvases mean 500 serial round-trips. That reframes the three:

• Report flaky image server to IA — worth doing, but orthogonal. It explains the intermittent youtube-7w8F2Xi3vFw case, where the image server is momentarily unavailable; it doesn't touch the systematic slowness on taboca/highland-house. Separate robustness item, not a fix for this.
• Stop adding images to video manifests — a straight revert of Support Mixed-Media Manifests for Items with both Images and Video #157, which was fixed specifically so multitype items expose their images. It throws away a real capability to dodge a performance problem. I'd avoid it unless multitype support is being abandoned.
• Cap at N images — pragmatic, but a fixed N is a proxy for the real cost, the number of dimension lookups, and it surprises users right at the boundary: N images is fine, N+1 silently drops them all.

A fourth angle, if the manifest builder allows it: keep the image canvases but stop forcing per-image dimension resolution at build time. Defer it, pull dimensions from a cheaper metadata source already in the item, or batch the lookups behind a cache. That keeps multitype manifests complete — preserving #157 — while removing the generation-time penalty that's the actual cause.

If deferring dimensions isn't practical, the cap is the reasonable fallback. I'd tie N to the actual generation budget — the test timeout, say — rather than an arbitrary number, and still file the flaky-server report separately.