After reading workflow notes again I realised I made a mistake by downloading ltx23_echoVid-ltxAud_surgical_int8_convrot.safetensors and LTX23-echoVid-ltxAud-Surgical-DiT-Q8_0.gguf. Normally, I do not use GGUF as they are not supported by ComfyUI and in general I avoid using them (no dynamic VRAM support by ComfyUI) .

Only one of the checkpoints FP8/BF16 from joeygambino/joyai-echo-ltx23-echoVid-ltxAud-surgical is really needed as a model file and no other checkpoints/gguf files are needed.

Now I hit another wall:

• Exception Message: FileNotFoundError: Gemma sidecar files missing: preprocessor_config.json.
  Put them in one of:
  • the same folder as your Gemma file (/media/xxx/models/text_encoders/gemma-3-12b)
  • /home/xxx/apps/ComfyUI/custom_nodes/ComfyUI_JoyAI_Echo_GGUF_Nodes/gemma_assets (ships with the node pack)
    These ship inside the node pack's gemma_assets folder -- if they're missing, re-download the pack from GitHub rather than pulling configs from the google repo (google's config.json is the multimodal variant and is NOT compatible with this pipeline).

I have the files in both /media/xxx/models/text_encoders and also /home/xxx/apps/ComfyUI/custom_nodes/ComfyUI_JoyAI_Echo_GGUF_Nodes/gemma_assets but it still reports them as missing.

You've got the checkpoint part exactly right - one fp8 or bf16 model file, nothing else. And I think I found the sidecar bug; it's not that your files are missing, it's that the pack can't stage them.

Here's the mechanism: for a single-file Gemma, the loader copies the sidecars (preprocessor_config.json etc.) into a hidden folder called .gemma_virtual_folder that it creates NEXT TO your Gemma file - in your case inside /media/xxx/models/text_encoders. If that location is a read-only or restricted mount (very common for /media auto-mounts on Linux), the folder can't be written, so the sidecars never actually land there - and the check that follows looks in .gemma_virtual_folder, finds nothing, and reports them missing. That's why they're "present in both locations" but still missing: the problem is the staging destination, not the source.

Two ways forward:

1. Immediate: move your single-file Gemma to a writable location (anywhere under /home works, e.g. next to your other writable models), point gemma_path at it there, and it'll stage fine. Or, if you can, make that /media folder writable by your user.

2. Just pushed a fix: the pack now checks whether the model folder is writable and, if not, stages the sidecars under your system temp dir automatically - no more read-only-mount failures. It's in the current pack + the v1.5 zip. The error message also now tells you exactly which folders it searched and whether each file was found-but-couldn't-be-staged, so this class of problem self-diagnoses.

Update the pack (or grab v1.5), restart Comfy, and it should load from /media without moving anything. If it still fails, paste the new error - it'll now name the exact staging folder and what it found where.

You've got the checkpoint part exactly right - one fp8 or bf16 model file, nothing else. And I think I found the sidecar bug; it's not that your files are missing, it's that the pack can't stage them.

Here's the mechanism: for a single-file Gemma, the loader copies the sidecars (preprocessor_config.json etc.) into a hidden folder called .gemma_virtual_folder that it creates NEXT TO your Gemma file - in your case inside /media/xxx/models/text_encoders. If that location is a read-only or restricted mount (very common for /media auto-mounts on Linux), the folder can't be written, so the sidecars never actually land there - and the check that follows looks in .gemma_virtual_folder, finds nothing, and reports them missing. That's why they're "present in both locations" but still missing: the problem is the staging destination, not the source.

Two ways forward:

1. Immediate: move your single-file Gemma to a writable location (anywhere under /home works, e.g. next to your other writable models), point gemma_path at it there, and it'll stage fine. Or, if you can, make that /media folder writable by your user.

2. Just pushed a fix: the pack now checks whether the model folder is writable and, if not, stages the sidecars under your system temp dir automatically - no more read-only-mount failures. It's in the current pack + the v1.5 zip. The error message also now tells you exactly which folders it searched and whether each file was found-but-couldn't-be-staged, so this class of problem self-diagnoses.

Update the pack (or grab v1.5), restart Comfy, and it should load from /media without moving anything. If it still fails, paste the new error - it'll now name the exact staging folder and what it found where.

My /media folder is writable and .gemma_virtual_folder exists in both locations /media/xxx/models/text_encoders and later created /media/xxx/models/text_encoders/gemma-3-12b. I did not want the sidcar files copied in my general /media/xxx/models/text_encoders folder so I moved the GGUF to a new folder where the same .gemma_virtual_folder was created successfully. So it is not an issue of access/write rights, all folders in /media/xxx/models/ are normaly writable both by local user and ComfyUI.

My /media/xxx is not auto-mounted, it is fstab entry with rw access, just a different drive to store all model files.

You've got the checkpoint part exactly right - one fp8 or bf16 model file, nothing else. And I think I found the sidecar bug; it's not that your files are missing, it's that the pack can't stage them.

Here's the mechanism: for a single-file Gemma, the loader copies the sidecars (preprocessor_config.json etc.) into a hidden folder called .gemma_virtual_folder that it creates NEXT TO your Gemma file - in your case inside /media/xxx/models/text_encoders. If that location is a read-only or restricted mount (very common for /media auto-mounts on Linux), the folder can't be written, so the sidecars never actually land there - and the check that follows looks in .gemma_virtual_folder, finds nothing, and reports them missing. That's why they're "present in both locations" but still missing: the problem is the staging destination, not the source.

Two ways forward:

1. Immediate: move your single-file Gemma to a writable location (anywhere under /home works, e.g. next to your other writable models), point gemma_path at it there, and it'll stage fine. Or, if you can, make that /media folder writable by your user.

2. Just pushed a fix: the pack now checks whether the model folder is writable and, if not, stages the sidecars under your system temp dir automatically - no more read-only-mount failures. It's in the current pack + the v1.5 zip. The error message also now tells you exactly which folders it searched and whether each file was found-but-couldn't-be-staged, so this class of problem self-diagnoses.

Update the pack (or grab v1.5), restart Comfy, and it should load from /media without moving anything. If it still fails, paste the new error - it'll now name the exact staging folder and what it found where.

[ERROR] !!! Exception during processing !!! Gemma sidecar files missing: preprocessor_config.json.
preprocessor_config.json: not found in any searched location
Searched, in order:
/media/xxx/models/text_encoders/gemma-3-12b
/media/xxx/models/text_encoders/gemma-3-12b/gemma_assets
/media/xxx/models/text_encoders/gemma-3-12b/gemma
/home/xxx/apps/ComfyUI/custom_nodes/ComfyUI_JoyAI_Echo_GGUF_Nodes/gemma_assets
Staging folder: /media/xxx/models/text_encoders/gemma-3-12b/.gemma_virtual_folder
If a file shows FOUND-but-could-not-stage, the staging folder is read-only (common for /media mounts) - the pack now falls back to a temp dir automatically, so update the pack. Otherwise the files ship in the pack's gemma_assets folder; re-download the pack rather than pulling configs from the google repo (google's config.json is the multimodal variant and is NOT compatible with this pipeline).
[ERROR] Traceback (most recent call last):
File "/home/xxx/apps/ComfyUI/execution.py", line 543, in execute
output_data, output_ui, has_subgraph, has_pending_tasks = await get_output_data(prompt_id, unique_id, obj, input_data_all, execution_block_cb=execution_block_cb, pre_execute_cb=pre_execute_cb, v3_data=v3_data)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/xxx/apps/ComfyUI/execution.py", line 342, in get_output_data
return_values = await _async_map_node_over_list(prompt_id, unique_id, obj, input_data_all, obj.FUNCTION, allow_interrupt=True, execution_block_cb=execution_block_cb, pre_execute_cb=pre_execute_cb, v3_data=v3_data)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/xxx/apps/ComfyUI/custom_nodes/ComfyUI-Lora-Manager/py/metadata_collector/metadata_hook.py", line 171, in async_map_node_over_list_with_metadata
results = await original_map_node_over_list(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/xxx/apps/ComfyUI/execution.py", line 316, in _async_map_node_over_list
await process_inputs(input_dict, i)
File "/home/xxx/apps/ComfyUI/execution.py", line 304, in process_inputs
result = f(**inputs)
^^^^^^^^^^^
File "/home/xxx/apps/ComfyUI/custom_nodes/ComfyUI_JoyAI_Echo_GGUF_Nodes/nodes.py", line 906, in encode
text_encoder = model"text_encoder_builder"
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/xxx/apps/ComfyUI/custom_nodes/ComfyUI_JoyAI_Echo_GGUF_Nodes/nodes.py", line 666, in _build_text_encoder
wrapper = RebelsJE_TextEncoder().run(
^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/xxx/apps/ComfyUI/custom_nodes/ComfyUI_JoyAI_Echo_GGUF_Nodes/rebels_loaders.py", line 842, in run
raise FileNotFoundError(
FileNotFoundError: Gemma sidecar files missing: preprocessor_config.json.
preprocessor_config.json: not found in any searched location
Searched, in order:
/media/xxx/models/text_encoders/gemma-3-12b
/media/xxx/models/text_encoders/gemma-3-12b/gemma_assets
/media/xxx/models/text_encoders/gemma-3-12b/gemma
/home/xxx/apps/ComfyUI/custom_nodes/ComfyUI_JoyAI_Echo_GGUF_Nodes/gemma_assets
Staging folder: /media/xxx/models/text_encoders/gemma-3-12b/.gemma_virtual_folder
If a file shows FOUND-but-could-not-stage, the staging folder is read-only (common for /media mounts) - the pack now falls back to a temp dir automatically, so update the pack. Otherwise the files ship in the pack's gemma_assets folder; re-download the pack rather than pulling configs from the google repo (google's config.json is the multimodal variant and is NOT compatible with this pipeline).

I copied the missing preprocessor_config.json inside .gemma_virtual_folder, restarted ComfyUI but the error message is still the same.

I copied gemma_assets inside /media/xxx/models/text_encoders/gemma-3-12b and it sill won't load.

Got it - and your error message is the key. It says preprocessor_config.json is "not found in any searched location," and that list includes the pack's OWN gemma_assets folder (/home/xxx/apps/ComfyUI/custom_nodes/ComfyUI_JoyAI_Echo_GGUF_Nodes/gemma_assets). So my read-only-mount theory was wrong - your mount is fine. The real problem: the file genuinely isn't in the pack's gemma_assets on your machine, and it turns out that folder was never actually shipped in my patch. The loader depends on it but I never distributed it - so if your base pack's gemma_assets was incomplete, there was nowhere for the loader to find the sidecars. My bug, not your setup. Sorry for the runaround.

Fixed now, two ways to get unblocked:

1. Immediate (no update needed): copy these six files directly into your Gemma folder, /media/xxx/models/text_encoders/gemma-3-12b (the first location it searches - put them right in that folder, not in a gemma_assets subfolder):
   config.json, preprocessor_config.json, processor_config.json, special_tokens_map.json, tokenizer_config.json, tokenizer.model
   They're the Gemma tokenizer + config sidecars. Restart Comfy and it'll stage them and load.

2. Proper fix: I just pushed an update that BUNDLES gemma_assets inside the pack, so this can't happen anymore. Update to the latest patch (or grab the v1.5 zip) and gemma_assets ships with it - no manual copying, loads from /media as-is.

One note on where to get those six files if you go the manual route: they ship in the pack now, or from a full gemma-3-12b-it download - but do NOT grab config.json from the google/gemma-3-12b-it repo specifically; that one's the multimodal variant and isn't compatible. The pack's version is the text-only config this pipeline needs.

You are right, I updated the module and copied over new files from gemma_assets directly inside /media/xxx/models/text_encoders/gemma-3-12b and now it seems to be loading.

I'm was hitting OOM's however. I haven't seen OOM 's for a long time since ComfyUI uses dynamic VRAM but mybe it cannot be used here? Got past by enabling sequential_offload=true.

Now I get this, I will try to solve it tomorrow:

ComfyUI Error Report

Error Details

• Node ID: 67
• Node Type: JoyEcho_Generate
• Exception Type: RuntimeError
• Exception Message: RuntimeError: Could not load libtorchcodec. Likely causes:
  1. FFmpeg is not properly installed in your environment. We support
  versions 4, 5, 6, 7, and 8, and we attempt to load libtorchcodec
  for each of those versions. Errors for versions not installed on
  your system are expected; only the error for your installed FFmpeg
  version is relevant. On Windows, ensure you've installed the
  "full-shared" version which ships DLLs.
  2. The PyTorch version (2.11.0+cu130) is not compatible with
  this version of TorchCodec. Refer to the version compatibility
  table:
  https://github.com/pytorch/torchcodec?tab=readme-ov-file#installing-torchcodec.
  3. Another runtime dependency; see exceptions below.
  
  The following exceptions were raised as we tried to load libtorchcodec:

[start of libtorchcodec loading traceback]
FFmpeg version 8:
Traceback (most recent call last):
File "/home/xxx/apps/ComfyUI/venv/lib/python3.12/site-packages/torch/_ops.py", line 1503, in load_library
ctypes.CDLL(path)
File "/usr/lib/python3.12/ctypes/init.py", line 379, in init
self._handle = _dlopen(self._name, mode)
^^^^^^^^^^^^^^^^^^^^^^^^^
OSError: libavutil.so.60: cannot open shared object file: No such file or directory

Thank you for troubleshooting today.

So close! That's the hard part done. Two things in your message:

OOM / dynamic VRAM: expected, and sequential_offload=true is the right fix. This pipeline doesn't run through ComfyUI's model manager - it's the vendored JoyAI-Echo inference stack, so ComfyUI's dynamic VRAM offloading doesn't apply to the DiT. Its own offloader (sequential_offload + the resident_blocks knob for how many transformer blocks stay pinned on GPU) is how you manage VRAM here. So no worries - you did exactly the right thing.

The torchcodec error: that's a system dependency, not the pipeline. torchaudio on torch 2.11 hands WAV encoding to torchcodec, which needs FFmpeg's shared libraries installed at the OS level - your error (libavutil.so.60: cannot open shared object file) means they're not there. Two fixes, either works:

1. Best/universal: install FFmpeg system-wide - sudo apt install ffmpeg (or your distro's equivalent). torchcodec supports FFmpeg 4-8 and finds the shared libs; this also covers ComfyUI's own video nodes, not just mine.
2. Venv-only: pip install soundfile into your ComfyUI venv - it bundles libsndfile and handles WAV without any system FFmpeg.

And I just made the pack robust to this regardless: the per-shot WAV save now falls back torchaudio -> soundfile -> Python's builtin wave writer, so that specific crash won't happen anymore even without FFmpeg. Update the pack (or v1.5 zip) and re-run. If ComfyUI's own CreateVideo node still complains about torchcodec afterward, that's the same missing-FFmpeg thing - option 1 above clears it everywhere.

Thanks for sticking with it - you've shaken out two real bugs today (the missing gemma_assets and this), both fixed for everyone now.

Hi, I'm back at it today.

I already had ffmpeg 6.1.1 system wide and torchcodec 0.10.0, soundfile 0.13.1 in comfyui venv installed prior the error message. My system however does not have libavutil.so.60, only libavutil.so.58

ldconfig -p | grep libavutil                           
        libavutil.so.58 (libc6,x86-64) => /lib/x86_64-linux-gnu/libavutil.so.58

There is no higher version available in default Ubuntu 24.04 repos.

I updated with latest of your module zip archive today, got past the error but ComfyUI hard crashes here:

[JoyEcho] Loading DiT generator...
[JoyEcho] Loading VAEs...
[JoyEcho] Model loaded. Audio sample rate: 48000
[JoyEcho] Conditioning cache HIT (conds_f8c39cd78fcbd9d8.pt) - 2 shot(s), encode skipped entirely.
[JoyEcho] Generating 2 shot(s) at 608x416, 321 frames [sequential offload]...
[JoyEcho] Shot 1/2, seed=42, memory_size=0
[JoyEcho] Sequential offloading installed: 48 blocks (24 resident on GPU, 24 streamed)
[JoyEcho] head-trim: dropped 14 frames from shot 1 (all outputs + per-shot preview).
[JoyEcho] wav via soundfile (torchaudio failed: RuntimeError).
[JoyEcho] Shot 0 saved → /home/xxx/apps/ComfyUI/output/joyecho/shot_000.mp4
[JoyEcho] Shot 1/2 done.
[JoyEcho] Shot 2/2, seed=43, memory_size=1
[JoyEcho] Sequential offloading installed: 48 blocks (24 resident on GPU, 24 streamed)
[JoyEcho] head-trim: dropped 14 frames from shot 2 (all outputs + per-shot preview).
Inconsistency detected by ld.so: ../elf/dl-tls.c: 613: _dl_allocate_tls_init: Assertion `listp != NULL' failed!

Files shot_000.wav and shot_000.mp4 are successfully created, but ComfyUI crashed to command line just before second part sampling.

I suspect it could be related to the change you made yesterday to overcome the error message i saw?

Edit:
I just updated ffmpeg 6 (released 2023) to ffmpeg 8.1.2 (curent latest from 6/2026) and it solved the crashing issue. Now everything seems to run without crashing Comfy.

For Ubuntu 24.04:

sudo add-apt-repository ppa:ubuntuhandbook1/ffmpeg8
sudo apt update
sudo apt install ffmpeg

Nice! Glad to see someone finally got it working! These are my first public workflows and models, so I'd never really anticipated that everyone else is going to be on different hardware and different versions (and different OS) of anything I'd actually built it on.

Nice! Glad to see someone finally got it working! These are my first public workflows and models, so I'd never really anticipated that everyone else is going to be on different hardware and different versions (and different OS) of anything I'd actually built it on.

I perfectly understand. I always presume it will take some time to make it run as it is never an easy way with new stuff. Thank you for your work on JoyEcho Model ComfyUI support and help along the path.