Not Speaking For J River, But It Is The Responsibility of the Podcast creator to create it in the approved format. There Are Many Websites you can run the script Thur that will tell you what is wrong with the script, so really there is no excuse why the two above podcasts are incorrectly formatted.
They need to correct it or get out of the Kitchen
KingSparta's 2 Cents
King,
I respectfully disagree with your perspective for the following reasons:
1. Let's speak clearly. There is *no* podcast format. Rather, there is RSS (in all it's versions, the latest of which is 2.0) and Atom 1.0. You might think the distinction is pedantic, but it's critical to understanding the next part.
2. RSS 2.0 requires that dates conform to RFC 822. There are web-based validators such as
http://feedvalidator.org/ that you can use to check a feed. In this case,
http://www.computerwoche.de/rss/podcast.xml is far from valid because of the date issues as well as the length attribute of enclosures.
3. An RSS or Atom aggregrator (which is what MC has become now that is parses feeds for enclosures (aka podcasts) should be graceful in parsing it's feeds. Either spit out the reason the feed is invalid (which is *easy* to do), or make assumptions about the feed and hide the details to the user.
So... regarding number 3... I think MC should make some assumptions about the feed. For example, in this case if the pubDate doesn't conform to RFC 822, then ignore the pubDate altogether. But there's no reason to choke altogether.
Regarding your comment about getting out of the kitchen if you can't make valid RSS or Atom... that's a bit harsh. No full-time aggregator application could take that approach.