Re: scanUrl not being called

Paul Webster wrote: 
> Looks like the OPML code insists on "url" and does not have a
> non-display equivalent like streamUrl.
> The hideURL attribute does not seem to help either.
> 
> So - I think I do need the ability to have my PH URL in the menu result
> (in the end) in PlayHLS being invoked (subject to me determining at run
> time that HLS is what is required for the target URL).

I have only had a quick look but you have a full PH which expects to
play playable URLs (e.g.http/aac with possible redirections ).  HLS URLs
are not playable URLS - they always a playlist which has to be
processed, it can result in multiple possible URLs (e.g. different bti
rates) each of which is a playlist. So PlayHLS has its own scanURL and
also getnexttrack - so my gut feel is that a PH cannot supply HLS URL to
LMS as it is not immediately playable.

I'm not sure why you have to subclass HTTP to do remote streaming but
obviously you'll be missing out PlayHLS as it won't be subclassed.

BBC iPlayer plugin managed to do something similar to your requirements,
it has a simple iplayer:// PH and co-existing DASH and HLS PHs. (3 PHs
in one plugin) - so I need to revisit BBCiPlayer but I also have to
understand how your menus.  With BBC HLS and DASH URLs were the 
simplest form and so assumptions can be made and shortcuts taken.  The
PlayHLS plugin deals with general HLS which have more complexity.

Looking at PlanetRock site and it seems it is supplying a series of URLs
like France Radio.  Why the need for a PH for PlanetRock ?  This iswhat
I struggled at the start of this thread and still have not got to grips
with this key problem that requires a PH solution


------------------------------------------------------------------------
bpa's Profile: http://forums.slimdevices.com/member.php?userid=1806
View this thread: http://forums.slimdevices.com/showthread.php?t=114599