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