# File Converter ## Local development 1. Copy `.env.example` to `.env` and fill in your local MariaDB credentials. 2. Install dependencies: `npm install` 3. Export those same `DB_HOST`/`DB_USER`/`DB_PASSWORD`/`DB_NAME` values from `.env` into your shell, then apply the schema with Prisma Migrate (creates the `conversion_jobs` table fresh, since a new local database starts empty): `DATABASE_URL=$(node scripts/printDatabaseUrl.js) npx prisma migrate deploy` 4. Run the API: `npm start` 5. Run the worker (separate terminal): `npm run worker` 6. Run tests: `npm test` (requires the same MariaDB reachable via your `.env` vars, exported into the shell) ## Deployment on o2switch 1. Upload the project (excluding `node_modules/`) via SSH/Git. 2. Create/adjust `.env` on the server with production values (`STORAGE_DIR` pointing to a writable path under your account, MariaDB credentials from cPanel). 3. `npm install --include=dev` (never with `--ignore-scripts` — Puppeteer needs its postinstall step to download Chromium). 4. Configure the app in cPanel "Setup Node.js App", pointing its entry point at `src/server.js`. Passenger manages this process (start/stop/restart). 5. Start the worker independently of Passenger, over SSH: `./node_modules/.bin/pm2 start ecosystem.config.cjs`, then `pm2 save`. Try `pm2 startup` to survive a server reboot; if that's not permitted without root on this account, fall back to a cPanel cron job every 5 minutes that runs `pm2 resurrect` (or checks `pm2 list` and restarts the app if absent) — validate which option this hosting plan actually allows once connected over SSH. 6. Add a cPanel cron job to run the cleanup script periodically, e.g. every 15 minutes: `*/15 * * * * cd /home/gaan6043/convert.ombrora.com-node && /home/gaan6043/nodevenv/convert.ombrora.com-node/24/bin/node src/cleanup.js > /dev/null` (adjust the path and node binary location to match your actual account — check with `which node` over SSH). 7. **ONE-TIME, before ever running `prisma migrate deploy` on this server:** the o2switch database already has the `conversion_jobs` table (created by hand, before this project used Prisma), but no `_prisma_migrations` tracking table. Running `migrate deploy` first would try to `CREATE TABLE conversion_jobs` again and fail with a "table already exists" MySQL error, leaving Prisma's migration history stuck and needing manual recovery. Avoid that by baselining the existing table once, ever, on this server, before step 8's `migrate deploy` runs for the first time: `DATABASE_URL=$(node scripts/printDatabaseUrl.js) npx prisma migrate resolve --applied 0_init` Do **not** repeat this step on later deployments — after this one-time run, `migrate deploy` (step 8) is the correct command going forward. 8. On every subsequent deployment: pull changes, `npm run deploy` ### Calibre ```bash mkdir /home/gaan6043/convert.ombrora.com-binaries mkdir /home/gaan6043/convert.ombrora.com-binaries/calibre cd /home/gaan6043/convert.ombrora.com-binaries wget -nv https://download.calibre-ebook.com/5.44.0/calibre-5.44.0-x86_64.txz -O calibre.txz python3 -c " import lzma, shutil with lzma.open('calibre.txz') as f_in, open('calibre.tar', 'wb') as f_out: shutil.copyfileobj(f_in, f_out) " tar -xf calibre.tar -C calibre rm calibre.txz calibre.tar ./calibre/ebook-convert --version ``` ### FFMPEG ```bash wget https://johnvansickle.com/ffmpeg/releases/ffmpeg-release-amd64-static.tar.xz python3 -c " import lzma import shutil with lzma.open('ffmpeg-release-amd64-static.tar.xz') as f_in: with open('ffmpeg-release-amd64-static.tar', 'wb') as f_out: shutil.copyfileobj(f_in, f_out) " tar -xf ffmpeg-release-amd64-static.tar rm ffmpeg-release-amd64-static.tar ffmpeg-release-amd64-static.tar.xz ```