I received an SMS message on my cell phone today, informing me that Cingular (my carrier) had a free phone for me, all I had to do was stop by my local Cingular store and …. etc. It also nicely told me to reply with ‘STOP’, and I would not receive marketing messages from them anymore. I did so, and was instantly sent another SMS message informing me I would “no longer receive marketing messages from Cingular. Please allow 10 days for your preferences to be updated”.

You have to be kidding me. 10 days? Nothing takes 10 days anymore, especially when it comes to updating my SMS preferences. In 1860, the Pony Express got someone’s ‘preferences’ (mail) from Missouri to California in the same amount of time.

Update: In WordPress 2.1.x, the code below is now in the file wp-includes/bookmark-template.php

I wanted to put an image in the sidebar of this blog, but the default code puts a border around the image, because it’s also a link. I think that’s generally unattractive, but even the link editor didn’t allow me to set the border to 0, so into the code we go.

In wp-includes/links.php, lines 247-249, change this:

$output .= "<img src=\"$row->link_image\" $alt $title />";
else // If it's a relative path
$output .= "<img src=\"" . get_settings('siteurl') . "$row->link_image\" $alt $title />";

to this:

$output .= "<img src=\"$row->link_image\" $alt $title border=\"0\" />";
else // If it's a relative path
$output .= "<img src=\"" . get_settings('siteurl') . "$row->link_image\" $alt $title border=\"0\" />";

and now the images under the Links sidebar won’t have a border around them. Yes, I understand the border is supposed to be a visual cue that the image is also a link, but these days, most people know that things in the sidebar are generally links, plus the visual cue of the pointer changing when a user hovers over the image seems to be enough.

When compiling mod_ruby under Fedora Core 5, and thus Apache 2.2, configure.rb assumes an incorrect path for the apr* files, and make kicked out the following errors:

# make
In file included from /usr/include/httpd/httpd.h:43,
from mod_ruby.h:49,
from mod_ruby.c:33:
/usr/include/httpd/ap_config.h:25:17: error: apr.h: No such file or directory
/usr/include/httpd/ap_config.h:26:23: error: apr_hooks.h: No such file or directory
/usr/include/httpd/ap_config.h:27:32: error: apr_optional_hooks.h: No such file or directory
…

The problem is that the apr* files are in /usr/include/apr-1, which is not where make is looking. (In order to compile mod_ruby, the httpd-devel, apr-devel, and apr-util-devel packages are required, so doing a “yum install httpd-devel” installs these three packages).

To fix the problem, run the configure.rb command like this:

./configure.rb –with-apr-includes=/usr/include/apr-1

and then the “make” command will run without error.

Scott Whitney had a question for us regarding the number of downloads of your RSS (XML) file versus the number of downloads of the actual audio file (Podcast) identified within it:

Do you have any data regarding the normal ratio between number of feed downloads (the XML file) versus the actual number of audio downloads? And, any explanation why there would be a measurable difference?

Our response covers a couple of the many reasons why it will be different:

The number of downloads of the XML file versus the audio file is almost always very different, for several reasons. In a perfect world, all RSS aggregators would make use of the feature in which the aggregator asks the web server “Has this feed changed since I last downloaded it at time X ?”. If there was no new audio program in the feed, the server would respond “No”, and the XML file would not be downloaded. Only when there was a new post/program would the XML file be downloaded, as would the audio file, and there would be a 1:1 ratio between the two.

However, many aggregators do not use this feature, and just blindly pull the XML file every time, new or not. This, coupled with the fact that most aggregators can be changed by the user as to how often they check the XML file (anywhere from every minute to once a day), leads to the XML file being downloaded many more times than the audio file itself. Also, things like people opening the XML file in a browser, etc., lead to many more hits on the XML file than the audio.

I don’t have any hard data on the ratio of XML versus audio downloads, because it is all over the map depending on which podcast, time-period, etc. is looked at.

On a related note, inferring subscriber statistics from the number of hits on the XML file is very inaccurate, because of the same reasons. The number of downloads of the audio file itself is more accurate, but still not completely accurate, because of multiple downloads of the file by the same aggregator/person (more downloads than real subscribers), and services like iTunes and Odeo that cache your audio file for their users (less downloads of the file from your server than actual subscribers).

I’m surprised to find out that Bloglines does not update the favicons (the small icons that appear next to the feed name) dynamically. After quickly Googling the subject, I saw that you had to manually request that your feeds be ‘updated’, so that the favicon would show up. Very strange, since most other feed readers or browsers check for the favicon each time they pull the page. My only guesses are that they are doing it for bandwidth reasons, or that they don’t want your brand cluttering up ‘their’ page.

The email:

The results:

Larry Mason informed us that our most recent episodes of Endurance Radio would not play on the Emprex MP1003 MP3 player he had just recently purchased at Frys. This concerned me, because I know that often many different brands of MP3 players use the same chipset, and if it was a chipset problem, and not an embedded software problem, there could be many MP3 players out there that would not play our content.

I was unable to find this MP3 player at our local Frys, but was able to find it at Frys online partner/portal Outpost.com. Once delivered, I set out to find what was wrong with our MP3s that was causing them not to play on the Emprex.

My first shot was to remove all the ID3 tags from the MP3, and see what happened. Lo and behold, this stripped-down MP3 played correctly on the Emprex. Going back to the original MP3, and pulling various tags out of the MP3, I discovered it was the embedded GIF file we were using in the ID3v2 album art tag that was causing the problem. Once I removed just the album art, the MP3 played properly on the Emprex.

Referring to the ID3v2 specification, I noted that they say ‘The “image/png” or “image/jpeg” picture format should be used when interoperability is wanted.’ I inserted a JPG image as album art, and the file played properly. Next, I inserted a different GIF image, and this file also played properly, so it was not just a GIF/JPG problem. Interestingly, I noted that iTunes would not show the GIF album art, but would show the JPG album art (I was inserting the album art via TagScanner, not iTunes). Interoperability indeed.

The takeaways from this experiment are:

1) Always use JPGs as album art.
2) There is something in the GIF image in this program that causes the Emprex MP3 player to choke. Perhaps there is a common set of bytes in the image that the Emprex interpreted as MP3 data? This still remains to be investigated further.