Home » Uncategorized

iPodderX Alert

12 June 2005 2 Comments

It looks as though at least one mystery of the bandwidth issue has been resolved. From parsing through server logs, it appears that iPodderX, Build 148, is ignoring the status codes it receives from a server. The server sends a “file unchanged” code, yet iPodderX requests the file, regardless. Over and over and over.

Given the size of the metered bandwidth bill The Roadhouse got hit with in May, this is a big, big issue that should be addressed immediately by the iPodderX team. I’m sure I’m not alone in being assessed for unnecessary bandwidth, directly related to poor code in their commercial product.

This is more than just speculation. What follows are the commands used to parse the access.log for The Roadhouse, and the results. Look for yourself. It’s clear that this is the issue.

Here’s the code my hosting provider and I have used to parse the logs:

awk '/11/Jun.*"GET .podcasts.roadhouse_[^"]*"/ {print $1,$9,$12,$13,$14,$15}' log/access.log | sort | uniq -c | sort -nr | head -10

Fundamentally, this sets up a regular expression looking through the log for requests for any Roadhouse .mp3 file. It also returns the status code from the log and the user agent. Finally, it sorts the results by the number of requests from unique IP addresses, displaying the top ten results. Here are those results for June 11:

400 68.110.7.232 302 "iPodderX/Version 3.0 Build: 148

388 68.110.7.232 200 "iPodderX/Version 3.0 Build: 148 176 69.143.161.205 302 "iPodderX/Version 3.0 Build: 148 176 69.143.161.205 200 "iPodderX/Version 3.0 Build: 148 176 64.124.179.97 502 "iPodderX/Version 3.0 Build: 148 160 64.81.50.8 302 "iPodderX/Version 3.0 Build: 148 160 64.81.50.8 200 "iPodderX/Version 3.0 Build: 148 128 62.252.0.12 302 "iPodderX/Version 3.0 Build: 148 128 62.252.0.12 200 "iPodderX/Version 3.0 Build: 148 95 64.252.97.35 302 "iPodderX/Version 3.0 Build: 148

The results show that IP address 68.110.7.232, for example, requested a Roadhouse file 400 times (the first space-separated field in the results), and received a “file unchanged” status code (302 – field 3). 388 times, it ignored the status code and downloaded the file (200 – also field 3). And, that’s just a single IP address in a single 24-hour period

The iPodderX Bug Reports Forum has many reports about multiple downloads. However, the iPodderX team doesn’t appear to have responded. If you’re an iPodderX user, please let them know that this is entirely unacceptable. Rather than facilitating podcasting, their bad code is actually crippling servers with unneccessary requests for files that haven’t changed. The fact that it’s a commericial product – a product that you’ve paid for – makes it even worse.

2 Comments »

  • Mike said:

    Please tell me Doppler, the podcatcher I use, does not do this. I know it does have a quirk listed beloe but I am pretty sure it doesn’t do the above., but can you check you logs to confirm for me. I am a beta tester for them so can give them feedback if they are doing you (and other producers of podcasts) wrong.

    I did notice that recently Doppler was trying to download previous Roadhouse shows, due to the new URL for the files. Luckily I caught it after only one extra show, and then did a “catch-up” to make all those new URLs as downloaded. This is because Doppler uses the whole URL for matching not just the filenames (I THINK). I have seen this happen with other podcasts where they move the mp3 files to another server, (ie. a podcast is using up thier space and bandwidth and move thier mp3 files to libsyn, adn redo the feed to point at the new libsyn server Doppler redownloads the files again, due to being a different URL)

    - 14 June 2005 at 9:37 am
  • Tony Steidler-Dennison said:

    Actually, Mike, Doppler handles the feeds quite well. They use a HEAD request which is much more effective and efficient. iPodderX insists on using a GET request. When we looked at the impact of iPodderX vs. Doppler, Doppler did very well.

    You make a good point, too, about the effect of the new enclosures on these clients. I hadn’t considered that they might try to get all the enclosures, given that they have different URLs, now. That would explain a higher-than-expected amount of traffic in the first 24 hours. That will probably level out as the clients cache the new address.

    Thanks, Mike.

    - 14 June 2005 at 9:49 am