693 replies to this topic

[Marc83]

streaming from the 8001 on my internal network does not work any more

There are only two possible fixes:

• Download und unzip the attached streamproxy binary
• Put it into /bin on your box
• Make sure /etc/inetd.conf contains this line:

  8001			stream	tcp6 nowait root /bin/streamproxy	streamproxy

I tried this fix, but unfortunately the stream still did not open ("Could not open MRL" message).

Drop OpenPLi and use a well maintained image.

When I received my Duo2 I played around with some other images, but in my opinion Pli provides the best user experiences for the last 4 years I haven't had any problems using Pli. Hopefully the transcoding plugin will be fixed soon, fingers crossed!

[SpaceRat]

Have you tried using the cacheflush plugin... I used to have your symptoms with my Duo until I started using this, and now I don't need to reboot very often (usually each week when I update the image).

It actually reduced those symptoms quite a lot:

The issues with timeshifted TV appear to have gone entirely and those with playback from Server have turned into recoverable ones and occur after a longer uptime again (Approx 36h instead of 12h) ...

After 36h or so there are still artefacts when watching movies across the net from time to time, but playback will either recover after some seconds or I can jump back some seconds and playback continues rather than producing just another problem.

So: Thanks, that was definitely a good tip!

[SpaceRat]

8001			stream	tcp6 nowait root /bin/streamproxy	streamproxy

I tried this fix, but unfortunately the stream still did not open ("Could not open MRL" message).
Hopefully the transcoding plugin will be fixed soon, fingers crossed!

The above fix is for the normal (untranscoded) streaming ... note the port "8001" in inetd.conf.

The transcoded streaming will continue to listen on port 8002 and 8003 using Erik Slagter's streamproxy (residing in /usr/bin rather than /bin). If properly configured, there isn't a single problem with his transcoding streamproxy, at least none which isn't related to Vu+ encoder engine being faulty/unstable.

The original streamproxy for untranscoded streaming - which I provided here for convenience - and Erik's streamproxy for transcoding are in no way related to each other.

root@vuduo2:~# netstat -tulpen | grep 800
tcp        0      0 :::8001                 :::*                    LISTEN      457/inetd
tcp        0      0 :::8002                 :::*                    LISTEN      469/streamproxy
tcp        0      0 :::8003                 :::*                    LISTEN      469/streamproxy

[Marc83]

You're right Spacerat, I was using the wrong term. Transcoding (8002) is working well, but unfortunately streaming on 8001 doesn't work currently. I'll try your fix again tomorrow  and play around with some settings, hopefully I'll get it to work. Thank you for your explanation.

[SpaceRat]

Please try this on mobile

Works (Using MX Player).

[tilleke]

Please try this on mobile

Works (Using MX Player).

 

Great!

[колбаскин]

Works (Using MX Player).

 

How you install and configured???

I try how you write, and not work!

[SpaceRat]

Works (Using MX Player).

 
How you install and configured???

For the transcoding: Right from the feed, nothing special, no changes.

I try how you write, and not work!

Try from a normal PC first, preferably a Windows PC.

If it works there, it might simply be your Smartphone being nasty ...

[delavega]

streaming works on android using vu+ player without modifying anything.

 

Spacerat do you have a fix for samba freezing the box if the share isnt online anymore?

[SpaceRat]

Spacerat do you have a fix for samba freezing the box if the share isnt online anymore?

Yes

[stick50jr]

Have you tried using the cacheflush plugin... I used to have your symptoms with my Duo until I started using this, and now I don't need to reboot very often (usually each week when I update the image).

It actually reduced those symptoms quite a lot:

The issues with timeshifted TV appear to have gone entirely and those with playback from Server have turned into recoverable ones and occur after a longer uptime again (Approx 36h instead of 12h) ...

After 36h or so there are still artefacts when watching movies across the net from time to time, but playback will either recover after some seconds or I can jump back some seconds and playback continues rather than producing just another problem.

So: Thanks, that was definitely a good tip!

I'm glad it has helped a little bit.    I try to avoid timeshift as well.

Edited by stick50jr, 5 May 2014 - 08:14.

[колбаскин]

 

Works (Using MX Player).

 
How you install and configured???

 

For the transcoding: Right from the feed, nothing special, no changes.

I try how you write, and not work!

Try from a normal PC first, preferably a Windows PC.

If it works there, it might simply be your Smartphone being nasty ...

 

 

In PC work, on mobile not work.

 

root@vuduo2:~# opkg remove streamproxy
Removing package streamproxy from root...
Stopping Streamproxy: stopped /usr/bin/streamproxy (pid 434)
streamproxy.
 Removing any system startup links for streamproxy.sh ...
  /etc/rc0.d/K20streamproxy.sh
  /etc/rc1.d/K20streamproxy.sh
  /etc/rc2.d/S20streamproxy.sh
  /etc/rc3.d/S20streamproxy.sh
  /etc/rc4.d/S20streamproxy.sh
  /etc/rc5.d/S20streamproxy.sh
  /etc/rc6.d/K20streamproxy.sh
root@vuduo2:~# cat /etc/enigma2/streamproxy.conf
cat: can't open '/etc/enigma2/streamproxy.conf': No such file or directory
root@vuduo2:~# opkg install streamproxy
Installing streamproxy (1.0+git68+7f9b3ec-r3) to root...
Downloading http://downloads.pli-images.org/feeds/openpli-4/vuduo2/streamproxy_1.0+git68+7f9b3ec-r3_vuduo2.ipk.
 Removing any system startup links for streamproxy.sh ...
Configuring streamproxy.
 Adding system startup for /etc/init.d/streamproxy.sh.
Starting Streamproxy: streamproxy.
root@vuduo2:~# cat /etc/enigma2/streamproxy.conf
listen = 8002:transcode
listen = 8003:transcode
size = 480p
bitrate = 500
profile = baseline
level = 3.1
bframes = 0
root@vuduo2:~#
 

 

streaming works on android using vu+ player without modifying anything.

 

nonsense, VU+ Player not work with auth on stream.

You try old streamproxy

 

How fix for work on mobile?

Attached Files

•  work.jpg   161.07KB   38 downloads

[Erik Slagter]

I've fixed the problem with streaming not working (in the literal sense) at all if the http port was set != 80.
Once again, I probably was too late for the fix to make it into the next release (2014-04-28) but it should be in if you update on 2014-04-29 or later.

Thank you, I will update tomorrow and will let you know if this fixed my issue!

 

This issue (well, more like minor detail imho) has been fixed in the streamproxy. It will fetch the OpenWebIf listening port from the enigma config now.

 

This means no more ugly workarounds are necessary (at least on OpenPLi). The OpenWebIf doesn't have to bind to [::1]:80 or 127.0.0.1:80 if a port other than 80 is being used for the webif.

Edited by Erik Slagter, 5 May 2014 - 10:42.

[delavega]

@spacerat like this ?

 

 

# automounter configuration
Hdd            -fstype=cifs,rw,user=root,pass=openpli                ://192.168.1.102/Harddisk
Music     -fstype=cifs,ro,max=samba1\ max,samba1   ://192.168.1.64/Music
Random    -fstype=cifs,ro,max=samba1\ max,samba1   ://192.168.1.64/Random
Movies    -fstype=cifs,ro,max=samba1\ max,samba1   ://192.168.1.64/Movies
 

sorry for hijacking this thread Erik.

[SpaceRat]

Erik Slagter, on 05 May 2014 - 11:39, said:
[Authed streaming wasn't working when OpenWebif port != 80]
This issue (well, more like minor detail imho) has been fixed in the streamproxy. It will fetch the OpenWebIf listening port from the enigma config now.

This means no more ugly workarounds are necessary (at least on OpenPLi). The OpenWebIf doesn't have to bind to [::1]:80 or 127.0.0.1:80 if a port other than 80 is being used for the webif.

My personal opinion on this topic is:
There never has been any reason to have the Webif listen on any but the standard port in the first place.

The only reasons to use a non-standard port are
- the (poor) security aspect of obfuscation
and
- to allow multiple servers of the same kind on the one and only outside IPv4 address.

Obfuscation however doesn't help to make the plain-text auth of http safe enough to open it to the outside world, which is why nobody with a sane mind would ...
Inside the LAN machines use to have unique (local) IPv4 addresses, removing the use for different ports to allow multiple servers of a kind.

So actually, I could as well remove the choice for the http-port from the OpenWebif plugin entirely and I normally would, but I bet some moron would revert this or would at least start to claim that $Other_Image using a forked/older version of OpenWebif was much safer because the WebIf port can be chosen there ...

[WanWizard]

Afaik the alternate port was introduced in the early days of OpenWebIf, when the original DMM WebIf was using port 80, and this gave the opportunity to run both simultaneously.

 

I agree that it's pretty useless at the moment, so +1 from me. If only to piss off the "security specialists" out there...

[plnick]

@WanWizard

You're right, the alternate port was introduced for running both webinterface plugins at the same time.

 

And the alternate port is still in use by users who are using both plugins.

 

There was never a thought about "security" in combination with the alternate port.

 

The "security" hint was given by guy(s) using real operating systems ....

[Erik Slagter]

Whatever... Maybe someone wants to run apache at port 80. It's their choice. My message was that workaround in OpenWebIf can be removed now.

Edited by Erik Slagter, 6 May 2014 - 11:27.

[plnick]

Sorry for confusing (@Erik you was not meant by my last sentence ...)

 

There are two different things

 

a) remove forced port binding for streaming (Erik's suggestion)

b ) remove the whole config option (GUI)  for running webinterface at other ports than port 80 (post by @SpaceRat)

 

about a )

For sure, with your streamproxy and PLi based images this is worth a thought, but think about images like Vu+ original images or DMM based images which don't use your streamproxy or enigma2

 

about b )

I can not agree to this. Without this, users can not run both webinterfaces or other port 80 based software without modifying the plugin.

Erik, you made an example with apache, removing the GUI option is like removing the port configuration at apache.

 

just my 2 cents

Edited by plnick, 6 May 2014 - 12:29.

[SpaceRat]

a) remove forced port binding for streaming (Erik's suggestion)
b ) remove the whole config option (GUI)  for running webinterface at other ports than port 80 (post by @SpaceRat)
 
about a )
For sure, with your streamproxy and PLi based images this is worth a thought, but think about images like Vu+ original images or DMM based images which don't use your streamproxy or enigma2

Normal streaming auth still requires (one of the) WebInterface(s) to respond on port 80.

about b )
I can not agree to this. Without this, users can not run both webinterfaces or other port 80 based software without modifying the plugin.
Erik, you made an example with apache, removing the GUI option is like removing the port configuration at apache.

As I said, I wasn't really intending to actually do this.