pointy56 wrote: 
> Yes, that explains it - I had only set Debug for M3U as I was interested
> in the M3U read processing (I didn't know there was a copy of _item in
> M3UM3U8.pm that would be called from M3U).
> With logging set to Debug for M3UM3U8 as well I get the 'missing' _item
> messages - I guess that also proves that's the copy of _item that's
> being called.
> 
> Thanks for your guidance on this, I hope to spend a bit more time
> tracking down the problem tomorrow - having to manually restart the
> stream is a showstopper for me.

There is clearly some side effect in PlayHLS processing and not simply
due to the called routines. Like MP3, M3U processing is a core part of
LMS and sometime it is not treated as a replaceable playlist type (e.g.
M3U routines are sometime directly called rather than indirectly via a
playlist type lookup).

I'll look some more.  

If it is a LMS core issue, I may have to separate out m3u from m3u8
processing.  When I started PlayHLS - stations used m3u and m3u8 suffix
as if they were the same just with UTF8 support - now with HLS
established there is more rigour and it may be possible to have PlayHLS
deal with m3u8 alone and ignore m3u.


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

_______________________________________________
plugins mailing list
plugins@lists.slimdevices.com
http://lists.slimdevices.com/mailman/listinfo/plugins

Reply via email to