Troubleshooting

Symptoms, what causes them, and what to check.

Every entry below is a failure that was measured on a real machine, not a hypothetical. Where OVB writes an explanation into its log, the log line is quoted so you can search for it.

Where the log is

OVB writes a Python-side log to your temp folder:

%TEMP%\ovb_python_debug.log

On macOS it is in $TMPDIR. The log survives the crash it explains, so if Harmony closes during an import, that file is the first thing to open — and the first thing to send if you report the problem.

Lines that matter start with a tag: [raster] for the bitmap path, [apply] for the import loop.

Long imports

Harmony closed during a long sequence import, with no message.

Older builds kept the whole sequence in memory on both sides of the bridge — the parsed frames and the JSON handed to Harmony. Measured on a 16 GB machine with 840 real SVG frames: about 0.9 GB retained just in the frame list, and Import JS error: bad allocation shortly before Harmony vanished. 240 frames worked; 840 did not.

The vector import is now streamed: memory depends on the size of a chunk, not on the number of frames. Update to the current build and try again.

The import took more than an hour.

Also fixed, and it was not the drawing at all — it was process count. Each bitmap frame launched up to two utransform processes (new Process2 + launch), which is roughly 1,700 processes for an 840-frame sequence. The PNG is now converted to TVG in-process at the scene's density, so the "base" pass became a TVG→TVG copy and is skipped when the input is already a TVG: one call per frame instead of two, and zero for a lone line-art track.

Undoing a long import takes many steps.

Deliberate. A single undo block covering hundreds of frames makes Harmony hold every drawing creation until the import ends, which is the memory failure above. Past a threshold the block is committed in slices, and OVB says so in the log rather than letting you find out:

[raster] 840 frames > 100: committing the undo block every 100 frame(s) to bound Harmony's memory — undoing this import takes 9 steps

The "save the scene every N frames" box is greyed out.

That checkbox saves the scene periodically during a long import so Harmony frees memory as it goes, and what was already saved stays if you cancel. It needs a scene that exists on disk:

Locked: save the scene first.

Save the scene once, and the box unlocks — OVB re-checks on Apply, so you do not have to reopen the window.

The import stopped halfway. Can I continue from where it left off?

Yes — if Checkpoint save was on. The scene on disk then holds everything up to the last checkpoint, and the log names it:

[checkpoint] scene saved at frame 100 of 840

Import the rest into the same Read node, with Start and Range both beginning at the next frame. Say frames 1–100 are already in and you want 101–200:

1. Open the scene the checkpoint saved.
2. Select that Read node in Harmony's Node View.
3. In the Outliner, + → Add drawing from Node View — the drawing points at the existing node instead of creating a new one.
4. Bind the same sequence on the same art layer.
5. In the Drawing card (not the subartlayer): Start = 101, Range = 101–200.
6. Leave Checkpoint save on and Apply.

The frames already there are untouched: Replace clears one frame at a time, only the frames being written, and each frame becomes a drawing named after its own number — so 101…200 never collide with 1…100. The scene grows to fit the new frames on its own.

Range is which frames of the sequence to import; Start is where the first of them lands on the timeline. Give them the same number when resuming — Start = 1 with Range = 101–200 would write those frames onto 1–100 and overwrite what you already have.

Without Checkpoint save there is nothing to resume from

Drawings Harmony has written but not saved live only in its memory. If the import never saved and Harmony was killed, the work is gone — start over with the box on.

The scene will not save after an import

Harmony refuses to save with "Missing folder …/Temp/ovb_raster_xxxx" and "Cannot write palette list".

Whoever writes a TVG writes its PALETTE_LIST beside it. In older builds the final drawing was assembled from intermediate TVGs that lived in a temp directory, so the finished drawing inherited a palette reference pointing at a folder the import itself deleted on the way out.

Every intermediate TVG is now created in the element folder and swept afterwards; the PALETTE_LIST stays, which is where it belongs. If you have a scene already in this state, re-importing with the current build repairs the reference.

Bitmap imports

A second bitmap track erased the first one.

Harmony 24 can only load a drawing once, so two tracks written to the same {element}-{frame}.tvg meant the second one's pixels went to disk and were never loaded. All bitmap tracks of a drawing are now composed into one TVG before the create, so they arrive together. If you are on an older build, importing the tracks separately is what triggers it.

The bitmap does not line up with the vector art — it looks like a different resolution.

Converting a PNG to TVG at the scene's density uses DrawingTools.vectorize, which requires the Vectorize licence feature. Harmony Premium and Advanced ship it; without it the file goes to utransform at its own fixed default density, which will not match. OVB does not fail silently here:

[raster] frame 12 art 2: vectorize unavailable — importing at utransform's default density (may mismatch the vector art)

Two tracks with different alpha modes made the import much slower.

-premultiply is per utransform invocation, so it can only carry one mode for a whole frame. When the tracks agree, the conversion happens in C++. When they disagree, each track is straightened in Python instead — a per-pixel loop. The log says so when it happens; giving both tracks the same alpha mode restores the fast path.

The track landed off-centre, or short of where I put it.

The gizmo offset is baked into the pixels by growing the canvas with transparent padding — that is the only way to express "off centre" to a tool that centres whatever it is given. The canvas is capped at 16,384 px to stop a typo from asking for a multi-gigabyte image:

[raster] gizmo offset clamped to 16384px canvas — the track will land short

If you see that line, the offset is larger than the drawing can express; move the object instead of offsetting the track.

Frames and exposure

Some frames hold the drawing from the frame before.

A frame that failed to write leaves no column entry, so that cell keeps whatever was there — and every later frame reads as shifted against the tracks that did land. Silent holes are exactly how a sequence comes out "misaligned" with no error anywhere, so OVB reports them:

[raster] HOLES — 3 frame(s) never written: 47(base rc=1), 48(base rc=1), 49(base rc=1)

A frame came in empty.

If the source has no artwork at that frame number, the exposure is written empty on purpose. Sequences are aligned by frame number, not by position in a list, so a gap in the source stays a gap in the scene — and writing it empty is what stops a re-import from leaving the previous drawing in the cell.

Frame Range imported the whole sequence, or wrote past the end of the scene.

Frame Range indexes the sequence, 1-based and inclusive — 5–20 of a 100-file sequence means those 16 files, not all 100. OVB grows the timeline from that same range so no imported frame is dropped. If your scene looks truncated, check that the range and the scene length agree; the timeline is extended for you, never shortened.

Palette

The "−" button removed a colour I had just created in OVB.

Fixed in the current build. The palette panel's remove button and the colours created by the app were two loose ends of the same chain, and removing one could take the other with it.

Blender exporter

A pass came out empty, or shows what is behind the object.

In EEVEE, a material set to Blended does not write the Normal and Position passes — what you get is whatever is behind it. If the surface is actually opaque, set blend mode to Dithered instead. This is a Blender behaviour, not an OVB one, and no setting in OVB can work around it.

A horizon line disappeared, or became a hairline.

Geometry that is nearly edge-on to the camera collapses to a sub-pixel sliver before the tracer sees it. Give the surface a real thickness, or split the line out as its own pass.

Still stuck

Send %TEMP%\ovb_python_debug.log together with your Harmony version and the number of frames in the sequence. Those three things answer most of what a reply would have to ask for.

Support: octo-tools.com/support