Hi guys,
First off, I’ve forked the official TuneIn.bundle to my GitHub account as below. So far I’ve fixed streaming for some stations as well as the metadata grabbing for station, show title, show hosts and thumbnail URL. These don’t actually show in Plex (probably due to the age of the channel and incompatibilities with the latest versions of Plex server) but they show up correctly in the resulting XML, so it’s certainly a good start. Before they weren’t even making it into the Plex-generated XML (Info > View XML).
As I said earlier, some stations now stream perfectly after the small changes I’ve made. I’ve determined that this success is due to the Tune.aspx URL output by the channel resulting in a URL that refers directly to a stream hosted with the content provider for the station. However, sometimes the Tune.aspx URL refers to a playlist hosted with the content provider. Within these playlists tends to be one or more streams, sometimes differing in bitrate or codec.
In the current HEAD of my forked repository (using Local Radio > Manchester > All Stations > Manchester as an example), you’ll find that the likes of XFM Manchester streams perfectly. However, other stations such as the BBC radio stations, the family of Absolute radio stations etc don’t work. I’ve found that this is due to TuneIn forwarding requests through to a content provider hosted playlist, rather than directly to a stream. The channel will try and play the binary stream of the playlist rather than attempt to further parse it for streams, which is due to a lack of logic within the channel itself. This results in Plex attempting to play the next station alphabetically, continuing until the channel provides it with a binary stream that it can actually play.
My questions are these: How would you guys suggest implementing such logic in a generic, reproducible and compatible way? Realistically there is no telling how many levels of nested playlists one could encounter, though setting a sensible limit of 5-10 levels for example would probably be a good idea to prevent infinite loops, similar to how Apache implements “RewriteOptions MaxRedirects” to avoid redirect loops.
Has anyone here encountered this sort of challenge before when authoring channels, and if so, how did you opt to overcome it? I’d guess the main challenge is determining whether you’ve hit a binary audio stream or ASCII/UTF-8 formatted text file, and playing the stream if the former, or parsing it if the latter and subsequently attempting to perform the same check the result.
One way or another, I fully understand the challenge and believe that there isn’t a whole lot of work to be done in order to get the TuneIn.bundle channel working again (though I’m not entirely sure that it ever did fully work: it was authored before I began using Plex).
Finally, one of the main reasons I understand that development work halted on this plugin was due to API access being required from TuneIn, which apparently they denied/ignored. From what I can gather there will be no need what-so-ever for any TuneIn partner API access in order for this to function. By manually following the XML bread-crumb trail via my browser and playing streams via VLC there hasn’t been a single stream that I’ve tried that has failed, meaning that there’s no reason why this channel can’t be made to work. 
Fixing the issue I’ve focused on in this mail is pretty much the only barrier preventing all stations from working. After this is fixed, a channel logo added (we might need permission for that?) and a bit of tidying/modernisation, it should be ready for prime time.
Thanks for your time, and I hope that I can get some helpful feedback and get the channel back on it’s feet with the communities assistance.
Cheers,
Chris
