Re: scanUrl not being called

I'll continue on this later today and I think I may have an answer.

Paul Webster wrote: 
> I did try switching the url from https to hlsplay (see the PM from
> yesterday).
> 
> In the particular case that I am working on, there are a mixture of HLS
> and Icecast/Shoutcast streams and it is only the HLS ones that are
> causing me problems. I can (currently in my case) identify them from
> strings in the URL although that is not foolproof.
> 
> However, in the ideal world my plugin should not need to know anything
> about the type of protocol (etc) needed to play the stream. Knowing that
> the raw URLs work when no special PH is used means that at some level
> LMS can do it all itself (with assistance from genuine protocol helpers
> like PlayHLS).
The problem arises is because your PH is subclassing HTTP and so has
forced  all URLS are to be played as HTTP/AAC or HTTP/mp3 because the
"new" creates that HTTP PH object.  

You have not allowed for any non HTTP/AAC HTTP/MP3 stream to be be
processed and nor have asked LMS to determine what PH is required.

> Maybe when HLS is natively supported in LMS this problem would
> disappear.
It does now for the non PH case but for a PH needing to calli a
different class of PH - I think issue may still arise.  I think your PH 
will need to use a different Base this and not force HTTP PH handling on
all URLs.

I believe this is sort of a new LMS application as all playable URLs up
to now have HTTP streams (ie.. one GET) so these are new unseen problems
and will feed back into changes in the PlayHLS implementation (also a
DASH one as well) and maybe some LMS ones.

> Anyway - I'll continue with the experimentation.
Leave it with me for awhile.


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