pointy56 wrote:
> 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 - I believe this is called from Control::Commands line 1549
> when it processes a 'playlist resume' command for a filetype of 'M3U'.
We sort of working on similar areas. Commands.pm is where "m3u"
playlist processing is hardcoded into using an LMS routine which PlayHLS
has indicated it will do processing - so there will be a disconnect
later.
Code:
--------------------
if ($load) {
# The user may have stopped in the middle of a
# saved playlist - resume if we can. Bug 1582
my $playlistObj = $client->currentPlaylist();
if ($playlistObj && ref($playlistObj) &&
$playlistObj->content_type =~ /^(?:ssp|m3u)$/) {
if (!defined $jumpToIndex &&
!Slim::Player::Playlist::shuffle($client)) {
$jumpToIndex =
Slim::Formats::Playlists::M3U->readCurTrackForM3U(
$client->currentPlaylist->path ); }
--------------------
So I am working on feasibility of separating m3u8 processing from m3u as
otherwise the fix may require updates to LMS which means many users
would not get benefit unless they updated.
------------------------------------------------------------------------
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
