Skip to content

Extend hangs indefinitely at start of full-resolution denoising loop (1080p source, minimum 4s extend) #143

Description

@snesgps-a11y

Version: LTX Desktop 1.1.0 (Windows)

Hardware: RTX 5090, 32GB VRAM, Windows 11

Description:

Extending a 1080p (1920×1088) clip by the minimum allowed 4 seconds reliably hangs at the very start of the final full-resolution denoising loop. Reproduced twice in separate sessions with identical behavior both times.

The generation progresses normally through text encoding, embeddings, and transformer building, then logs the start of the denoising loop and immediately stops — no step progress, no heartbeat log lines, GPU remains pegged at 100% utilization with VRAM maxed out, but nothing advances even after 10+ minutes.

Steps to reproduce:

Generate or load a 1080p (1920×1088) source clip
Use Extend on that clip with the minimum 4-second duration
Generation proceeds through setup normally, then stalls after the denoising loop begins

Log excerpt (both occurrences stall at the identical point):

Attempt 1:

2026-08-04 13:52:24,263 - INFO - [Backend] INFO:ltx_pipelines.utils.blocks:Running denoising loop (8 steps, 1920x1088 217 frames @ 24.0 fps)
2026-08-04 13:52:24,269 - ERROR - [Backend] 0%| | 0/8 [00:00<?, ?it/s]
[no further output — process still shows 100% GPU utilization, VRAM maxed, no progress after 10+ minutes]

Attempt 2 (fresh app restart, same project, same source clip):

2026-08-04 14:10:59,160 - INFO - [Backend] INFO:ltx_pipelines.utils.blocks:Running denoising loop (8 steps, 1920x1088 217 frames @ 24.0 fps)
2026-08-04 14:10:59,181 - ERROR - [Backend] 0%| | 0/8 [00:00<?, ?it/s]
[identical stall]

Additional context:

A plain (non-extend) I2V generation at the same 1920×1088 resolution completed successfully in the same session just before the first extend attempt, finishing in 144.58s total. That run's high-res denoising stage only ran 3 steps; the extend's high-res stage runs the full 8 steps at 217 frames, and that's specifically where it stalls, before even the first step reports progress.

VRAM during the successful plain generation's high-res stage hit free=0.00/31.84GiB at one point — worth flagging in case the extend's larger frame count (217 vs. the plain gen's 121) is pushing an allocation over the edge and causing a silent deadlock rather than an OOM error.

Happy to provide full session logs, settings.json, or test further configurations if useful.

session_2026-08-04_11-07-07_unknown.log

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions