Forums

Maybe someone knows where/why this is happening. When connecting with Kodi or vlc I see a connect request/established to the box (port 8001) and within 2 seconds it drops the connect, vlc immediately reconnects and starts showing the channel. (leaving the first connect in tcp/time-wait) This seems to happen all the time, its kind of irritating because this first connect (and disconnect) sometimes blocks a tuner from use until the box 'sees' its not really in use and streamproxy stops. ps. can someone enable the 'rich text editor' for me, I can't format posts properly.

Go into the Webif and ensure that the zap before stream is ticked in the web interface.

Doesn't work, the box is always in standby mode, only used for streaming.

VLC has the nasty habit of opening multiple connections at the same time and/or opening multiple connections quickly after another. Usually with streaming that doesn't have to be a problem, but for transcoding it is.

Its not vlc its streamproxy not handling aborted connections, it just sits there for 60 seconds while nothing is going in/out hugging a tuner. with ipv4.tcp settings I've got it down from 5min to 1min but realistically 5sec is enough. question remains can this be done via other sysctl settings or does streamproxy needs hacking?

I have similar issue!

I have also noticed that MPC-HC sometimes is unable to start stream with video (only audio). I have to retry few times to connect to stream correctly (with video).

 

With VLC similar issue if you have password set. Sometimes I put my password and STB doesn't accept it. I am sure its correct because I copy paste it. Here I also have to retry few times.

That's why i moved to MPC-HC because it can save password and retry them (automaticly I guess)

 

Right now I have 

Streamproxy closes the connection to the client and to the trancoder/tuner as soon as it gets the signal that the client went away. If the client leaves the connection open, nothing will happen. You can check it with netstat. Also try to start streamproxy with -f and look at the debug output. You can post it here, but remove passwords first.

> Also try to start streamproxy with -f and look at the debug output I'd love to but streamproxy only runs when streaming, running a second streamproxy -f does nothing as thats a new process, from where is streamproxy actually started so I can add -f ?

No that's not true.

Kill the running streamproxy and then start streamproxy with -f.

If your streamproxy is run from inetd, it's not the streamproxy from our feed.

When your on the box (telnet) you see no streamproxy (ps) running which is normal, start VLC http://ip:8001/1:0:1...:1:C00000:0:0:0:, after that a streamproxy process is added and running, now who's starting this process and where so I can add -f.

My et6x00 doesn't have streamproxy

I don't think an ET6x00 can transcode?

I am quite sure

But. If you own a receiver that is able to transcode, you will have the streamproxy running directly after boot. If it doesn't, it's either not OUR streamproxy or you haven't flashed your receiver for two years or more.

I guess then we are talking about different things then, but the symptoms are the same.  

Later I will try to record a video from my screen of the service on port 8001 that sometimes thinks my password is wrong and how the stream is starting with audio only in MPC-HC. 

> But. If you own a receiver that is able to transcode, you will have the streamproxy running directly after boot. If you have transcoding disabled or removed streamproxy does not start on boot but only on request. You don't need transcoding to stream.

But you don't need streamproxy to stream. I think that's your misconception. Streaming is handled by enigma itself, in enigma. Streamproxy can do it too (on other ports) but streaming on port 8001 is handled by enigma.

Ok that might be a misconception but on any image (including openpli) when you open a stream on port 8001 there is a process streamproxy running while the stream is active, as soon as the stream stops so does streamproxy. Open a VLC on your own box on any channel on 8001 and run 'ps -A -f' and see for yourself. Do a killall streamproxy and see your live stream stopping.

Then you are not running OpenPLi. On OpenPLi enigma is the only process that listens on port 8001. There cannot be two processes listening on one port. You can check it with netstat -lpnt.

Then whats the difference between inetd/streamproxy or enigma2 handling the streamdata ? (http://forums.openpl...-13#entry417776) it seems (and 'top' confirms it) enigma2 on its own(9%) is using more cpu then inetd/streamproxy(1%) via enigma2(2%) on the same test stream (ch4-hd) with the same bitrate(+-6mb).

You did not get my point. Please read again.

 

Then you are not running OpenPLi. On OpenPLi enigma is the only process that listens on port 8001. There cannot be two processes listening on one port. You can check it with netstat -lpnt.

Edited by Erik Slagter, 12 October 2015 - 18:42.