693 replies to this topic

[SpaceRat]

But the web/about-api is part of the OpenWebIF, you'd have to discuss that with SpaceRat.

I neither wrote nor "own" OpenWebif, I've just made some contributions in the past.

The OpenWebif is now used on a myriad of boxes and images and if OpenPLi would need major OpenPLi-specific changes inside it, it would in the end become unavoidable to create a fork, which I would not appreciate.
And while a fork would make it possible to get the OWIF to work with OpenPLi changes, it would likely break apps that are already there.

Re-creating consistency between OIWF and a special OpenPLi-Enigma by making OWIF match the OpenPLi Sonderweg is definitely not a good choice.
This is especially true if the public reception of the Sonderweg is that of an OpenPLi-only bug ... not an OpenPLi-only feature ...


That's also why I keep asking about IPv6-Support on port 8001:
Images with a seperated streamproxy in inetd have it (HDMU) or can easily implement it by adding 1 char to inetd.conf

Erik keeps recommending using port 8002 instead which I made clear is not an option, as port 8002 doesn't natively exist on non-transcoding boxes. It would require OpenPLi and transcoding enabled boxes specific changes to OWIF (and still would not fix those boxes without transcoding).


BTW
To some degree I have to agree to our Russian friend:
There are plenty of problems or limitations in Enigma2 and OpenPLi and sometimes you might think that OpenPLi-devs tend to prefer playing around with something "new" - possible breaking working things at least during the phase of playing - instead of fixing something.

Erik, I know it might be boring you, but while re-writing socket creator classes from IPv4-only to Dual Stack/portable code might offer less of a thrill than creating something "entirely new", as someone who tries hard to help all those people already "suffering" from DS-lite lines, I simply can not understand why comparably tiny fixes get delayed again and again while working parts get rewritten over and over.

Please, please, please concentrate on fixes first. If almost anything works, people will have more understanding for the creation of new construction sites in order to enhance things.

One last thought:
"One wrong-way driver? Hundreds!" (After a warning on the radio that there was a wrong-way driver on highway $X) is a German saying to describe someone doing something wrong but believing all others do it wrong. So in his eyes it's not (just) him driving on the wrong side/into the wrong direction but all others (except him).

So if no other image group merged the superior streamproxy enhancements yet, chances are they aren't enhancements, let alone superior ...

Edited by SpaceRat, 26 April 2014 - 14:00.

[SpaceRat]

Well, I have to add yet another point:

You (meaning all devs) keep saying that OpenPLi 4.0 is beta and thus a constant flow with possible breaks ...
But then, what's the stable version?

As a matter of fact, the current trunk has always been the only usable path, as older versions never receive any fixes.

How about doing something which is completely new to the *ix world:
A code maturity phase

Revise existing code, would you write it the same way with what you know today?
Close bleeding edges, things that never really worked but never got fixed.
Find the blind ways went for too long: Where are you still working around bad design decisions of the past?

Usability lab:
Compare an E2 box to a good "ready-to-use" set-top-box. Where is E2 still falling back?
And yes, it is. E2 offers a lot ... but still is a PITA in many other points.
One of the major points are plugins. There is way too much basic functionality done by plugins rather than the core.

Next point being them not true plugins but addons: Using plugins, you get settings cluttered all through the interface. There is a settings menu which doesn't contain all the settings because the get hidden under the plugins menu ... but they aren't plugINs if they don't plug IN but hook anywhere.

[Erik Slagter]

SpaceRat, although I do agree with some (!) of your comments, I don't like your tone. We all do this in our spare time, it's supposed to be fun to some extend. We're getting nowhere but demotivated if we're going to call each other names like this. I am certainly open to suggestions but not like this.

[Rob van der Does]

 

 

No this one 

https://play.google.com/store/apps/details?id=com.vuplus.vuplusplayer

 

I was talking about the App from tilleke, not VU+.

 

Yes, that's the one made by Tilleke (Android dreamer as well, but that's not been maintained for a long time).

 

Now I am confused...

Well, tell us what confused you so we can help you out.

[Erik Slagter]

It's clear now. Tilleke appears to be the author of the VU+ App as well.

[SpaceRat]

SpaceRat, although I do agree with some (!) of your comments, I don't like your tone.

