While you are all busy putting flowers on the graves of the men (mostly) who died in this country’s wars, I’m pushing forward with improving the SRGuide information gathering process (meaning most of it can be done by others using the web -or is totally automated!)
Now that the web server is on its own stable platform and my old Windows XP is no longer my test platform of choice, I’ve been working to replace my old Visual Basic tools with php (the languages are not that different in the big universe of languages)
Here is what I’ve accomplished this morning:
The station involved is not significant, although it is typical and shows a few of the challenges.
What the process does is it tries to load the “Home Page” of the radio station, as known by the database. It then scans all of the links on the home page looking for the player. If it finds none (which is the case here), then it looks for a link on the page which might contain the player links – http://www.wloh.net/listenliveonlinehere.html in this example -loads that page, and then scans it for possible players.
The existing SRGuide Database only has the notion of 2 possible players (plus ooTunes for iDevices). The primary is the “best” link (typically an m3u link, or if none is available, a Windows Media Player link), and then an optional MP3/secondary link if there are both an MP3 link and a Windows Media Player Link (or other). [For the pedantic among you, it is no longer technically an MP3 link – it is an MP3 style playlist that almost always launches an AAC or AAC+ stream, which doesn’t have the patent issues of “true” MP3 streams)
This process found that the two streaming links are still valid (yay!) and that there are also two Shoutcast Playist links (.pls) [which don’t work in Microsoft Windows Explorer], a QuickTime player link [ack!] and a direct link (twice) to Tunein.
So given the ability to gather that information, how would it be useful and/or how can it be presented without getting out of hand? Other similar web sites try to list every possible link along with what they think the bit rate is. I’m pretty sure I don’t want to get that crazy. One approach would be to use the existing “Player” Icon to launch a popup, which would then list all of the identified player options and click a second time to launch the specific player you want. Another more complicated option (which really would need people logging in to be useful) is to allow you to say “These are the lists of player types I want to use” and then either give a popup with the players in that sequence, or just launch the player type that is your “best” preference. I’m pretty sure there are other options. For you people using WiFi radios and the like, I’m still not going to cross the boundary of reverse engineering players to find the raw streaming URLs – I only will show or use things “out in plain sight”.
This same web based PHP process can be used to potentially gather the program schedules, but as I’ve pointed out (especially to the volunteers), the station’s web site is a VERY unreliable source of programming information in many cases. At best, it might be used to “notice” schedule changes and pick those changes up more quickly.
I would be most interested in feedback from the people who might eventually use this tool as opposed to he people who only infreqently use the web site. [But most of those people also never read the blog!]