fix(noise): suppress recurring ffprobe demuxing-error lines in non-verbose activity log (closes #847)#953
Closed
Salem874 wants to merge 1 commit into
Closed
fix(noise): suppress recurring ffprobe demuxing-error lines in non-verbose activity log (closes #847)#953Salem874 wants to merge 1 commit into
Salem874 wants to merge 1 commit into
Conversation
…rbose activity log (#847) `Error during demuxing: Invalid data found when processing input` fires from ffprobe stderr on virtually every track during enrichment — modern ffmpeg's partial-moov-atom warning at byte 0. Downloads complete; ffprobe falls through to a valid result on retry. But the noise produces ~20 entries per album in the activity log, reported in #847 as the most-aggravating recurring noise. Implementation modelled exactly on the shipped #660 pattern (`is_python_traceback_noise` + non-verbose suppression in `download_queue.rs::emit_subprocess_line` gate): - New `process::is_ffprobe_demux_noise(line: &str) -> bool` in `utils/process.rs`. Match keys on the structural `[in#<digit>/<demuxer-list> @ 0x<hex>]` prefix plus both required tail substrings (`Error during demuxing:` AND `Invalid data found when processing input`). Tight enough that genuine ffmpeg demuxer errors that share words pass through; loose enough to survive future demuxer-list shifts (the comma-separated demuxer names vary by ffmpeg version). - Wired into both stdout (line 10958) and stderr (line 11155) reader gates in `download_queue.rs` — `is_known_noise` now combines both `is_python_traceback_noise` and `is_ffprobe_demux_noise`. The 5th arg to `emit_subprocess_line` (`show_in_ui`) stays `verbose || !is_known_noise` so the on-disk activity-log writer still records every line — forensic record intact for support requests. 6 new unit tests pin the contract: - Canonical Apple Music shape (verbatim from the #847 issue report) - Leading-whitespace + wider-hex-pointer tolerance - Alternate demuxer lists (aac, wav,mp3) — future-proof against ffmpeg auto-selection changes - Genuine ffmpeg errors pass through (muxer errors, parameter errors, generic "Invalid data" without the demuxing prefix) - Empty / unrelated / traceback lines pass through - Wrapped GAMDL `[INFO HH:MM:SS]` prefix doesn't false-positive - Requires `0x<hex>` pointer form — gate fails open (noise resumes) if upstream switches format rather than over-suppressing Closes #847
Contributor
PR Security ChecksHardcoded absolute filesystem paths (derive from app_data_dir / std::env, not literals)Generated by |
Contributor
Author
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Closes #847 — the most-aggravating recurring log noise in the user-facing activity log. ffprobe's "Invalid data found when processing input" warning fires from stderr on virtually every track during enrichment as ffmpeg encounters the partial-moov-atom case at byte 0. Downloads complete; ffprobe falls through to a valid result on retry. But ~20 noise lines per album turned the activity log into static.
Implementation modelled exactly on the shipped #660 pattern (`is_python_traceback_noise` + non-verbose suppression in `download_queue.rs::emit_subprocess_line` gate). Verbose mode still surfaces everything; on-disk activity-log writer still records every line so support requests stay debuggable.
What changed
Design choices
Why a tight structural match rather than a regex on the literal demuxer list? Future ffmpeg may auto-select a different comma-separated demuxer list (the canonical `mov,mp4,m4a,3gp,3g2,mj2` set could shift to include / exclude formats). The match keys on the bracket shape `[in#N/...` + the `@ 0x]` pointer suffix, which has been stable across ffmpeg 4.x / 5.x / 6.x / 7.x. If upstream ever switches the pointer format the gate fails OPEN (noise resumes) rather than over-suppressing genuine errors. Safe-default direction.
Why combine with the existing #660 gate rather than a separate emit path? Single `is_known_noise` boolean keeps the call site readable + avoids the "every new noise filter doubles the branching" pattern. Future noise gates land in the same OR chain.
Tests
6 new unit tests pin the contract — all green:
Verification
Test plan
🤖 Generated with Claude Code