bpa wrote:
> I'm a bit confused. Did the stream play OK and you heard the audio and
> it played for say 1 minute without problems ?
>
> If so, then the log is showing what happnes when you try playing a
> BBCiPlayer live stream of R4. Just to be sure - you are not in the UK.
>
>
> There is something strange happening. LMS is sending data to the
> transcode process but nothing is being received and then every sop often
> EINTR happens. I suspect EINTR is because no output from transcode
> process.
>
> >
Code:
--------------------
> >
> 15-04-21 18:53:19.4470] Slim::Player::Pipeline::sysread (310) Wrote 12631
bytes to pipeline writer
> [15-04-21 18:53:19.4476] Slim::Player::Pipeline::sysread (282) Pipeline
doesn't have pending bytes - trying to get some from source
> [15-04-21 18:53:19.4478] Slim::Player::Source::_readNextChunk (341) Got
EINTR, will try again later.
>
--------------------
> >
>
> The transcode is achieved using a program called socketwrapper which
> takes data from LMS passed it to faad, collects faad output , passes
> output to flac and then takes flac output and passes the transcoded
> audio back to LMS.
> This can be broken by some security software but if LMS was able to
> play the Groovesalad AAC stream on same player and it was oK for
> minutes, then it shows the transcode process is OK and the problem is
> specific to how plugin interacts with LMS.
The 'Got EINTR' log line is seen under normal streaming - it is from
the end of the sysread function in Triode's HLS.pm:
Code:
--------------------
# otherwise come back later - use EINTR as we don't have a file handle to put
on select
$! = EINTR;
return undef;
}
--------------------
I'm trying to fathom out the log.
There are 15 lines like 'Slim::Player::Pipeline::sysread (310) Wrote
32694 bytes to pipeline writer' in the first 3 seconds (up to time
18:53:19.8531), which add up to correct buffering of the first 5 HLS
chunks of 6.4 seconds each. All appears well and good, but I don't know
what 'pipeline writer' is - I guess they've been sent off to the
socketwrapper / faad / flac for transcoding. So I think 32 seconds of
stream data has been sent to transcoding.
Then there are these error lines where it first goes wrong, 2 seconds
later:
Code:
--------------------
[15-04-21 18:53:21.9226]
Slim::Player::StreamingController::playerOutputUnderrun (2330)
00:04:20:17:81:e5: decoder: 24067 / output: 0
[15-04-21 18:53:21.9230] Slim::Player::StreamingController::_eventAction
(271) 00:04:20:17:81:e5: OutputUnderrun in PLAYING-STREAMING ->
Slim::Player::StreamingController::_Rebuffer
[15-04-21 18:53:21.9232] Slim::Player::StreamingController::_setPlayingState
(2479) new playing state BUFFERING
[15-04-21 18:53:21.9243] Slim::Player::StreamingController::_eventAction
(303) 00:04:20:17:81:e5: OutputUnderrun - new state BUFFERING-STREAMING
--------------------
I'm guessing that means that the player itself hasn't received enough of
the transcoded stream data and has underrun. That implies to me that an
insufficient quantity of those 32 seconds worth of stream data have made
it through transcoding in socketwrapper/faad/flac and then streamed over
the network to the player to keep the player's buffer filled, after the
player has received the initial data and been told to start playing.
I can only guess that running LMS on a remote VM results in the timing
of the multiple processes involved just not working out compared to
running on a local machine. Or perhaps it is an issue with the server
version of windows. I'm not sure what to suggest now...
------------------------------------------------------------------------
utgg's Profile: http://forums.slimdevices.com/member.php?userid=40900
View this thread: http://forums.slimdevices.com/showthread.php?t=53229
_______________________________________________
plugins mailing list
[email protected]
http://lists.slimdevices.com/mailman/listinfo/plugins
