One owner for what the iPod can play #9

New issue

Open

opened 2026-08-25 22:29:46 +02:00 by wokoman · 0 comments

wokoman commented

2026-08-25 22:29:46 +02:00

(Migrated from code.nolog.cz)

What to build

One module owns what the iPod can play — the file extensions, and the names libgpod uses for them. Copying and transcoding both read from it, and neither reaches into the other.

Right now the two split ownership of format policy and depend on each other in both directions: the transcoder calls into the copy engine to ask whether a file is playable, while separately restating the same libgpod format strings the copy engine's table already holds. Adding support for a format means editing two tables that have to agree, and the module cycle is the kind of thing that quietly blocks other refactors.

Roughly forty lines change hands. No behaviour changes at all, and the data involved is already covered by tests — which is why this is low risk despite touching two modules.

Acceptance criteria

Playable extensions and their libgpod names live in one place
Copying and transcoding both depend on that place, and not on each other
The libgpod format strings are written once
Adding a hypothetical new playable format requires editing one table
No behaviour change: existing tests pass untouched
cargo clippy --all-targets clean

Notes

The playability check has one non-test caller, and it is in the module that the copy engine depends on — so the check may not need to survive the move in its current form.

Blocked by

None — can start immediately.

## What to build One module owns what the iPod can play — the file extensions, and the names libgpod uses for them. Copying and transcoding both read from it, and neither reaches into the other. Right now the two split ownership of format policy and depend on each other in both directions: the transcoder calls into the copy engine to ask whether a file is playable, while separately restating the same libgpod format strings the copy engine's table already holds. Adding support for a format means editing two tables that have to agree, and the module cycle is the kind of thing that quietly blocks other refactors. Roughly forty lines change hands. No behaviour changes at all, and the data involved is already covered by tests — which is why this is low risk despite touching two modules. ## Acceptance criteria - [ ] Playable extensions and their libgpod names live in one place - [ ] Copying and transcoding both depend on that place, and not on each other - [ ] The libgpod format strings are written once - [ ] Adding a hypothetical new playable format requires editing one table - [ ] No behaviour change: existing tests pass untouched - [ ] `cargo clippy --all-targets` clean ## Notes The playability check has one non-test caller, and it is in the module that the copy engine depends on — so the check may not need to survive the move in its current form. ## Blocked by - None — can start immediately.