INTERACT FORUM
More => Old Versions => Media Center 11 (Development Ended) => Topic started by: slr001 on June 18, 2006, 03:26:27 pm
-
Hey guys... new to v11, and new to Podcasts so might be operator error.
I have gotten some Podcasts to work, but this one seems to fail. Can someone try and see if I am doing something wrong?
http://www.bigpoker.ca/Rounders_rssfeed.xml
Thanks
Edit: v11.1.186
Also the feed seems to load fine in iTunes
-
Looks like it is an error handling the pubDate tag....
This is an entry prior to the error message
<pubDate>1 Feb 2006 10:07:31 -0800</pubDate>
This is the format the error message points to...
<pubDate>Wed, 18 Jan 2006 02:49:16 0000</pubDate>
Looks like they started sticking the day of the week in front of the date.
-
I think the problem is that 0000 should be +0000 to be a valid time-zone offset.
We'll try to make MC more forgiving. (although the RFC822 date format is tightly defined and should be followed by all proper Podcasts)
-
Updated build here:
http://yabb.jriver.com/interact/index.php?topic=34272.0
-
Thanks,
Will give it a try when I get home.
-
I tried the latest update .188 with the following feed that threw errors in MC revision .183:
http://www.onthemedia.org/index.xml
The error message reads:
This podcast feed is not currently available, or contains a data format error. Please notify the webmaster, or just check back later.
XML Field Error: channel tag = pubDate value = Fri, 23 Jun 2006 24:00:00 GMT
This feed still throws the same error in .188.
I suspect this is a boundary value condition where the current logic doesn't know what to do with 24:00:00 (is it 00:00:00 AM or 00:00:00 PM)? And it's arguable that 00:00:00 ever occurs.
I don't mind contacting the webmaster but what exactly should I tell him/her? Tell them to reference RFC822 date formatting specification?
FeedDemon, iTunes, iPodder (aka Juice) and NewsGator handle this feed without issue as I expect others do. I also suspect the webmaster may possibly push back given that other aggregators are not having issues with their XML file.
-
For what it's worth, I emailed them about their tricky 24:00:00. I'll let you know what they say.
In the meantime, is it possible for the parser to create a case for 24:00:00 and internally resolve it to 23:59:59?