> I'll need to look at this in more detail when I have time.
It would be appreciated, thanks in advance.
If I could be of any "help", let me know.
> However, remember TCP level communication is at the OS level. LMS does
> not send RST - just open and close.
I'll need to look at this in more detail when I have time. However,
remember TCP level communication is at the OS level. LMS does not send
RST - just open and close. RST are as a result of timeouts at TCP level
and implemented at driver level. Since your test system is WIndows based
> More investigation is needed.
I tried to compare the behavior with the playback of a remote file from
the audio archive of Slovak Radio (RTVS). LMS plays back these files
without any problem and they are served by the webserver through
HTTP/1.1 as well, see the curl logs (on the
> Hello bpa,
> if I use ffmpeg with -reconnect option, playback of the remote file
> isn't terminated after elapsing of the first ~10MB segment, see my
> previous post(s). This is why I use it (ffmpeg -reconnect command) in
> transcoding option in the LMS (for the FLAC stream
> I think this is the same as what happens with LMS - by using the pipe to
> ffplay you are slowing the flow down and so the czech music server break
> the connection.
if I use ffmpeg with -reconnect option, playback of the remote file
isn't terminated after elapsing of
> I also checked playback on my work PC connected via ethernet to other
> network and it behaves exactly in the same way. I just noticed the
> following error message in the ffmpeg log which doesn't appear in the
> logs from ffmpeg on my home ntb (this is just due to different
Hello Michael, bpa,
thanks for your replies and effort to help.
> Could you please see what happens without your ffmpeg transcoding and
> debug logging for player.streaming.remote enabled? What does the
> server.log say then?
Please find attached the requested log without
Using wireshark to see what happens when LMS issues GET for the mp3
The log shows the following
[18-04-11 15:11:21.1358] Slim::Networking::Async::connect (108) Connecting to
The ffmpeg log show using http 1.1 - does it use the same TCP
connection used for mulitple GETs - LMS only support HTTP 1.0 - I
wonder if there is different behaviour if connection is made with HTTP
This use of partial content - looks like a poor man's chunked http
Thank you very much for this detailed analysis. I might need to look
into supporting the partial content streams.
http://www.herger.net/slim-plugins - Spotty, MusicArtistInfo
I doubt there's a generic problem playing static mp3 files: it's what
most podcasts and streaming services (Pandora, Deezer, Tidal,
Bandcamp...) do. So, rather than playing with custom-convert I'd suggest
you double check you theory by installing 7.7.6 on a computer, then
7.9.1. On the same
Mail list logo