693 replies to this topic

[SpaceRat]

We simply used it pending a better solution and more generic solution, which is correctly worked on by Erik. NO other image uses the streamproxy binary, in all other platforms port 8001 is serviced by the Enigma binary.

As usual, the truth is just the opposite:

The /usr/bin/streamproxy (Sometimes at other locations, as usual in *ix) was not made by Vu+, it has "always" been there (Since 2007 or so).
It has nothing to do with Vu+ either, it exists on any box, unless it is 1:1 based on OpenPLi. Any image which doesn't blindly merge anything by OpenPLi still has it.

You are confusing it with Vu+'s transstreamproxy and transfileproxy binaries.

There are three options:

• You can be happy that I found this difference in setup on a different box with an E2 image that's not just a recompilate of OpenPLi and thus located the bug and revert the removal of streamproxy.
• You can accept that the original streamproxy binary actually wasn't obsolute, just like in option one, and re-implement its functionality elsewhere.
• You can also close your eyes and ears to the reality, hum a melody and continue to claim that OpenPLi is bug-free ...

[SpaceRat]

Already explained ....

You try this himself?
If put your bin file - work just 8001 port
if update from receiver - work just 8002 port
 
need run both ports!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

If you need both, do both:
Update the box to the latest transoding ipks for the transcoding to work and put the /usr/bin/streamproxy onto the box and into inetd.conf to make the plain streaming work.

Both parts are absolutely seperate things.

Normal streaming auth in OpenPLi has been fucked up since 2011! (Link to a notice about the faulty commit)

This thread and the reason that I helped switching some other image to OpenWebif was just the occasion to locate this bug but it is in no way related to transcoding.


PS:
Argls, I think I found your problem.
Erik was so clever to call the transcoding stream proxy just "streamproxy" and put it into the same directory /usr/bin, just like the old one ...
So you can't have both if you strictly follow the instructions.

Well:

Copy the original streamproxy (Attached again) to
/bin
and make the 8001 line in inetd.conf read
8001 stream tcp6 nowait root /bin/streamproxy streamproxy

After that you might need to uninstall and reinstall the transcoding ipks again (See link at the beginning of my posting) to replace the streamproxy in /usr/bin with the transcoding streamproxy again.

Then both will work.

@Erik:
How about renaming the transcoding proxy to transproxy?
I know meaningful file names are considered bad design on *ix, but maybe you could make an exception ;>

Attached Files

•  streamproxy.zip   4.59KB   5 downloads

[WanWizard]

@SpaceRat,

 

I don't care what's on other boxes, with other images, with other history. You are here at the OpenPLi forum, and we're discussing OpenPLi here.

 

And in OpenPLi, the streamproxy was removed from the image quite some time ago, and it's functionality is handled by Enigma internally.

 

Then VU+ came with transcoding and decided to modify the streamproxy to implement that (maybe logical since they use an old DMM fork), so we had to disable the Enigma functionality and go back to the streamproxy to make transcoding work. Which is a solution we don't like, and doesn't work very well with our desire for clean and proper solutions. So we decided to rework the entire transcoding proxy, which is what Erik was doing.

 

The only problem is that when he enabled the new code in the image and removed the streamproxy, he forgot? to re-enable the built-in streaming in Enigma, which is why you don't have anything listening on port 8001. And which is why attempting (or demanding?) to re-instate the streamproxy is a dumb idea, and it's not going to happen. It's a bad solution, it's lousy programming, and it's not needed.

[WanWizard]

From what I have been told nothing is even disabled in Enigma.

 

As soon as you define port 8001 in your inetd.conf, it is in use, and the stream handler in Enigma is disabled.

So you should not have any reference to 8001 in your inetd.conf, and after a reboot you should have

Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
tcp        0      0 0.0.0.0:8001            0.0.0.0:*               LISTEN      9256/enigma2

 

You should NOT have the old streamproxy binary on your box, and you should NOT define it yourself in your inetd.conf !

 

If there is a problem with the functionality of this, then that has to be addressed. And not worked around.

[SpaceRat]

I don't care what's on other boxes, with other images, with other history. You are here at the OpenPLi forum, and we're discussing OpenPLi here.

Exactly.
That's why I have to explain how to work around OpenPLi specific bugs.
If we were on the forum for another image/box, I wouldn't have to explain, because they didn't broke it in the first place.

And in OpenPLi, the streamproxy was removed from the image quite some time ago, and it's functionality is handled by Enigma internally.

The first part of your statement is true but not the second.
The functionality of the original /usr/bin/streamproxy was just removed.


 

Then VU+ came with transcoding and decided to modify the streamproxy to implement that (maybe logical since they use an old DMM fork), so we had to disable the Enigma functionality and go back to the streamproxy to make transcoding work.

"Bullshit" is the nice expression for this.
They created independent binaries for transcoding, they were just used in a similar way to the original pass-through streamproxy. Nothing would have been needed to be altered in Enigma2, neither was it.

