Not too sure whats going on here. Just fired it up for the first time and it crashes with this error
/usr/bin/python: No module named py_captions_for_channels.main; 'py_captions_for_channels' is a package and cannot be directly executed
Which installation process did you use?
Docker/Portainer/Intel GPU
what operating system and version?
Lubuntu and I'm running the latest version
Found it — thanks for reporting this, it was a real bug. Not your setup.
The short version: the container's docker-compose file had a leftover developer setting that replaces the app's code inside the container with whatever's in the folder next to your compose file. For a normal git clone install that's harmless, but with Portainer that folder doesn't actually contain the source — so it wiped out the container's entry point and it crashed on startup with that error. Nothing you did wrong.
I just pushed a fix. Once the new image finishes building (check back in an hour or so), here's what to do:
- Pull the new image and redeploy the stack in Portainer (or
docker compose pull && docker compose up -dif you're on the CLI). - If you're sticking with Portainer, there's now a dedicated Docker / Portainer section in INSTALL.md — worth following since it also covers a couple of Portainer-specific gotchas around the recordings folder path that would've bitten you next (they need to be set as stack environment variables, not just in
.env).
Let me know if it still doesn't come up after redeploying and I'll dig further.
After it successfully installs, the next challenge will be to get it to work. I've tested CPU-only with Intel, but I have not fully tested parakeet or groq on an Intel GPU system yet. So, you're in beta territory. Here's the instructions for switching to parakeet after running the installation wizard (The wizard doesn't know about parakeet or groq yet):
Two equivalent ways — no container restart needed either way, since the transcription step runs as a fresh subprocess (python -m py_captions_for_channels.embed_captions) per job that re-reads .env from scratch. Whatever's set takes effect on the next job, not before.
Via the web UI: 
Settings → find WHISPER_LOCAL_ENGINE → switch dropdown from faster-whisper to parakeet → Save. PARAKEET_DEVICE should already default to cpu (the only supported value right now).
Via .env directly (or the equivalent Portainer stack var if you went that route):
WHISPER_ENGINE=local
WHISPER_LOCAL_ENGINE=parakeet
PARAKEET_DEVICE=cpu
This only takes effect if WHISPER_ENGINE=local (or if it's on groq and it falls back to local on a failed cloud call)
Ok, thats a bit confusing
All of the environmental variables should be in the docker-compose file then. Having another .env file on top of the environmental variables that already has to be set is confusing AF and unnecessary. I think thats causing all the bugs here