HLS / .ts can't get to play

[drdr]

My Internet Radio is mplayer based and has known issues with HLS playlists. It reads the m3u8 playlist, and starts the first chunk, and doesn't do any buffering ahead... it pauses between each few second chunk. After it gets through the first chunklist, that's it.

Then, I saw Minimserver/Minimstreamer can play BBC HLS streams. I tried it against my PC with BBC and it works. When I tried it against the URL I want, it doesn't (even on my PC):

http://82.80.192.28/iba_radio-kolmusicaB...ylist.m3u8

I tried with and without transcoding.

This URL sends back another m3u8 file with a .ts chunklists. In Wireshark, I see that the PC then requests the .ts chunks from minimserver and gets no response.

Any recommendations?

Are m3u8 embedded in m3u8, requesting .ts files supported?

Thanks

[simoncn]

(15-12-2015 03:27)drdr Wrote:  My Internet Radio is mplayer based and has known issues with HLS playlists. It reads the m3u8 playlist, and starts the first chunk, and doesn't do any buffering ahead... it pauses between each few second chunk. After it gets through the first chunklist, that's it.

Then, I saw Minimserver/Minimstreamer can play BBC HLS streams. I tried it against my PC with BBC and it works. When I tried it against the URL I want, it doesn't (even on my PC):

http://82.80.192.28/iba_radio-kolmusicaB...ylist.m3u8

I tried with and without transcoding.

This URL sends back another m3u8 file with a .ts chunklists. In Wireshark, I see that the PC then requests the .ts chunks from minimserver and gets no response.

Any recommendations?

Are m3u8 embedded in m3u8, requesting .ts files supported?

Thanks

Thanks for letting me know about this. A fix for the problem is now available in MinimStreamer 0.5.21. I'm listening to the station now and enjoying the music very much!

[drdr]

(15-12-2015 09:07)simoncn Wrote:  Thanks for letting me know about this. A fix for the problem is now available in MinimStreamer 0.5.21. I'm listening to the station now and enjoying the music very much!

Great, thanks! That was quick!

Now it streams fine... But, it runs the first bunch of chunks (thankfully with no pauses between chunks) and never requests more chunks. It goes on to the next item in the file I created.

Any ideas? Did the same happen to you?

Thanks

[simoncn]

(16-12-2015 04:25)drdr Wrote:  Great, thanks! That was quick!

Now it streams fine... But, it runs the first bunch of chunks (thankfully with no pauses between chunks) and never requests more chunks. It goes on to the next item in the file I created.

Any ideas? Did the same happen to you?

Thanks

This doesn't happen to me. I have listened to the station for al least 15 minutes without any interruption.

When the station stops playing, are there any error messages in the MinimServer log?

Some players might require the data to be sent in a continuous stream because they don't have internal buffering. With a "conventional" Shoutcast stream, this happens automatically. With an HLS stream, the data is sent in "bursts" and this might be an issue for some players.

To get more information about this, you can produce a debug log as follows:

1) From the minim icon, select 'Show log'
2) In the log window, change the logging level to Debug
3) Leave the log window open
4) Start playing the stream
5) When the stream stops, click 'Save as' to save the log to a file
6) Change the logging level back to Info
7) Zip the saved log file and attach it to a post here

What internet radio are you using?

[drdr]

(16-12-2015 08:07)simoncn Wrote:  When the station stops playing, are there any error messages in the MinimServer log?
..
What internet radio are you using?

-I noticed you said to zip the logs. I tried to Remove the non-zipped logs and it won't let me.-

A) The BBCWS works just fine using MininServer/MiniMStreamer and my Internet Radio.

B) I'm using http://www.listenlive.nl/ 's third party firmware for a SkyTc based (Otek) player. It's embedded Linux and uses mplayer to actually do the streaming. RTSP/RTMP etc streams works ok. HLS streams buffer between chunks (which minimstreamer fixes) and then quits after the first list of chunks (which we're still having here). The author of the firmware says that it's an mplayer limitation (I see the non-caching of HLS mentioned, while googling).

C)

Attached I have logging from your software and then logging from the radio... maybe you can understand the interaction better. I used a different radio station from the same broadcaster, for this test.

