mediarss

Podcasts downloaded from Apple include custom hex-encoded metadata in COMM id3 tags. mediarss includes these COMM tags in its generated item descriptions which results in hex gibberish tacked onto the actual description. Here are the relevant ID3 tags of an example podcast mp3 from Apple (no TDES tag present): How music-metadata processes it: The item description mediarss generates in the feed: mediarss should ignore COMM tags with content descriptors matching iTun*.

Fixes #106 Summary Filter Apple private COMM frames (, , , …) out of so they no longer leak hex junk into RSS item descriptions Apply the same filter to both and native fallbacks (so iTun-only files don't fall through to the first native COMM value) Keep real COMM/comment text (empty or non-iTunes descriptors) Add regression tests covering the Apple podcast metadata shape from the issue Test plan [x] (format, lint, typecheck, unit tests) [x] Targeted coverage for iTun* filtering on common + native COMM    Summary by CodeRabbit Bug Fixes Improved podcast/RSS descriptions by excluding Apple iTunes private comment metadata. Preserved standard comment entries and combined them correctly when mixed with private metadata. Returned no description when the only available comments are iTunes-private. Tests Added unit coverage for description extraction, including mixed/private-only scenarios, and exported the description helper for direct testing.

I have a downloaded set of podcast episodes that weren't sorting by publication date correctly. Checking the id3 tags, the problem turned out to be: The music-metadata package exposes TDRL as releasedate. If TDRL (releasedate) exists I think it should be read and preferred over TDRC (date).