bpa wrote: > 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.
If you look at the log I uploaded yesterday you will see that there is an additional log entry in the test that I ran without PlayHLS: [22-04-11 16:51:28.0569] Slim::Formats::Playlists::M3U::readCurTrackForM3U (203) Found track: 0 This seems to tie in with what you are saying about the core M3U processing - this seems to be called from Control::Commands line 1549 when it processes a 'playlist resume' command for a filetype of 'M3U'. ------------------------------------------------------------------------ pointy56's Profile: http://forums.slimdevices.com/member.php?userid=72509 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
