v0.3.0

A service picker, and an honest word when the log does not fit

A transponder normally carries several services, each with its own elementary
streams and its own control words. A capture of one is the ordinary case rather
than a special one, and until now the window made a person work out which pids
belonged to which service by hand, because nothing read the program tables.

It does now. One survey pass returns both the pid table and the program tables,
and the Service picker offers what the recording actually holds, marked
scrambled or in the clear. Choosing one fills in its pids, so -n and -p cannot
disagree about what is being worked on.

"everything in the recording" is the default rather than the first service: a
recording of a single service is common too, and decrypting all of it is the
safe reading. The picker is there to narrow things, not to guess.

It also says so when the control word log was out of step with the recording. A
resync means part of the file was decrypted with a key the log had drifted
from, so the result has a seam in it, and the run still comes out green. That
is worth saying out loud rather than leaving in the log for anyone who goes
looking. It only appears with resync turned on, and without it the problem is
invisible.

Needs tsdec 2.5.0, which is where the program tables landed.

v0.2.0

A native Windows program, which is what this should have been.

0.1.0 was a browser pointed at a local server. It works, and it is still here
for a shell or an ssh session, but nobody wants to double click it. This is a
real window.

Download tsdec-gui.exe and run it. That is the whole installation: the
decoder is inside the program, so there is nothing else to download and nothing
to put on your PATH.

What it does

One job at a time, because that is the honest scope.

• Pick a .ts recording and a .cwl control word log, choose an output, run
  it.
• A real progress bar with a percentage, a throughput and an estimate, fed by
  the decoder's progress events rather than a timer.
• Stop a long recording. A request, not a kill, so whatever was already
  decrypted is kept, packet aligned and playable, and the result says how far
  it got rather than claiming the run finished. This is the button the 0.4.1
  Win32 GUI had, and the main reason this exists.
• Survey the pids with how much of each is scrambled, and narrow the run to
  the ones wanted.
• Thread count, cw blocker, resync past corrupt packets.
• Light and dark, following the system preference.

The stop, which is the fix that mattered

Ctrl+C is a console control event. A windowed program has no console to
deliver one from, so on the real Windows build the stop either did nothing or
turned into a kill, and a kill throws away every packet already decrypted.
That is the one thing the stop button exists to prevent, and it only showed up
once the program was actually frozen into an exe.

The front end now asks for a stop by creating a file, which needs no terminal
and behaves the same on every platform. That needed a matching change in the
decoder, released as
2.3.0.

Nothing asks before replacing an output

A stopped run leaves a partial file. Running again over the same name used to
destroy the part that had been written, silently. It asks now.

How it is checked

41 checks drive the window headless, 36 drive the web front end, and 14 check
the packaged executable as an artefact: a single exe in an empty folder, with
nothing on PATH, has to find its decoder inside itself, decrypt a recording,
stop one that is still going, and open a window.

That last one is the point. Every check against the Python modules passed while
the frozen build was quietly unable to stop a decode, because the Python
modules were never the thing that was broken. test_exe.py runs the artefact
in a job before it is published, so it cannot ship again.

Headless

The packaged program can also be driven without a window, which is how the
release job proves it works:

tsdec-gui.exe --decrypt -i recording.ts -f log.cwl -o clear.ts
tsdec-gui.exe --self-test

Licence

GPL v3, matching TSDEC.

v0.1.0

The first release of the front end.

tsdec-gui is a local web interface for
TSDEC, the offline decrypter for recorded
DVB transport streams. TSDEC does the work as a child process; this is only the
interface around it. There is no decoding code here and nothing links against
any, so the two can be released and debugged independently.

What it does

One job at a time, because that is the honest scope for a first release.

• Pick a .ts recording and a .cwl control word log, choose an output, and
  run it.
• Watch it happen: a real progress bar with a percentage, a throughput and an
  estimate, fed by the decoder's progress events rather than a timer.
• Stop a long recording. The stop is a request, not a kill, so whatever was
  already decrypted is kept, packet aligned and playable, and the result says
  how far it got rather than claiming the run finished.
• Survey the PIDs in a recording, with how much of each is scrambled, and
  narrow the run down to the ones wanted when a transponder carries several
  services.
• Thread count, CW blocker in bytes, and resync past corrupt packets.
• Light and dark, following the system preference.
• A log pane, for when a run ends oddly.

Running it

python tsdec_gui.py

No build step and nothing outside the Python standard library, so it runs
wherever Python 3 does. It prints the address to open.

The server binds to 127.0.0.1 and refuses anything else, and it serves only
the three files under web/, so a browser cannot be used to read the disk
through it. There is no authentication because there is nothing to
authenticate against beyond the local machine, and a password would only make
it look safer than it is.

Requirements

TSDEC 2.2 or later, which is where --json landed. It is found on PATH, next
to this checkout, or wherever you point it:

python tsdec_gui.py --tsdec /path/to/tsdec

The binaries are on the tsdec releases
page.

How it drives the decoder

Through tsdec --json, which writes one JSON object per line: progress
events while it works, then a single result event with the counts, the status
code and a sentence saying what happened. That is a documented contract, not
scraped log text.

Building this on top of the decoder is what turned up four bugs in it, all
fixed in 2.2.0: log lines that ran together so a pipe could not parse them,
Ctrl+C that did nothing under Windows when the process was started in its own
group, a throughput figure that counted processor time instead of elapsed
time, and a total missing from the result so a stopped run had no honest
percentage to show.

Tests

python test_gui.py

Builds a recording, runs it through a real tsdec, compares the output byte
for byte against the plaintext, and checks that a stop stops rather than kills.
33 checks. It ran in CI for this release against a decoder built in the same
job.

Licence

GPL v3, matching TSDEC.