I really can't help you if you already feel offended by an objective list of facts.

We all do this in our spare time, it's supposed to be fun to some extend.

Sure and that's exactly my point.
I've come to a point where I feel as if nothing gets fixed unless I do it ... with the big problem that there is way too much I can't do, making me feel helpless.

I'm confronted with an expensive hardware which can tell me on the TV who's calling, show me the weather in Timbuktu, connect to Facebook but won't play back a recording or a timeshifted broadcast without glitches if I do not reboot it twice a day, decides to keep or forget the EPG on reboot by pure chance, becomes unconnectable if I ever change my ISP, doesn't even allow the slighest level of security for its network shares, needs 100% manual setup of network shares, ...

OpenPLi 4.0 needs a properly recompiled Samba so that at least basic security works (I managed to do this for sh4 myself, but not for mips), it needs mounting network shares switched to autofs to actually work reliable, it needs a fixed autofs startup script to make autofs come up at all, ...

Where is the fun supposed to come from when I do my daily opkg update && opkg upgrade and there are only cosmetic changes and 12h later I have to reboot that pile of &%§$ again so that I can watch TV without artefacts?

I appreciate your work and effort, but guess how much more motivation it would give to you if you would start fixing the ugly bugs first and everybody cheers "Finally $feature is really working!" instead of starting with things that you simply deemed badly coded?

Its quite normal that nobody wants to do the ugly work of hunting down the nasty bugs deep inside but instead code something more prominent ... but the more I would appreciate if someone did it ...

And believe me: I know it wasn't you who borked "it". But someone who's better than me plus the guy who originally borked it has to come and fix "it" ...

[delavega]

"OpenPLi 4.0 needs a properly recompiled Samba so that at least basic security works (I managed to do this for sh4 myself, but not for mips), it needs mounting network shares switched to autofs to actually work reliable, it needs a fixed autofs startup script to make autofs come up at all, ..."

 

Couldnt agree more on that.

[malakudi]

@SpaceRat: I don't know why your box has to be rebooted every 2nd day. Mine doesn't.

root@vusolo2:~# uptime

 00:10:10 up 50 days,  6:10,  1 user,  load average: 0.30, 0.26, 0.29

 

root@et4x00:~# uptime

 00:12:11 up 36 days,  1:54,  1 user,  load average: 0.58, 0.31, 0.28

 

Boxes are used for recording, timeshifting, media playback (from NFS - maybe your issue is samba?), streaming, transcoding (on VU+ Solo2) etc etc.

 

[SpaceRat]

@SpaceRat: I don't know why your box has to be rebooted every 2nd day. Mine doesn't.
root@vusolo2

Mine is the older ultimo:
Much less CPU power, much less RAM.

I know for sure that the Duo² works much better than the older Ultimo.
If it wasn't that worthless on eBay, I would have sold the Ultimo long ago ... on the other hand ... if it wasn't such a pile of junk, it probably wouldn't be that worthless anymore ...

And: Every 2nd day isn't enough, I reboot it twice a day (If there aren't green screens making that more times ...).

[malakudi]

@SpaceRat: Mine is Solo2, not Duo2. But the other box is ET4000 which isn't really powerfull. VU+ Ultimo is a powerfull box, same as ET9X00 and DM7020HD. It still shouldn't have those problems you are mentioning.

[Rob van der Does]

root@Ultimo:~# uptime

 06:21:10 up 21 days, 14:06,  1 user,  load average: 0.22, 0.19, 0.14

[SpaceRat]

root@Ultimo:~# uptime

 06:21:10 up 21 days, 14:06,  1 user,  load average: 0.22, 0.19, 0.14

In use or just sitting there, doing nothing?

Can you please send me the output of
"opkg list_installed"
by PN?

BTW: Since day one, I have already replaced the "original" Samsung Desktop-HDD with a Western Digital AV-optimized harddisk, added a third tuner, moved that new third tuner to tuner slot B when I later replaced the third tuner with a twin-tuner, tried ext2, ext3, ext4, xfs file systems, tried to move the timeshift buffer to USB, moved the smartcards from the box to my router, replaced oscam with an "I can do nothing but be a client" and so on and so on.

