Question 1

How to fix Jasna error "LTX worker could not start: Windows reports a different program path for the Jasna window"?

Accepted Answer

This error occurs when Windows holds a stale program path for Jasna - typically after you rename/move the Jasna folder or start a new version (e.g., v0.11.2) from a different folder while an older version (e.g., v0.10.0) was previously run, without rebooting. Fixes: 1) Reboot Windows, then run Jasna again - this resolves it in most cases. 2) Run Jasna from a normal folder on a regular local disk - avoid RAM drives, mapped/network drives, subst drives, VeraCrypt volumes, or paths containing junctions. 3) Upgrade past v0.11.2: the developer changed the path check in the next release so it no longer depends on the path name.

Question 2

How to fix slow performance and FPS decay on AMD GPU (ROCm/Windows) caused by MIOpen re-solving convolution kernels?

Accepted Answer

On AMD/Windows, ROCm wheels ship without a MIOpen system Find/Perf DB and the find timer is broken, so every convolution shape is re-solved on every occurrence — throughput decays as new input shapes appear (GPU idles while CPU is pinned in MIOpen). Workaround: set environment variables BEFORE any model loads:

```bash
export MIOPEN_FIND_MODE=3          # HYBRID: heuristic-first, persists finds to user FindDb
export AMD_COMGR_CACHE=1           # persist comgr compile artifacts
export AMD_COMGR_CACHE_DIR=/path/to/persistent/dir
```

On Windows: `set MIOPEN_FIND_MODE=3` (or set via System Environment Variables). The first run seeds the user FindDb (`%USERPROFILE%\.miopen\db\*.ufdb.txt`); from the second run on, cached kernels are reused. Measured gains: +37% end-to-end FPS and 4x faster primary restoration (79 ms/f → 20 ms/f), plus lower VRAM (9.0 → 7.1 GB). Do NOT set `MIOPEN_FIND_ENFORCE` — values other than 1/2 are rejected and `2` pins the broken timer path. Quality is unchanged; only selected kernels differ. In jasna, this is fixed: main now defaults `MIOPEN_FIND_MODE` to HYBRID on AMD, shipping with the next AMD build — just update. Upstream defect tracked in ROCm/TheRock #7958.

Question 3

How to fix JASNA LTX worker ProtectionError 'invalid LTX executable mapping'?

Accepted Answer

The LTX worker ProtectionError is caused by third-party software injecting DLLs into the worker process — most commonly antivirus behavioral inspection (not RTSS or MarkAny, which only cause the separate 0xc0000428 startup dialogs). Fix for ESET antivirus: 1) Open ESET → Setup → Advanced setup (F5). 2) Go to Protections → HIPS → Deep behavioral inspection → Exclusions → Edit. 3) Add the full path to jasna.exe (e.g., C:\Users\<user>\Desktop\jasna 0.11.1\jasna.exe). 4) Restart JASNA and run LTX again. If you use a different antivirus, add jasna.exe to its behavioral/HIPS/DeepGuard exclusion list instead. To also eliminate the startup DLL error dialogs (RTSSHooks64.dll / IMGSF50Filter_x64.dll, error 0xc0000428): add jasna.exe to RTSS application profiles with 'Application detection level: None', and stop or exclude MarkAny Image SAFER. To diagnose which program injects into the worker, use Microsoft Process Monitor with filters 'Process Name is jasna.exe' and 'Operation is Load Image' while reproducing the error.

Question 4

How to fix JASNA pipeline stalling with 'no frame encoded' watchdog errors on Windows ROCm (BasicVSR++ eager path)?

Accepted Answer

Set the environment variable `JASNA_BV_HIP_GRAPH=1` (the default) to use the HIP graph replay path for BasicVSR++ instead of the eager forward. The stall occurs only with `JASNA_BV_HIP_GRAPH=0` (eager mode) on Windows ROCm builds (e.g., RX 7900 XT, torch 2.14+rocm), where the detector thread parks inside a MIOpen convolution in the RF-DETR DINOv2 backbone and never returns, causing the encode-stall watchdog to fire repeatedly. Graph replay completes reliably on the same inputs (1080p and 8K). The likely root cause is a MIOpen find/compile race when the detector and eager restorer submit GPU work concurrently after the pipeline rework; you can help diagnose by running instrumented builds with `MIOPEN_LOG_LEVEL` or MIOpen `FIND_MODE` variants.

Question 5

Why does Jasna 0.11.2 get stuck at 99% during the scan (step 1) on long videos?

Accepted Answer

This is a known performance bug in v0.11.2: right after the scan reaches 99%, processing slows down drastically the longer the video is — a 2-hour video can appear stuck for many minutes. The developer fixed it (35s down to 3.5s in testing) and the fix ships in the release after 0.11.2, so update to the latest version. If it still looks stuck after updating, click the Log button, export the full log, and report it together with your video duration.

jasna

Core Features

What It Can't Do

Use Cases

Tags

Getting Started

Similar Projects