Couple of issues with 1.33

[Keyser]

Hi.

 

I love the starting support for reverse proxy'ing as this allows me to stream outside my house.

 

I have however discovered a few glitches so far:

 

1: The RSTweak settings does not include a dialog for setting the "Reverse Proxy URL" (Outside URL) as stated in the release notes for 1.33. It does include the "Reverse Proxy IP" dialog.

Since i cannot add the needed additional "X-Forwarded-xxxx" in my reverse proxy, I may need this setting. (I can add X-Forwarded-For header)

 

2: Reverse proxy'ing works excellently even though I don't think I have the additional headers. I can watch live TV in a browser from the internet now. BUT:

I cannot use the streaming feature of the /IOS interface. When starting a HLS stream on IOS the page comes up, but no video appears in the client window (neither in a browser nor in the Rec. Service APP). FFMPEG starts very breifly on the server and then stops again. Why does this not work when webbrowser streaming does?

 

3: Lately (this was also an issue in 1.32) HLS streaming has been rather flaky in my RS. Even on the inside the stream starts and runs for perhaps a minute, sometimes several minuttes, sometimes half an hour, but eventually it will stop/freeze, and shortly thereafter the FFMPEG proces stops on my server. Mostly the stop comes after about a minute, but not always. I can easily restart the stream, but it will stop again like before.

 

All I need for RS to be perfect for me now, is stable HLS streaming, and HLS streaming working from the outside through the reverse proxy (as browser streaming already does).

 

Thank you very much for your efforts and the excellent work you are doing.

 

-Keyser

[Griga]

1: http://www.DVBViewer.tv/forum/topic/58316-rs-133-reverse-proxy-and-m3u-stream-ip-address/?p=447534

[Keyser]

Okay that was a fast answer :-)

 

The new INI file provided me with the "Reverse Proxy URL" setting and that definately made a difference :-)

 

I can now start a HLS stream from the outside as well, so things are really shaping up !!! YAAAYYYHHH

 

Regarding the intermitted freezing of a HLS stream i'm still testing. I disabled authentication on the inside, and that currently seems to have made it stable from the Rec. Service APP. and /IOS interface.

Mind you, I did have to delete the APP and install it again to clear it's cache. It was starting to act weird.... But it also seems stable on my other devices where I haven't reinstalled yet, so it's not the reinstall.

 

I will do some serious testing from both the inside and Outside, but this is REALLY starting to look good.

 

Thanks Guys

[Keyser]

Well right now it seems very stable. I'm REALLY REALLY happy with this. the Rec. Service APP is just so sweet this way :-)

 

I'll keep you posted if the HLS stream freezing returns (or other issues are discovered).

 

For any interested users: I'm using a PFsense Firewall with HAproxy as a reverse proxy. It's listening and running externally on SSL and forwarding to the regular HTTP protocol on the inside. Works beautifully.

 

What a sweet day :-)

[Griga]

Congratulations that you made it work.

 

I cannot use the streaming feature of the /IOS interface. When starting a HLS stream on IOS the page comes up, but no video appears in the client window (neither in a browser nor in the Rec. Service APP). FFMPEG starts very breifly on the server and then stops again. Why does this not work when webbrowser streaming does?

 

In a nutshell: The RS tries to do something HLS is not designed for: HLS on demand. The culprit is HLS being a segmented stream, in contrast to Flash or WebM.

 

On the other side Safari / the iOS player is the most touchy HLS client you can think of. It was extremely difficult to make it work at all, even without a reverse proxy in between.

 

Usually servers provide HLS permanently, not on demand. When the client request arrives everything is already set up, running and available, so the client can get immediately what it needs to start streaming and playback (aside from network delays): The master playlist, the media playlist referenced in the master playlist, the TS segments referenced in the media playlist...

 

However, apparently the RS can't keep HLS for 100 channels up and running all the time. It starts transcoding and producing TS segments "just in time" when the request arrives. So clients have to deal with unexpected long response times. Some don't like that at all (see above). Every additional buffering / delay in between may tip the balance.

 

HLS servers typically provide at least 3 already completed segments with 10 seconds duration each, so the client can read and buffer up to 30 seconds ahead. But you would not like to wait 30 seconds and more on every channel change until playback starts, would you? Besides that such a response delay would exceed the timeouts of most clients / players.

 

That's why the RS reduces it to 3 segments with 2 seconds duration each by default. Already a bit narrow The absolute minimum are 2 one-second-segments as we have found out. Otherwise you'll get drop-outs even with very tolerant clients / players.

 

For special purpose the RS API allows to set up permanent HLS streams independently from client requests (see here, search for starthls), enabling to configure more and longer segments that the client can read ahead. But that can't be used for zapping, of course. It may be suitable if there are only very few channels that you want to make available all the time without delay (provided the server CPU is powerful enough to transcode them all permanently and simultaneously, and you have enough money to pay the electricity bill).

 

For more information about transcoding and HLS parameters (particularly seg and segdur) please refer to the file transcoding_params_en.txt in the Docs directory of your RS installation.