Skip to content

feat(metadata): advertise media metadata (bitrate / length / codec) for shared files #140

Description

@got3nks

Follow-up to #136 / #139 (Phase A — display media metadata received from peers in search results).

Phase B: extract media metadata from aMule's own shared files and advertise it to the ed2k servers + Kad, so other clients see populated Length / Bitrate / Codec columns when our files come back in their searches. Today aMule contributes nothing to the metadata pool — grep -rE "FT_MEDIA_BITRATE|FT_MEDIA_LENGTH|FT_MEDIA_CODEC" src/ returns only consumer-side code; no path reads media info from local files.

The ed2k advertisement layer doesn't need any change: CKnownFile's tag-publication code already serialises every tag attached to the file, so once we populate the tags, they ride out to servers + Kad automatically.

Where the gap is

Need a MediaProbe abstraction that, given a CPath, returns (length_seconds, bitrate_kbps, codec_name) for audio/video files. The values then get attached as FT_MEDIA_LENGTH / FT_MEDIA_BITRATE / FT_MEDIA_CODEC tags on the CKnownFile at share-add time and re-computed when files change.

Options for the probe backend

Backend Pros Cons
ffprobe subprocess (shell out to the binary) Universal codec coverage; no link-time dep; clean license boundary (LGPL/GPL stays out-of-process); user supplies path Requires ffmpeg installed; adds a PreferredFFProbePath preference + autodetection; one fork-per-file (~50 ms/probe) — bulk re-share could be slow but acceptable behind a thread
libavformat link (from ffmpeg) Fast (no subprocess), comprehensive Heavy dep; LGPL vs GPL nuance (we'd need LGPL ffmpeg builds); build complexity bumps on every platform; +5-10 MB binary size
MediaInfoLib (BSD, cross-platform) Smaller than ffmpeg; clean API Another dep with its own quirks; eMule AI uses this on Windows
Per-format hand-parsers (mp4 / mkv / mp3 metadata only) Zero new deps Massive maintenance burden, partial coverage

Suggested direction

Start with ffprobe subprocess as the default — it's the cleanest dependency story (zero link-time deps, user opts in by installing ffmpeg). Add a preference:

Preferences → Shared Files → Media metadata extraction:
  [✓] Enable
  Path to ffprobe: [/usr/local/bin/ffprobe          ] [Browse...]  [Detect]
  • Default state: enabled if ffprobe is on $PATH, disabled otherwise.
  • Threading: probe off the main thread (extend CSharedDirWatcher's existing batch path).
  • Caching: don't reprobe unchanged files (compare mtime + size against cached tags).
  • Failure mode: silent skip with a debug-level log line; no UI noise for files ffprobe can't read.

Out of scope for this issue

  • Title / Album / Artist tags (FT_MEDIA_TITLE / _ALBUM / _ARTIST) — same plumbing applies but the UI columns aren't there yet. Track separately.
  • Linking libavformat directly — only if ffprobe subprocess turns out to be too slow under heavy load.

References

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions