I'm not sure I put this in the correct category. It's
really a problem with enclosure grabbing.
The problem is that if the URL for an enclosure
referenced in a particular feed is invalid (e.g.
results in an HTTP Error 404) iPodder will save the
error page as the enclosure.
I noticed recently that I was getting .mp3 files that
appeared as HTML files instead of MP3 files on my
system (Ubuntu 4.10). That is, they have HTML icons and
context menus. I opened one in my text editor and it is
in fact the HTML of the error page.
I made a test feed with one item that referenced a file
that didn't exist in the enclosure tag. I subscribed to
the feed in iPodder and ran a scan. iPodder downloaded
the error page and saved it with the enclosure file name.
Logged In: YES
user_id=1120007
How should iPodder handle this?
Logged In: NO
In my experience the 404 errors are often due to temporary
conditions (e.g. a problem uploading the enclosed file). I
think there is value in being able to redownload them, but
probably only with user intervention.
In the GUI version (which I haven't looked at in depth) it
might work to list the missing URL in the pending downloads
list with some kind of flag. Then the user could choose to
try downloading it again or delete it from list.
In the command line version, I would just like to be able to
set in a mode that is silent unless there are problems. That
way cron could send me an email whenever there was a 404.
(Right now, if I don't block the email, cron will email me
all of ipodder's output, including every line of the
download progress.)
Logged In: YES
user_id=847427
The last comment from nobody (2005-02-12 11:31) was actually
from me. I realized too late that I wasn't logged in. Sorry.
Logged In: YES
user_id=1120007
copied from newer bug:
OpenPodcast was over its hourly quota, and was
responding to requests for MP3s with HTML. It spake
thusly (the enclosing <h.. tags removed):
<head>
<title>403 Forbidden</title>
</head>
<body>
<h1>Error: 403 Forbidden</h1><br>
Error when attempting to use the Coral Content
Distribution Network (<a
href=http://www.coralcdn.org/>http://www.coralcdn.org/</a>).<P>The
hostname specified in the Coralized URL is currently
over its hourly quota. Please try back later.
<br><br>
<hr>
<i>Server CoralWebPrx/0.1.11 (See http://coralcdn.org/\)
at 128.100.241.68:8090</i>
<br>
</body>
But Ipodder saved this in the specified download
directory with the mp.3 extension; Windows MediaPlayer
10 believed Ipodder's .tag until it went to play the
file and found an improper header, and bitterly
complained about it.
Maybe some [i]deus ex machina[/i] code here?