I can exclude hardware or thermical problems:
The box works like a charm for some hours after rebooting but behaves like a bitch again after max. 24h. As it is booting from hot to hot it won't cool down that much during reboot that it wouldn't behave like a bitch again after a much shorter time.

Misbehaviour also varies greatly:
When watching mkv/mp4/avi/mpg from server,
- picture stands still, sound continies
- video continues, sound is muted
- giant artefacts
especially after pausing and resuming playback.

Sometimes jumping back and forward recovers, but most times doesn't help. Video plays back just great after reboot, even after pausing/resuming a zillion times.

Watching timeshifted TV, I more or less frequently get more or less giant artefacts. They are not inside the stream, jumping back 1 minute plays the same part just fine. This is a known problem of the Ultimo.

PS:
I can easily let the box run 300 days without rebooting it. It just is a pain in the ass to watch anything after max. 24h.

Using identical Plugins & Co. on a friends Duo² doesn't produce ANY problems.


But we (I) are becoming off topic. I was talking about known but unfixed bugs in OpenPLi components which can easily be reproduced on any box, not my specific problems with my box/model of which I actually know they do not occur on other models but with any image on (my) Ultimo.

[Rob van der Does]

root@Ultimo:~# uptime

 06:21:10 up 21 days, 14:06,  1 user,  load average: 0.22, 0.19, 0.14

In use or just sitting there, doing nothing?

In constant use; it's my main box.

[колбаскин]

Как сделать работающей авторизацию в OpenWebif на 8001м порту?

И будьте добры, дайте нормальную инструкцию как запустить Transcoding с авторизацией на 8002м порту.

 

How to make working authorization in OpenWebif on 8001 port?
And be so kind as, give the normal instruction how to start Transcoding with authorization on 8002 port.

 

step by step

please

[Erik Slagter]

Your translation is way better than mine Google says:

 

How to Set Authorization rabotayuschey OpenWebif at 8001m port?
And be Dobriy let normalnuyu Instructions How to launch Transcoding with Authorization to 8002m port.

 

Okay, let's try it again.

 

