Continued from the previous entry: Aural Stream Updates and Tutorial: Preliminary remarks, objectives, and exploration, we see that with WinAmp successfully configured to stream to ShoutCast, the Radionomy.com page (which is merging with ShoutCast at the time of writing) associated with the channel automagically presents a “Last tracks played” listing.
This is a pretty interesting feature in itself; a feature that begs the curious to ask “how can this functionality be emulated elsewhere, say, on my own web page?”
Here is an opportune time to speak to a core mentality when it comes to “hacking”, “reverse engineering”, “software engineering”, even life in general: that every problem is, at its core, a logistics problem. Given that the desired thing came from somewhere, point A, and is now at point B, how does one go about first getting “at it”? then getting it to point C? This is truly is at the heart of it. Making this sort of analytical thinking habitual – almost engrained into one’s very mentality – yields dividends far beyond the technological realm.
“What is desired is over there, how best to get it over here?”. Often the answer to this question lies in tracing it back to its source by asking “how did it get there?”
So here what we do is hit F12 on Chrome and check the Network tab
Sure enough, there’s this function GetLastTracksPlayed issuing an XHR (Xml Http Request) which looks as if gets called at a set interval to retrieve the track listing.
From here, if all one were interested in were taking this output and incorporating into their own project, they’d start by checking the source for that function, which looks like this:
We can see it’s a Post using a relative URL, so we’re going to modify it slightly to use the full or absolute URL.
Then we see it’s passing a radioUID parameter which means to test this all out, the URL’s going to look like this:
(where, of course, XXXX-XXXXXXX-XXXXX is replaced with your radioUID)
Here’s what we get back:
Success! With a few modifications, one can make their own function on their own site or project to consume this data as they see fit.
We can chose to work with this. It will suffice, at least for some, maybe. This might have answered a simple question someone else may have had. For DiVas, however, there’s a few issues here:
Firstly, there’s a lot to be desired in terms of data that’s available. Going from the data returned above to the data in the final product depicted below seems nigh impossible. And indeed, it is!
Secondly, in using any form of XHR to get data, one puts oneself at the mercy of whatever’s going on in the back end: the controller. At any time and without any forewarning, the developers, who do not owe you anything and do own the service, can do any number of things to cause the function to change. They may change the URL, they may require additional parameters, they may even add, take away, or rearrange the data that gets returned. All of those things leave you either playing whack-a-mole with API changes or just crossing your fingers that nothing changes. And all this to say nothing of the hoops one must jump through should the need to circumvent CORS policy arise. So we’re not going to take this route in this project – at least not for the last tracks played feature. It will be returned to for the now playing feature and to illustrate how to circumvent restrictive CORS policies.
The instructive moments here, however, are that tons of websites work this exact same way. What you’ve learned here can be applied elsewhere – anywhere there’s dynamic data on the web you may want to “get at” and cannibalize or repurpose. Sometimes the process is easier, sometimes it requires a bit more reverse engineering, but this is the gist of how that all works.
The other instructive moment here is never stop at the first right answer! The first right answer is usually better suited for a different but similar problem (in this case, this is exactly the case, and we’ll come back to this for the “currently playing” piece several entries from now). When you have a vision in mind, though, you don’t want to compromise that by stopping at the first thing that seems like it might work. It’s a bad practice.
That said, we now move on to trace the data flow further upstream. How does the data make its way to the URL to which the XHR is sent? Ironically, the answer to that is you, yourself, are the source of it and this too applies all over the map. Often the case really is that the data or thing you want to get at is something you’ve already handed-over to some tech conglomerate that they just locked behind a paywall and had their way with. The thing you’re after is something you’ve had all along. That’s a whole separate topic, though.
Stay tuned for Part 2 Where from here? Datatables, SQL Server, stored procedures, what can go wrong and meanwhile listen-in and see where all this is leading up to at https://digitalvalhalla.net/streaming-aural/