Files
com.darkwisp.app/app
Letdown2491 5a59341560 fix: lazily create inline video players to survive media-heavy notes
InlineVideoPlayer and InlineVideoPlayerWithFullscreen created a fully
prepared ExoPlayer per video URL the moment it entered composition,
with no cap or visibility gating. A note carrying many video URLs
(e.g. the circulating 155-video stress-test note) instantly spawned a
player per URL: 156 players / 487 player threads / 1800 process
threads measured on device, exhausting hardware codec instances
(~16-32 device-wide) and memory until input dispatch timed out (ANR)
in STACK media layout.

The player now only exists while its video is near the viewport:
created when >50% visible with autoplay on, or on tap (which starts
playback immediately); released with its position remembered once the
video scrolls fully off-screen. Until then the slot renders the
uploader-provided NIP-92 imeta "image" preview frame, falling back
to the existing thumbhash/blurhash painter. parseImetaTags now parses
the "image" entry, and MediaCarousel video tiles use it too instead
of a blank box when no thumbhash/blurhash is present.

Verified on device against the 155-video note: peak 7 ExoPlayer
threads (was 549), no ANR, playback/mute/fullscreen/PiP unaffected.
2026-06-12 11:32:22 -06:00
..