rework the entire transcoding proxy, which is what Erik was doing.

Finally something that's really true.
Yes, Erik has reworked the transcoding proxy and it actually works in its current version.
However, his transcoding proxy has nothing in common with the original pass-through stream proxy used in any working E2 environment ... well, except of the filename

 

The only problem is that when he enabled the new code in the image and removed the streamproxy, he forgot? to re-enable the built-in streaming in Enigma, which is why you don't have anything listening on port 8001.

Do you ever think before you write?

Erik didn't remove the pass-through streamproxy, he wouldn't even have been able to do that, because it was already gone before.
The E2 streaming on port 8001 on the other hand had never been gone and thus E2 has of course still listened on port 8001.

Erik's trancoding stream proxy works nicely and also respects stream auth if enabled. He has not broken or taken away anything (at least not in the end).

The only thing missing in OpenPLi is the original streamproxy and its only purpose is to pass the streaming request through webif auth before handing it over to E2.
It's not a replacement for E2's built-in streaming, it's just a piggy-packed auth engine.
When OpenPLi/pieterg removed the original streamproxy in 2011, you/he just removed the auth capability, without providing a replacement.

How many OpenPLi devs do you need to replace a bulb?
None: They just define darkness a new standard.

Edited by SpaceRat, 28 April 2014 - 18:33.

[WanWizard]

Why don't you read before replying.

 

I already corrected myself. It was removed before, and auth doesn't seem to work anymore. I am not debating that. If something is broken, fine, then it must be fixed.

If there is something we as a team decide to remove, it's not broken, it's how we want to have it. I'm not pieterg, so I can't comment for him, but if that is the case, then I suggest you live with it. However, from what I understand it is being looked at, so I expect a solution in the near future.

 

And the original streamproxy isn't missing. We removed it for a purpose, and it is NOT coming back. We also do not implement workarounds.

[malakudi]

@SpaceRat: Replying with such language will not help you. Expressions like "bullshif" etc cannot make other people try to understand and help you.

 

@WanWizard: The "problem" is that the enigma2 internal web server on port 8001 does not support simple http auth request. So, SpaceRat and others complain because original streamproxy was removed by something inferior in their opinion - since it does not provide http basic auth support. If we would implement http basic auth on the internal web server, it would be OK.

 

In my opinion http basic auth is useless. If you want security, setup a tunnel with your box. openvpn, ssh tunnel, whatever. http basic auth is no security.

[колбаскин]

Then both will work.

after reboot not work

 

1. /bin/streamproxy - md5: 4FBF924E6C27F8644B2EDA83E2BFC2FC

2. inetd.conf 8001 stream tcp6 nowait root /bin/streamproxy streamproxy

3. root@vuduo2:~# opkg remove streamproxy

4. root@vuduo2:~# opkg install streamproxy
Installing streamproxy (1.0+git57+4431cce-r3) to root...
Downloading http://downloads.pli...-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.
 

work just 8002 with auth

 

streamproxy.sh

PATH=/sbin:/bin:/usr/sbin:/usr/bin
DAEMON=/usr/bin/streamproxy
NAME=streamproxy
DESC="Streamproxy"
 

 

what need to do?

[WanWizard]

@malakudi,

 

Totally agreed.

 

And as said, it being looked at.

 

Altough there isn't a hair on my head that would consider putting the box on the internet (in any way or form), I would like to keep my pre-teen son from the "meat-channels", so there is no debate whether or not auth is handy...

[SpaceRat]

@SpaceRat: Replying with such language will not help you. Expressions like "bullshif" etc cannot make other people try to understand and help you.

The point being that it's not me who needs help ...

 

@WanWizard: The "problem" is that the enigma2 internal web server on port 8001 does not support simple http auth request. So, SpaceRat and others complain because original streamproxy was removed by something inferior in their opinion - since it does not provide http basic auth support. If we would implement http basic auth on the internal web server, it would be OK.

Not really.
It was a good design the way it was.
Sadly some people manage to understand the concept of an E2 box even less than I do:

If you implement http auth inside E2 itself, you violate the whole idea of plugins/modularity etc.
"streamproxy" was added to E2 in the process of a adding a web interface, because in conjunction with a web interface, http auth actually makes sense.
However, at the moment you still have the choice if you want a web interface at all and which ...

Implementing http auth in E2 itself would tie E2 to the presence of a web interface (If it uses "en passant" auth through webif) or render the port 8001 "simple stream" useless for any other potential use, at least it would require yet another setting in E2 itself to enable/disable http auth for port 8001 (Or E2 itself would need to be tied to plugin settings ...).

A worse design decision can not be made!

In the very same moment you implement the http auth inside E2 itself, you would have to implement the whole web interface inside E2 as well to avoid a mess of conflicts.

 

In my opinion http basic auth is useless. If you want security, setup a tunnel with your box. openvpn, ssh tunnel, whatever. http basic auth is no security.

