Hello, Andy! [EMAIL PROTECTED] wrote: > It's a good point, and I meant to say that I know it's not really > the podcatcher's problem to handle this. > >> Does the feed return a 404 page or simply some static served >> placeholder? I think this bug should be adressed by the podcast feed >> author by simply not adding the enclosure tag to the RSS feed until the >> file is available. gPodder already handles "mixed" podcasts (RSS feeds >> with some items that don't have enclosures) gracefully by ignoring the >> episodes without enclosure. > > I think it serves a placeholder page. Though I didn't prod enough on > Sunday. I'll try to grab it in time this Sunday just to see what it > does for sure.
Make sure you also watch the HTTP response closely (if you can't get to see it, try with Wireshark) and see if the status code is 404 or 200 or so. On the command line, you should also have a "HEAD" command if you installed the "libwww-perl" package on Debian. The "HEAD" command also gives you the HTTP status code. >> What kind of sanity check do you expect? It would be hard to implement > I wasn't sure if the things you use to pull things like track length > from the mp3 toss an error when given an HTML file. It gets onto the > iPod as a 1139-hour file that then doesn't play. Can you please zip up and send me your channels.opml (or URL of the feed) and the following files: * the (broken?) mp3 file in gPodder's download directory for that channel * the index.xml file in gPodder's download directory for that channel > But like you said, it's really an issue of the feed, and probably best > not to get too wrapped up in kludging around for one bad apple. I'll > still take a deeper look this coming Sunday and see if anything jumps > out at me. Thanks :) Thomas _______________________________________________ gpodder-devel mailing list [email protected] https://lists.berlios.de/mailman/listinfo/gpodder-devel
