I literally just did...were you watching the API log? *grin*
I just ran 3 exact matches through with no '%'s; they returned pretty quickly. They checked out (as hopefully they will when the length of the returned list is 1) as the program I expected them to be. The good news is that I got the mediaUrls from my Google Reader Listen Subscriptions "read" feed; so I can now:
a) Listen to podcasts on my Android device with Google Listen (or for that matter, in any fashion that uses Google Reader for podcast feeds, and marks them read properly).
b) Periodically have a script check my Listen "read" feed for newly listened programs, and pull out the mediaUrls (you can go arbitrarily far back on this, so if I haven't queried it for, say...a week, that's ok. I just change the timestamp that I go back to).
c) Take those mediaUrls, use the programs/search?mediaUrlLike query from the SpokenWord API to get programIds, and then add those programIds to my "Recently Listened" collection.
No more manual "trying to find what I just listened to in SpokenWord"! This makes is much, much easier for me to quickly scan this collection do things like rate programs, move programs to other (more manually curated) collections, etc.
Seems to be working fine so far...it's just been hand-tested python at this point. I'm wiring things together into a test script now, and hopefully should put things into a cron job over the weekend.
Please let me know if the queries become bundensome on the MySQL db, Doug. I don't query unless I have a "listened" mediaUrl, and in this model, they're all intended to be unique; no '%'s. So it shouldn't be too bad, but if things go awry, let me know and I'll change frequency (or strategy) as needed.
There are some edge-case, ill-behaved "podcasts" that reuse media urls...ick. Nothing much to be done about that, but AFAIK they are pretty rare.