WanWizard hasn't said much useful in this thread, but I have to agree on his point:
http basic auth should be enough inside the LAN to keep children from watching propaganda or RTL.

And for the same reason, finally adding at least basic security - for example for the cifs server - should have higher priority than trying harder and harder in order to find things one can break.

People here keep playing the same record of an E2 box not belonging opened to the net at all, but didn't realize one of the biggest mistakes in security tales ever: The LAN isn't necessarily a safe place anymore.

[колбаскин]

Stream with transcoding work on PC  - VLC player, when open 2th time

Not work in mobile with all players

[qnopli]

Hi,

 

I recently discovered that it isn't possible anymore to select an different audio channel (language) for transcoded streams (e.g. in VLC player). For streamed TV channels the default language is german (for german stations of course) which is fine for me, but for recorded transcoded movies it is per default only english (for multiple broadcasted languages, audio channels). Is there a way to configure something on the box itself? I've had already read something about this problem in this thread - so what is the current status of this problem?

Edited by qnopli, 29 April 2014 - 12:31.

[qnopli]

Hi,

 

I recently discovered that it isn't possible anymore to select an different audio channel (language) for transcoded streams (e.g. in VLC player). For streamed TV channels the default language is german (for german stations of course) which is fine for me, but for recorded transcoded movies it is per default only english (for multiple broadcasted languages, audio channels). Is there a way to configure something on the box itself? I've had already read something about this problem in this thread - so what is the current status of this problem?

 

I've just tried streaming a recorded movie with the Vu+ Player Android app - and audio channel is OK (in german) for this app but isn't also be selectable anymore.  

[Marc83]

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 has indeed fixed it, thank you once again!

 

I also tried to change some settings in etc/enigma2/streamproxy.conf but these don't seem to be picked up. Any idea how to fix this? I read some setting may crash your box, but I want to play around with it a bit to see if improves the streaming on my Duo2.

[delavega]

Youtube tv is gone?

 

whats going on?

[Erik Slagter]

@SpaceRat: Replying with such language will not help you. Expressions like "bullshit" etc cannot make other people try to understand and help you.

 

@WanWizard: The "problem" is that the enigma2 internal web server on port 8001 does not support simple http auth request. So, SpaceRat and others complain because original streamproxy was removed by something inferior in their opinion - since it does not provide http basic auth support. If we would implement http basic auth on the internal web server, it would be OK.

 

In my opinion http basic auth is useless. If you want security, setup a tunnel with your box. openvpn, ssh tunnel, whatever. http basic auth is no security.

Exactly the hammer on the nail, like we say in NL, 100% +1'ed. Whether the internal proxy supports basic auth or it doesn't isn't relevant. It's not safe to expose the streaming ports to the outside with or without, period.

 

To second that, I have proof from my logs that hackers are trying to crack my (necessarily exposed) voip port every second (or more). Almost any password can be cracked that way. A computer is patient. Basic http auth won't help you.

[Erik Slagter]

Youtube tv is gone?

 

whats going on?

Since when?

 

I have updated the HbbTV plugin (1:1 from VU+) a few days ago (haven't had the opportunity to check yet), but I've seen reports it's broken now. Thank VU+. The youtube TV player also uses the HbbTV browser, so that would explain a lot

 

I'll have a look shortly. If you start the browser manually (see other thread about this), it does work, so it looks like it's "fixable".

[Erik Slagter]

I recently discovered that it isn't possible anymore to select an different audio channel (language) for transcoded streams (e.g. in VLC player). For streamed TV channels the default language is german (for german stations of course) which is fine for me, but for recorded transcoded movies it is per default only english (for multiple broadcasted languages, audio channels). Is there a way to configure something on the box itself? I've had already read something about this problem in this thread - so what is the current status of this problem?

Status is unfixable. Not this way anyway. Only one audio channel can be transcoded, so it must be selected beforehand. Currently there is no way to inform the streamproxy what audio channel to use. See also the discussion about this a few pages back. There is no easy way to have the user select the audio channel. The algorithm used now is to prefer ac3 channels and to ignore "narrative" channels.

 

One of the problem is that streamproxy does not know what you selected in enigma. Also, even if it did, it wouldn't work for recording, only live TV.

 

I might think of something some day, though.

[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 has indeed fixed it, thank you once again!

 

I also tried to change some settings in etc/enigma2/streamproxy.conf but these don't seem to be picked up. Any idea how to fix this? I read some setting may crash your box, but I want to play around with it a bit to see if improves the streaming on my Duo2.

To re-read the settings: /etc/init.d/streamproxy stop; /etc/init.d/streamproxy start

Good remark, I might add a better method, like monitoring the config file for changes, that's not that hard.

 

The webif listening on an alternate port (not 80) should be handled by the streamproxy and not the webif, imho. I will add some code the fetch the port number from the enigma config and then it's fixed properly. Although I don't understand why not to use 80, anyway.

[delavega]

yes its totally broken