Today I rewrote a Python script I wrote last year for calculating playoff magic numbers for the MLS. It can now function as a CGI script and can generate a reasonably attractive table of magic numbers in an HTML document. You can check it out at http://www.wombatnation.com/magicnumbers/.
The right side frame has an explanation of magic numbers. Hopefully, it makes sense.
In the scoring details on the MLS webpage, the time has always been given as just the minute of the goal, e.g, 34 for a goal in the 34th minute. The main exception is that goals in extra time are sometimes given a plus sign, e.g., 92+.
In today's game between Dallas and Colorado, Steve Morrow scored in the 92nd minute. For some reason, the time was entered as 92:00+. Fortunately, the only breakage in SoccerPhone was that scoring details were unavailable for this game after Morrow's goal was added to the website. A quick addition of a : to the regular expression for extracting scoring details fixed this.
I also cleaned up some inline JavaScript code in the mls.vxml file. I added the use of && for doing logical ANDs. I had temporarily forgotten that the JavaScript code is just the data for an XML element in the VXML file. Therefore, any inline JavaScript must be written as well-formed XML. In my case, that meant using && instead of &&.
The biggest problem is that the MLS website was really unreliable for a large part of the evening. The whole site was very slow. I often got timeouts on the scores and on the standings pages. I think it was their MySQL database getting hosed again. On one attempt to retrieve the scores, every score was replaced with the text from a MySQL error. I can't remember the exact text, but the exception was occurring in a php3 file and appeared to indicate a connection failure. Obviously, when problems like this are occurring on MLS's end, SoccerPhone is useless.
Fixed the problem where the Python script wrote the cached results to one place, but the VXML code looked for it in another directory. I didn't detect the problem earlier, because 1) I accidentally ftp'd a copy of results.xml to the VXML directory and 2) I didn't do a good job of regression testing failure scenarios. Now, if the MLS website doesn't respond in time, SoccerPhone will be able to read the results from the last time it successfully ran.
Whoever runs the MLS website is definitely keeping me on my toes. They made a couple new changes to the scores page that broke SoccerPhone again.
First, they dropped the date information from each score. Admittedly, I probably should have had exception handling code for this scenario, but it just seems strange that they would suddenly drop the date info, especially when most weeks as of late have had games on more than one day during the week. I'll need to go back and clean up the code I put in to handle this scenario, but it works for now. It's definitely good enough for code written at 1:30 am on a Saturday night.
Second, they changed the alt tags for the team images. The alt tags were not only an easy way for me to grab the team names, but also the proper way to code a website. Alt tags are there for a reason. Text-only browsers and web browsers for the blind depend on images having alt tags. I had to change my code to grab the team names from the relative file paths to the image files. Fortunately, they used the same abbreviations (e.g., SJ for San Jose) as for the scoring details, so I could reuse a Python function I had already written to convert team abbreviations to team names.
The recent ruling of the Librarian of Congress still contains the requirement that webcasters must pay performance royalties for each unique stream. Since it's impossible for a webcaster to tell whether a real person is on the other end listening to the stream, the webcaster must pay the performance fee regardless for every stream, even if no one hears the performance.
This could put webcasters in the position of encouraging their listeners to shut off their streams anytime they aren't actually listening. It's almost as if streamed music were a scarce resource, like potable water in New Mexico. If webcasters don't charge listeners per song for streams, "lazy" users could generate substantial wasted royalty payments for the webcaster. If webcasters do charge listeners per song, listeners have to worry about leaving the streaming client running everytime they walk out of hearing distance of their PC.
If the webcasters who own radio stations simply pass on the .02 cents per song charge for streams of on-air broadcasts, assuming 12 songs per hour, each hour would cost .24 cents. Leaving the tap open overnight for 9 hours brings the tab to 2.16 cents. For a pure webcaster with a .07 per song charge, assuming 15 songs per hour due to fewer commercials and mic breaks, the costs go to 1.05 cents per hour and 9.45 cents for the 9 hour overnight.
These charges won't bankrupt people, but can you imagine every single webcaster out there dealing with the billing nightmares to pull this off? Anyone with billing software for the mobile telephone industry may want to start making changes to support webcasters.
Do per stream charges sound familiar? Try the record industry's own, reportedly financially struggling, PressPlay.com (http://www.pressplay.com/terms.html):
"A "stream" means a Track that you may play back directly from and while you are logged to the Service. If you stream a Track for at least 30 seconds, one unit will be deducted from your available streams for that month. You may not attempt (or authorize, encourage or support others' attempts) to capture, copy, or download a streamed Track. If you do not stream the maximum number of Tracks that your subscription package allows in any particular month, the remaining streams will NOT carry over to the following month (e.g. if your package includes 300 streams per month, but you do not stream all 300 during that month, you will still have only 300 streams the next month)."
The standard Pressplay subscription gets you 200 streams. Now that's not 200 streams to listen to as much as you want. No, it's 200 "streamed songs." Although I haven't tried the service, it sounds like you have to manually stream the songs. Sort of like listening to samples at Amazon, but you have to pay to hear the whole song. This is no where near as complex as the billing for streamed songs that are part of a webcast will likely be.
If you listen to webcasted music, get ready for significantly reduced selection, more ads, and more fees. Thanks, RIAA, for doing your part to bomb the web back to the Stone Age.
I ran out of time before last week's vacation and never uploaded the new files for SoccerPhone. Consider it done. I even sort of tested it.
I finally got around to reading Fever Pitch during the World Cup, finishing it up just last week. Thanks to my wife's copy of The Omnibus, I have continued on with High Fidelity and will later read About a Boy. The Omnibus is published by Indigo in Great Britain. We luckily found a copy at Pendragon Books in Oakland.
Fever Pitch is a very humorous telling of Hornby's life mostly in terms of Arsenal matches. Okay, sure, Cambridge United and a few other teams take the lead position for a few of the chapters, but the heart of the story is Hornby's passion for Arsenal. Highly recommended.
Update: Since writing this, I've blogged a review of the movie version of Fever Pitch as released on DVD.