Port 8001 is served by Enigma on OpenPLi (and many other images). Not the OpenWebIf and also not the streamproxy. The Enigma built-in streamer (which I didn't write and have no knowledge of) does not check authorisation. It has never done, it's not something that changed "now". Solution: block this port in your router/firewall.

 

Poort 8002 is served by the streamproxy. It can serve requests for services, files, "normal streaming" and transcoding. It also honours (checks) authentication if you enabled authentication in the OpenWebIf. This is something I am going to check, because I am not 100% sure it works correctly at the moment. I will get back about that.

 

Unfortunately, you cannot run the streamproxy (with authentication) on port 8001, because Enigma already binds to that port. I cannot anything to solve that.

 

The only way to use authentication is to use another port than 8001. The streamproxy can use any port you want, if it's free. And 8001 is not free.

[SpaceRat]

Port 8001 is served by Enigma on OpenPLi (and many other images). Not the OpenWebIf and also not the streamproxy. The Enigma built-in streamer (which I didn't write and have no knowledge of) does not check authorisation. It has never done, it's not something that changed "now".

That much is wrong.

The E2 stream proxy tries to authorize through the existing Webinterface (Regardless of whether it is the old Webif or OpenWebif).
This is the reason why the WebInterface must listen on port 80 for streaming to work and which is why both, old Webif and OpenWebif create an additional listener on port localhost port 80 if the user configures a different port than 80.

So to say, the E2 streamproxy authorizes "en passant" through the Webif. Silly but true.

We (Some other contributors and I) borked this authorization in the very same moment we enabled IPv6 in OpenWebif, because now the local streamproxy didn't access the Webif from 127.0.0.1 anymore, but from ::ffff:127.0.0.1 and Twisted getClientIP function is useless ...

As a result, streaming was always asking for login/pass, even if stream auth was disabled.

I fixed this problem in commit fc16ec784217887aa76a2fcbd3abe0d0e7f1d0a3
and already mentioned this in post #38 of this thread.

At that time, everything was working nicely, stream auth was requesting auth if enabled and didn't if stream auth was disabled.
 

Unfortunately, you cannot run the streamproxy (with authentication) on port 8001, because Enigma already binds to that port. I cannot anything to solve that.

This isn't the whole truth either.
There are other images (HDMU sh4-images in this case) which use a seperated streamproxy binary for port 8001 inside inetd.conf, i.e. where the main executable of Enigma2 does NOT bind to port 8001 itself:

Topf:~# cat /etc/inetd.conf
# /etc/inetd.conf: Internet superserver configuration database
#
# <service_name> <sock_type> <proto> <flags> <user> <server_path> <args>
#
8001                    stream tcp6 nowait root /bin/streamproxy        streamproxy  

I'll continue to investigate the login/auth issue from OpenWebifs side.
However, looking from that point I can only see
- if the streamproxies try to auth
and
- if they are supposed to auth or not (stream auth enabled or disabled)

ATM my friend's Duo² has auth enabled and (properly) asks for auth when connecting to the transcoding proxies but not when connecting to port 8001.

I hope to know more tomorrow.

[Marc83]

I'm using port 81 for Open Webif and not 80 (this is being used by another device in my network). I can't get transcoding working, based on what I read in this topic, I conclude this could be because I'm not using port 80. Is there any way to get transcoding working and keep using port 81?

 

Thank you for your help!

[SpaceRat]

I can't get transcoding working, based on what I read in this topic, I conclude this could be because I'm not using port 80. Is there any way to get transcoding working and keep using port 81?

This is not related.

As I said: If you set the OpenWebif to listen on port x with x != 80, it will automatically also listen on port 80 (but only localhost) to keep streaming working:

		if port != 80:
			if not isOriginalWebifInstalled():
				root = buildRootTree(session)
				if config.OpenWebif.auth.value == True:
					root = AuthResource(session, root)
				site = server.Site(root)
				try:
					if has_ipv6 and fileExists('/proc/net/if_inet6') and version.major >= 12:
						# use ipv6
						listener.append( reactor.listenTCP(80, site, interface='::1') )
					else:
						# ipv4 only
						listener.append( reactor.listenTCP(80, site, interface='127.0.0.1') )
					print "[OpenWebif] started stream listening on port 80"
				except CannotListenError:
					print "[OpenWebif] port 80 busy"

[stick50jr]

root@Ultimo:~# uptime

 06:21:10 up 21 days, 14:06,  1 user,  load average: 0.22, 0.19, 0.14

In use or just sitting there, doing nothing?

Can you please send me the output of
"opkg list_installed"
by PN?

BTW: Since day one, I have already replaced the "original" Samsung Desktop-HDD with a Western Digital AV-optimized harddisk, added a third tuner, moved that new third tuner to tuner slot B when I later replaced the third tuner with a twin-tuner, tried ext2, ext3, ext4, xfs file systems, tried to move the timeshift buffer to USB, moved the smartcards from the box to my router, replaced oscam with an "I can do nothing but be a client" and so on and so on.

I can exclude hardware or thermical problems:
The box works like a charm for some hours after rebooting but behaves like a bitch again after max. 24h. As it is booting from hot to hot it won't cool down that much during reboot that it wouldn't behave like a bitch again after a much shorter time.

Misbehaviour also varies greatly:
When watching mkv/mp4/avi/mpg from server,
- picture stands still, sound continies
- video continues, sound is muted
- giant artefacts
especially after pausing and resuming playback.

Sometimes jumping back and forward recovers, but most times doesn't help. Video plays back just great after reboot, even after pausing/resuming a zillion times.

Watching timeshifted TV, I more or less frequently get more or less giant artefacts. They are not inside the stream, jumping back 1 minute plays the same part just fine. This is a known problem of the Ultimo.

PS:
I can easily let the box run 300 days without rebooting it. It just is a pain in the ass to watch anything after max. 24h.

Using identical Plugins & Co. on a friends Duo² doesn't produce ANY problems.


But we (I) are becoming off topic. I was talking about known but unfixed bugs in OpenPLi components which can easily be reproduced on any box, not my specific problems with my box/model of which I actually know they do not occur on other models but with any image on (my) Ultimo.

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).

[SpaceRat]

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.


I did not fix the problem of streaming on port 8001 bypassing auth because that problem isn't part of OpenWebif (or the old Webif) but caused by this commit:
[Openpli-git-commits] openembedded master: remove streamproxy (obsolete)
That streamproxy was not obsolete ...