Note that the "nop_streaming_read error : Connection reset by peer" from the radio comes MANY seconds AFTER the minimstreamer stop logging comes out. The radio stops streaming a number of seconds after that (when the buffer runs out) and then the radio gives the "Input buffer exhausted before END element found" log (I put #drdr comments at the end of the radio (otek) logs.

As in, mimimstreamer stop logging shows first, then the nop_streaming_read error on radio a bunch of seconds later, then when the buffer runs out, the radio shows "Input buffer exhausted before END element found".

Thanks!

[drdr]

Hmm... I just tried with an Android UPnP client and notice that it shows "Connection: keep-alive" vs "Connection: close" from mplayer on the radio.

I thought maybe that was the issue.

BUT - I just tried the same command line that the radio is using, on mplayer on my Raspberry Pi and I streamed for 11 minutes (when I stopped it) without a problem (as opposed to stopping after a minute consistantly). It still does a "Connnection: close" with this version. Maybe the firmware on the radio needs a newer version of mplayer. Considering this issue is seemingly only via mininstreamer, it may be difficult convincing him to upgrade.

This is what the radio is doing and what I tested on the Raspberry Pi:
mplayer -slave -input file=/tmp/mpio -af volume=-20 -vo NULL -colorkey 0x020202 -cache 1000 -cache-min 5 -cache-seek-min 90 "http://192.168.2.106:9790/minimstreamer/*/R3"

Any idea about a workaround?

By the way, I tried the original HLS URL in the mplayer on my Raspberry Pi (without minimstreamer) and that still does fail.. It reads the first few chunks from the initial playlist and exits.

Thanks!

[simoncn]

I have looked at these logs and I can see the cause of the problem.

MinimStreamer is stopping the stream because it has attempted to write data to the socket connection to the player and the player hasn't read this data from the socket connection within 2 seconds.

This 2-second timeout was added a long time ago to solve some other issues. It works OK when the network stream is a continuous flow of bytes but it can cause problems when the network stream consists of HLS packets.

It should be possible for me to implement a solution but there is no immediate fix or workaround that I can provide. The only workaround at present would be for the player to use a larger buffer so that it can read the data from the socket connection before MinimStreamer triggers its 2-second timeout.

The Connection: close or Connection: keep-alive setting is not relevant to this issue.

[drdr]

(17-12-2015 13:33)simoncn Wrote:  It should be possible for me to implement a solution but there is no immediate fix or workaround that I can provide. The only workaround at present would be for the player to use a larger buffer so that it can read the data from the socket connection before MinimStreamer triggers its 2-second timeout.

Thanks for the info! I tried the workaround and it seems to work (of course, starting streams now take quite a while). I'll use it until a fix is available.

I'm now running for 45 minutes without a problem.

Earlier, I ran it while being in and out of the room and at some time after about 30 minutes it went to the next item in the playlist.

Unfortunately, I don't have the logs. Would that be an issue with communication between the MiniMstreamer and the Internet stream, or my Internet radio? The radio was in an area which sometimes has so-so WIFI reception.

Is there a way to have it just retry the same stream, versus going on to the next one, if there is a communication error?

Thanks!

[simoncn]

(17-12-2015 18:43)drdr Wrote:  Thanks for the info! I tried the workaround and it seems to work (of course, starting streams now take quite a while). I'll use it until a fix is available.

I'm now running for 45 minutes without a problem.

I will post back here when a proper fix is available.

Quote:Earlier, I ran it while being in and out of the room and at some time after about 30 minutes it went to the next item in the playlist.

Unfortunately, I don't have the logs. Would that be an issue with communication between the MiniMstreamer and the Internet stream, or my Internet radio? The radio was in an area which sometimes has so-so WIFI reception.

It could be either. If you leave MinimServer/MinimStreamer running with the logging level set to Info, you can use 'Show log' to look at the log after this has happened and you should see a message giving more information about the cause.

Quote:Is there a way to have it just retry the same stream, versus going on to the next one, if there is a communication error?

Thanks!

MinimServer already does make a number of retries if there is a communication error with the internet stream server. It the stream stops, it means the error was unrecoverable. This would be the case for the 2-second timeout.

For an unrecoverable error, you could "program" a restart yourself by using a playlist with the same stream repeated 10 (or more) times. You would need to use a unique stream ID for each instance of the stream.

[drdr]

Quote:I will post back here when a proper fix is available.

Great, thanks.

Quote:For an unrecoverable error, you could "program" a restart yourself by using a playlist with the same stream repeated 10 (or more) times. You would need to use a unique stream ID for each instance of the stream.

Thanks.. is there a way of hiding the "extra" streams so that I don't see them when choosing which stream to play?

Thanks