devedeng-extended/ROADMAP.md
Luna b5a6cfe25f Add project roadmap
Prioritized A/B/C plan: safety net (tests, subprocess hardening, error
surfacing) first, then finishing fork features, then modernization.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-04 05:22:14 -07:00

4.5 KiB
Raw Blame History

Roadmap — devedeng-extended

Direction for the hardsub/auto-split fork of DeVeDe-NG. Ordered by leverage: the safety net comes first because everything after it is safer to build once it exists. Checkboxes track status.

Phase A — Safety net & correctness (do first)

  • A1. Automated test suite (pytest). The project has no tests today; every change is hand-verified. Start with the pure logic that already isolates cleanly: - plan_disc_split, _movie_chapter_seconds, _nearest_chapter_before - compute_high_profile_bitrate - ffmpeg/avconv command generation (convert_filecommand_var) with mock file_project objects, asserting flags for each profile, text/image hardsub, 2-pass, even pad/crop, AC3 448k. Add a tests/ dir and a CI workflow (Codeberg Actions/Woodpecker). This would have caught the 448k→384k clamp bug automatically.

  • A2. Harden subprocess I/O (kills the deadlock class). executor reads child stdout/stderr via blocking GLib.IOChannel watches; a stalled consumer can backpressure-deadlock the child (this bit us — ffmpeg froze on a full progress pipe when the GUI wedged). The progress-file fix only covers ffmpeg progress; dvdauthor/spumux/mkisofs stdout/stderr still use the fragile pattern. Build one hardened helper (non-blocking reads, drain-on-close, bounded buffers, never let a child block on a pipe we own) and route every backend through it.

  • A3. Surface real errors to the user. Failures show a generic error window; the actual failing command + stderr is buried in the log. On failure, show the command and the last N stderr lines. (Diagnosing the deadlock this session required strace//proc spelunking.)

  • A4. Narrow bare except: blocks. Config loading, pre_function/ post_function, ffprobe JSON parsing, etc. use except: pass, silently swallowing real bugs. Catch specific exceptions; log the rest.

Phase B — Finish & polish current fork features

  • B1. Multi-disc burning flow. The split feature makes N ISOs but the done-handler only offers the last one. Add "burn disc 1 → prompt to insert disc 2 → …" so the split workflow is complete end to end.

  • B2. Per-disc menu space in the split planner. plan_disc_split reserves menu space only on disc 0, but per-disc menus now exist on every split disc. Menus are small (a few MB) and fit in the 10% margin, so this is a correctness nicety, not urgent. Reserve menu bytes per disc.

  • B3. OCR for image subtitles (optional path). Image subs (PGS/VOBSUB) are currently overlaid as bitmaps. Add an optional tesseract/OCR path to convert them to styled text when the user prefers crisp text and the tool is installed (this was the originally-discussed "OCR optional" branch).

  • B4. Progress UX. One raw-percentage bar per core, no overall view. Add: ETA per encode, an overall "disc N of M / file X of Y" indicator, and persistent per-file labels. Matters most for long unattended batches.

  • B5. "Already DVD" guard. Warn when the input is already 720×480 MPEG-2 (likely a previous DVD output) to avoid a needless second- generation transcode.

Phase C — Modernization & reach

  • C1. Drop the avconv/avprobe backend. libav/avconv has been defunct since ~2018 and doubles the maintenance surface for every encode change (each ffmpeg edit must be mirrored). Remove it once ffmpeg is the assumed backend; simplifies converter.py and the converters.

  • C2. CLI / headless mode. Everything requires the GTK GUI. A devede-ng --project x.devedeng --output dir/ (and ideally a direct input video → hardsub → 480p NTSC → split → ISOs one-shot) would enable scripting, server use, and far easier automated testing.

  • C3. GTK3 → GTK4. GTK3 is maintenance-only; this is the long-term wall. Large effort; schedule deliberately.

  • C4. Consolidate UI construction. GLADE .ui files are hand-edited XML (fragile — newer widgets are built in Python instead). Pick one approach (likely programmatic or GTK4 templates) and converge.

Known limitations carried from current work

  • Split discs: burning is manual per-disc (see B1).
  • High profile uses a 3000k quality floor / 9000k cap; near-cap bitrates stress old players (acceptable — it's the explicit "high quality" choice).
  • No tests / no CI yet (A1).