devedeng-extended/ROADMAP.md
Luna 63f10f3aa0 Mark roadmap A3 (error surfacing) done
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-05 12:23:27 -07:00

80 lines
4.2 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# 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)
- [x] **A1. Automated test suite (pytest).** DONE — `tests/` with 43 headless
tests covering the split planner + chapter helpers,
`compute_high_profile_bitrate`, ffmpeg command generation (profiles,
text/image hardsub, 2-pass, even pad/crop, AC3 448k, progress-to-file,
`-ss`), ffprobe subtitle detection, and executor I/O. CI in
`.forgejo/workflows/tests.yml`. Caught/guards the 448k→384k clamp bug.
- [x] **A2. Harden subprocess I/O (kills the deadlock class).** DONE — the
executor now drains child stdout/stderr with background reader threads
into thread-safe buffers, consumed by a GLib timer on the main thread, so
a stalled/wedged main loop can never backpressure-deadlock a child on a
full pipe. stdout can go straight to a file, stdin is fed from a thread,
the retained log is bounded, and `wait_end` runs once. Verified a 2MB-
output child completes with the main loop never running.
- [x] **A3. Surface real errors to the user.** DONE — the error dialog now
leads with a focused summary (failed step, its command, last stderr
lines) built from the executor's bounded `stderr_data`, with the full log
still in the expander. Markup-escaped + unit-tested.
- [ ] **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).