this bug error is only in a 4090 environment ?
I was about to bring up the same thing. It does seem to be holding details temporally for a set of frames and then jarringly restarts the process without a smooth transition. I have a 3090 but the same issue happens on the output from Topaz’s servers.
7 Likes
Update coming soon ? 
for fix bugg
5 Likes
Yes, the model would need a MUCH higher batch size (which I fear isn’t possible due to RAM constraints) or some overlap blending between the batches to make those transitions soft and less noticeable.
The latter should not be that hard to implement but will cost speed because of the necessary overlap. But I would gladly opt for slower speed but smooth motion/a steady image.
This is one of the main reasons I don’t use SeedVR 2 - cause after having seen this glitch once it drives me crazy … 
6 Likes
hmm but then I don’t understand why they don’t max out available Vram and System RAM, spill to ssd for sets that are rare used, maybe a gentle lossless compression algorithm that requires little computing power.
1 Like
In the sample above the batch size is mere 30 frames.
Even my 16Gb 5070Ti can process 63 frames’ batches with 10 frames overlap, which eliminates such jumps.
2 Likes
Because even moving data from VRAM to RAM slows down computing.
Moving it further to SSD will slow processing to a halt. I’ve experienced it with SeedVR2 and beleive me - you wouldn’t like it.
1 Like
Nope. It just makes them less obvious.
Ideally this should be used together with the scene detection feature and the batch sizes adapted to fit the whole scene until the next cut - if possible of course (since quite some scenes will still be too large).
In those cases where the scene is too large to fit in one single batch blending should be used.
2 Likes
RTX 3090 24GB-VRAM / AMD Ryzen 9 5950X / 128GB RAM / Win11
Precision 2.5 works really good ..
My test:
320x160 → SeedVR2.5 → 1920x960 → Precision 2.5 → 3840x1920p
looks very nice
1 Like
does it really works on 3090 ?. As per requirements, it needs cuda compatibility 8.9
jop its working by me. I have Nvidia Studio Driver 591.86
What resolution did you start with and what resolution did you upscale to?
540p-960p
1 Like
I like how it isn’t super high resolution, but it still looks very clear. You don’t need to go to 4k or something crazy.
Yeah I’ll be running some 4k tests but by and large I think it’s hard to get the detail you want out of the kind of VHS tapes I’m dealing with. I think going to 960p and then maybe a proteus pass to 1080p or 1440p is the best result. Or even just rendering 960p source at 1080p.
Now I have some 1080p VHS captures (the VCR I have has some rudimentary upscaling technology in it) I’m going to try rendering in SLP at 1x and we’ll see how that does. Will try 2x also.
1 Like
Immediate error when trying to start up Precise. Some of the other models work. Fresh log with just this one try to start Precise to process.
logsForSupport.zip (1.2 MB)
With SEEDVR2, if you have enough vram, you can increase the batch size and set the number of frames to overlap. It makes a huge difference on temporal consistency and smoothness. Maybe Starlight should offer manual setting of batch size and batch overlap too.
5 Likes
after importing full log (step by step) into ChatGPT, the answer is:
What’s actually going wrong
Even though your file loads:
File Loaded successfully: ...Star Trek Voyager S06E04.mkv
the model pipeline (slp-25) ends up with an empty clip buffer.
That usually happens when one of these breaks:
1) Scene detection / trim bug (most common)
Starlight Precise internally chunks clips. If:
- you set a trim range, or
- scene detection misfires
…it can produce a segment with 0 frames, which this model refuses to process (needs ≥5 frames).
Other models often tolerate this — SLP does not.
2) Decode issue specific to that model path
SLP uses a slightly different pipeline (PyTorch + VAE/UNet stack). If decoding fails silently:
- container loads
- frames never reach model
Result: 0 frames.
3) Variable framerate / unusual MKV stream
Your file:
Star Trek Voyager S06E04.mkv
If it’s:
- VFR
- has broken timestamps
- or weird keyframe spacing
…SLP can choke while other models don’t.
4) Very short clip selection
If you’re testing with:
- a preview range
- or a very tight in/out
…it can literally drop below 5 frames.
What to try (in order)
Quick fixes (often enough)
- Clear any trim / in-out range
- Set full clip
- Disable preview-only export
- Disable scene detection
- Or set it to “none”
- Switch to constant framerate
- Re-encode a small test:
ffmpeg -i input.mkv -vf fps=23.976 -vsync cfr -c:v libx264 -crf 18 test.mp4
Then try SLP again
If that doesn’t fix it
- Try a different container
- MKV → MP4
(Topaz + SLP has had quirks with MKV demuxing)
- Check preview vs full export
- Does full export fail but preview works (or vice versa)?
- That tells us where the pipeline breaks
- Update / rollback Topaz Video AI
- You’re on
1.4.0per the log - SLP-25 is relatively new → version mismatches can cause exactly this
Subtle clue in your log
This warning earlier:
Could not find timeline with psUID: 29
…and:
Cannot read property 'video' of null
That suggests the UI/timeline state bugged out before export, which can absolutely lead to a “0 frames” handoff.
Translation: the export job may be starting with a broken timeline reference.
Most likely cause (based on your log)
If I had to bet:
Timeline/trim state bug → export job created with empty segment → SLP rejects it
This lines up perfectly with:
- UI warnings
- immediate failure after “RUNNING”
- 0-frame error
Fastest workaround
Do this exactly:
- Remove the clip from the queue
- Restart Topaz Video AI
- Re-import the file
- Do not touch trimming or preview
- Apply Starlight Precise
- Export full clip
Extra observation (important for quality)
Your video:
704x480 (NTSC DVD)SAR: 0.888889Rotation: 3 (!!)Codec: FFV1
That rotation = 3 is unusual
This might also confuse Topaz
my comment: NTSC-DVD is: 720 x 480 (in this case with the flag 4:3 when play), recommend leave 720x480 without crop, you can’t see the small left/right bars, because we play on 16:9 screens…or crop and strechts from 704 to 720, make sure video header is flaged as 4:3 and choose in topaz “square pixels”
let us know if u have success, I am also wondering why 140 works for some and not others and where is the fix patch like to see logs from working system
