693 replies to this topic

[jpl]

Update: vu+ player app still reprts that it can't find support for the API, so changing video quality on the fly or in the settings doesn't work.

 

Does anybody know what the command would be to add support for the API - without updating the whole image, please?

[Erik Slagter]

I does say this, but in the meantime it just works, ignore it.

 

For sake of keeping the topic clean I will refrain from reacting on your points about Linux and Unix which are obviously only supported by your own misinformation, which is often the case with Microsoft adepts.

[SpaceRat]

5. Ran "netstat -p tcp -a -n" and noticed that the process inetd was listening on port 8002, not streamproxy

That should have told you that something else went wrong before.

inetd isn't supposed to listen on port 8002 on OpenPLi, because the streamproxy is started as a stand-alone daemon.
I wonder how you managed to get it borked like that in the first place, because streamproxy has all the original transcoding proxies in its conflicts list and will remove them.


The following steps just describe how to bork it even more, because now you got two incompatible transcoders installed at the same time.

To put it into some picture:
You drove your car against a wall and now you can hear the metal scratch on the road while driving ... but instead of repairing the damage, you mount larger wheels, hoping the bent metal doesn't get ground contact anymore.
That works so far, but now you can smell the rubber of the tires, because the larger wheels don't fit inside the wheelcase anymore ...


BTW: Removing the line for port 8002 from /etc/inetd.conf and re-configuring erik slagter's streamproxy to use port 8002 again might lower the pain ...
But there can't be any simple advice for reverting your system to a truely clean state, because it must have been brought into its current state using brute force and we do not know what kind of force.
For proper repair, we would need to know how you managed to break it in the first place and only you can know that.

It is impossible to still have an inetd.conf listener on port 8002 if your transcoding was installed/upgraded the normal way.

[Erik Slagter]

BTW the simplest way to resolve this half-inbetween-condition the receiver has come into, is to make a backup, flash a new image and restore the backup.

This has been explained in various other topics.

[jpl]

Sorry, but I did find the reason for inetd listening and occupying port 8002. It was in inetd.conf (don't you just like Lunix and Unix with conf files all over the place! compare that to the Windows registry which is so simple in comparison) but didn't bother to post it. Here is the offender:

 

"8002 stream tcp nowait root /usr/bin/transtreamproxy transtreamproxy"

 

Commented out with a #, reboot and one can use 8002 for the streamproxy process, or any other free port, at will.

 

Eric, if I had an IT technician, even suggesting to solve every problem by wiping everything all the time, instead of doing real troubleshooting - and solving the problem, I would fire him faster than you can say "get out of here". Reflashing/reinstalling or whatever, did you learn anything? BTW, if you even paid half an ear of your precious time, I started this post by saying that I DID just that! With a fresh image, latest build!

 

Jeez...Linux boffins...'nuff said...

[jpl]

And now everything is working just fine, the way I want it to work. With the "Great Help of the Linux community"...give me a friggin break...

[Erik Slagter]

JPL I would happily explain all steps how to get to a working situation and also how the package system would have gotten into this inconsistant state, but I have learned that most users really don't want that, they just want to have a working situation, with little effort in little time.

 

As you've shown you have no interest in learning anything from anything other than Windows, I have assumed your preference would be the same.

[jpl]

As you've shown you have no interest in learning anything from anything other than Windows, I have assumed your preference would be the same.

 

Wrong, my friend, on two accounts: Firstly, I don't need to learn anything about Windows. Secondly, the Linux "community" attitude means I have to learn what is required on my own. Which I will. 

 

So thanks for your "kind" offer, but don't bother. If you could learn, it means I can learn it also, only 10 times better!

 

BTW: It wasn't me who launched the derogative comments on Linux, it was SpaceRat...not that it matters. Linux community has again opened it so warm and welcoming bosom in all matters! 

[lfc84]

 

pieterg has just pushed a commit that makes the internal streamserver (port 8001, streaming-no-transcoding), for authentication, configurable, indepedent of the open web interface, because it has no relation with the open web interface.

 

This means, from tomorrow on, that if you want authentication on plain streaming, you should set the option "Require authentication for http streams" inside the enigma settings for streaming (it's between the other streaming options, like "Descramble http streams" etc.

commit 5d6c607bf2f2c3feb7d5213be57a65ac539e8b4a
Author: pieterg <pieterg@users.sourceforge.net>
Date:   Thu May 15 17:40:36 2014 +0200
    streamserver: use internal setting for authentication
   
    the streamserver should not depend on the webinterface,
    so introduce our own setting, instead of checking an
    external openwebif setting.

 

I realise this is an openpli forum but I am running openvix and I cannot find an answer to my question.

 

I have enabled the above functionality so that streams on port 8001 are authenticated. However when I use the root credentials the authentication fails.

 

Is this issue specific to openvix?  Do I need to create a new user for the http port 8001 stream ?

[hemertje]

Ask at openvix forum

[SpaceRat]

The error is actually inside that old PLi commit:

The authentication against the internal streaming oftenly fails, it will succeed after 2, 3, 4, 5, 6, ... 20 retries with the amount of retries depending on the phase of the moon only.

 

oe-a images like ViX however should have the proper Dream-style streamproxy on their feed, so it can be installed using

opkg install streamproxy

 

This will fix this issue, however it makes it impossible to exchange EPG between boxes using http streams.

IMHO exchanging EPG using streams is far less widely used than streaming auth though.

[athoik]

The authentication against the internal streaming oftenly fails, it will succeed after 2, 3, 4, 5, 6, ... 20 retries with the amount of retries depending on the phase of the moon only.

Can you reproduce a failure? What are the steps to reproduce?

I guess providing that information could help developers to solve any problem exist.

[SpaceRat]

As I said, it's really "depending on the phase of the moon only".

 

Sometimes it will succeed on the first attempt, but in many cases it won't.

 

Sorry, but I can't give any more details, if it was easy to reproduce it would probably be easy to fix too and then I would have done that myself already

I guess it's something timing related, e.g. the browser sending the credentials after E2 has already decided it didn't get credentials ...

[lfc84]

Thankyou for the constructive comments. I haven't had an opportunity to reinstall streamproxy yet but i will try it out. I apprecaite the suggestion.

 

This thread seems to have some real expertise.