Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[ChrisRainman]

I'd love not to need itunes anymore for podcast feeds. I setup some podcasts in MC11.1 but not all of them seem to work.

Example:

http://www.computerwoche.de/rss/podcast.xml
http://www.handelsblatt.com/rss/PodCast.xml

What's wrong with them?

Can anybody advise?

[JimH]

It might be the date format.

We'll take a look at it.  This should be posted in the podcast thread here.

[KingSparta]

the first one does not even work in ITunes

And Jim Is right the date in the Podcast on the first one is in the wrong format and is prob the problem with it

the date in the second one is also in a incorrect format

there is a standard format for date and if the people who make them do not use the correct format they will not work in all players.

some are willing to make an effort in correcting the mistakes of others, but howmany formats are there for dates? it gets a bit hard to sort out.

maybe a better way to do this is to allow the program MC to toss out any invalid format and create a new one for the item in the podcast.

[JimH]

And Jim Is right the date in the Podcast on the first one is in the wrong format and is prob the problem with it

That was a lucky guess, wasn't it?

[KingSparta]

I know why podcasts use the ISO8601 date format

However it sure does make it hard for people trying to figure out how to correctly make a podcast.

[ChrisRainman]

Thanks you took a look at the podcast files. I assumed something like that but didn't believe two big german newspapers would ignore the formatting rules.

I can imagine that lots of users will ask similar questions like I did in case podcasting gets more and more popular. Especially, in countries with different date formatting rules such errors will happen.

What to do now?

What about other podcasting software? Are they supporting non-standard date formats?

I would at least show a message when creating the podcast that there's something wrong with the format. So MC users can go and ask for a correction at the podcast producer. I will try it...

[KingSparta]

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

[IlPadrino]

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.

[KingSparta]

No I agree with you It should not choke, and i said that above by stating to toss out the date if it is not in RFC 822, Or try to figure out what the date is but continue. There is no reason to choke on a date.

but, if your going to put something out you as a PodCast creator should make sure it is going to work on as many players as possible, and the RFC 822 date seems to be the date standard by many "Official" publications (what ever level you want to take that as, maybe self proclaimed) and online Podcast checkers.

One the first podcast above I tried it on 5 players not one of them would work on it to include ITunes, the second had better success.

[Gene]

I'd love not to need itunes anymore for podcast feeds. I setup some podcasts in MC11.1 but not all of them seem to work.

Example:

http://www.computerwoche.de/rss/podcast.xml
http://www.handelsblatt.com/rss/PodCast.xml

These will work in the next build.  I have had to make the code *very* permissive about what is accepted in a date.

For example 30/11/2005 is now accepted as November 30, 2005.  This makes dates ambiguous in some cases (think about the next day's episode entered as 1/12/2005) but I think it is probably better to read the Feed and get the date wrong than not to read the Feed at all.

So far it looks like essentially all the Podcasts out there do a reasonable job at XML (except for symbols like &) but a large number of the authors have never peaked at RFC822 to format date/time.

gene

[KingSparta]

I have been playing with dates for the last 2-3 years and it amazes me how many formats people use. just the other day i had to add a few more to my OTR Tagger I guess thats why i get upset about dates. Sometimes i think if they could turn the numbers upside down they would

I prefer

1940-12-31 since this is easily sortable in simple list controls without adding complex code.

[IlPadrino]

So far it looks like essentially all the Podcasts out there do a reasonable job at XML (except for symbols like &) but a large number of the authors have never peaked at RFC822 to format date/time.

I wonder how many podcast "authors" are really applications that aren't doing things right.  It would be nice if MC could throw a warning to warn the consumer that the feed isn't valid.  This would let users provide some feedback to the creators and let them know they (or their software) isn't working as it should.

Gene:  I'd hope MC treats valid RSS/Atom properly and only makes assumptions when the feed is invalid.  Otherwise, it wouldn't be fair to those that are doing things right.

King:  I sympathize with your frustrations - especially when the requirements are so clearly spelled out.

[IlPadrino]

So far it looks like essentially all the Podcasts out there do a reasonable job at XML (except for symbols like &) but a large number of the authors have never peaked at RFC822 to format date/time.

Gene,

Remembering that podcasts are a subset of RSS feeds, and that JRiver "produces" an RSS feed for their forum, I thought I'd check to see how well it validates...

Sorry

This feed does not validate.

    * line 15, column 55: pubDate must be an RFC-822 date-time (100 occurrences) [help]

                   <pubDate>Thu, 01 Dec 2005 01:22:23 GMT Standard Time</pubDate>

Ouch!

[ChrisRainman]

These will work in the next build.  I have had to make the code *very* permissive about what is accepted in a date.

Thanks a lot already for working on this!

I can understand the frustrations about some authors incorrectnesses with writing podcasts. But, this doesn't help for the MC product. Users try out podcasting with MC and if it doesn't work they tell everybody that it's not able to cope with podcasts and switch to itunes or any other more flexible supplier (I am aware that also itunes cannot handle all feeds but that's not essential here).

The most important thing is that users may not even notice that it's not the fault of MC. So, at least MC must state that there's a problem with the feed so users can ask for a correction (like IlPadrino also stated).

By the way, I wrote to both publishers. One answered with an automated email, that's all. For me it looks like podcasting is still far away from attracting lots of people (at least in Germany) so they don't care about it...

[JimH]

Gene,

Remembering that podcasts are a subset of RSS feeds, and that JRiver "produces" an RSS feed for their forum, I thought I'd check to see how well it validates...

The RSS feed is a feature of the forum software we use.  JRiver didn't write it.  If you want to chase the problem, please report it to the SMF/Lewis group below.

[IlPadrino]

The RSS feed is a feature of the forum software we use.  JRiver didn't write it.  If you want to chase the problem, please report it to the SMF/Lewis group below.

Then this is evidence regarding my previous quote of

I wonder how many podcast "authors" are really applications that aren't doing things right.

You can't blame the authors if their software is creating the invalid RSS.  There is benefit in letting consumers know, so the producers can be told, that the feed isn't correct.

[JimH]

Agreed.

This is all quite a big moving target for everyone concerned.

[lOth]

Despite the increased 'permissivity', this one (CNN news update) still doesn't work in MC :

http://www.cnn.com/services/podcasting/newscast/rss.xml

[ChrisRainman]

Hey, you made the 2 podcasts working - at least a bit:

For http://www.computerwoche.de/rss/podcast.xml I can see only two entries in MC whereas the file contains many entries. Why does MC only show 2 articles? Is it something in the XML file that indicates to show only 2 entries or just a bug in MC?

Anyway, thanks for what you did so far!