693 replies to this topic

[Erik Slagter]

For me it's working now... the critical point was that OpenWebIf needs to have Port 80 available. I had it on Port 81 before.

If that is something in the enigma config file, I can make it fetch from there instead of using the hard coded port 80.

[SpaceRat]

If that is something in the enigma config file, I can make it fetch from there instead of using the hard coded port 80.

You could, but that would be just some enhancement.

Normally the OpenWebif knows listening on port 80 is required for streaming, thus it in fact listens on both ports, the configured one and port 80, if a port != 80 is specified.

The only reason why it possibly doesn't do that is that it believes the old Webinterface is also installed ...

Edited by SpaceRat, 15 April 2014 - 18:40.

[Erik Slagter]

Can you explain then why this user had to change the port number to 80 to get it working?

[SpaceRat]

Can you explain then why this user had to change the port number to 80 to get it working?

As I said:
... that it believes the old Webinterface is also installed ...

[Erik Slagter]

In that case I'd expect to get a connection on port 80, but the connection is refused.

[Erik Slagter]

I've found and fixed a few small issues now.

• When a service was requested, that was not available (tuner in use, non-existing service, etc.) the web interface the channel is requested from, will stay silent (no error), streamproxy will wait for 15 seconds (was 30 seconds) and then give up. The pid iterators would be used even when they weren't set -> crash. This has been fixed.
• The default bitrate (specified in /etc/enigma2/streamproxy.conf) is set to 1 mbps (value 1000, equals 1000 kbps). This is fine for the duo2, but it doesn't work on the solo2. When applied to the solo2, you will get audio but no video.

The only current issue left is that you need to install the streamproxy explicitly, it's not in the image, as it should. I will fix that shortly.

 

New versions in the feed tomorrow.

 

Leaves me with the usual comment: the encoding engine (= hardware + drivers) isn't very robust. If you see unexpected results, always check dmesg first. If there is a kernel oops, you'll have to reboot. The streamproxy does it best to keep the encoding engine happy, but there is only so much it can do. For instance, on the vuduo2, you can do two transcodings simultanuously, but NEVER start them at the same time, always wait until you can see video before you start the second instance. The engine cannot cope with two initialisations at once.

Edited by Erik Slagter, 15 April 2014 - 20:14.

[SpaceRat]

In that case I'd expect to get a connection on port 80, but the connection is refused.

Well ... once again ...

Normally the Webinterface (Both, old Webif and OpenWebif) handles this itself by listening on localhost:80 (Specifically [::1]:80) additionally to the configured non-80 port.
OpenWebif refrains from doing so however, if it believes the old Webinterface is also installed (Because it has the same behaviour, which would result in a conflict).

So there are multiple reasons why your connection attempt fails:

1. You aren't connecting to localhost ... the listener for port 80 is started on localhost only, not "all addresses/::/0.0.0.0".
2. The user actually HAS the old Webinterface installed but inactive.
3. OpenWebif makes a false assumption that the old Webinterface was installed while it isn't.
4. OpenWebif fails to hook [::1]:80

A reason for 4 might be the user using an old workaround for missing IPv6-support:
This workaround works by hooking port x IPv6-only using a proxy like HAproxy or 6tunnel and forwarding all incoming IPv6-traffic to the same IPv4-only port.
Now that OpenWebif supports IPv6 itself, it fails to register the Dual-Stack listener if either - IPv6 or IPv4 - ports are already in use.

Dream Multimedia even still propagates this workaround using xinetd, rather than just shipping their images with real IPv6 support.

[Erik Slagter]

You're missing the point. If the old webif was installed (or not) there would always something be listening at 127.0.0.1:80. If the streamproxy gets "connection refused" clearly nothing does so. The streamproxy connects to 127.0.0.1:80. I can easily change that to [::]:80, but I don't trust ipv6 to work on every environment (image/enigma/webif/etc.)

[SpaceRat]

You're missing the point. If the old webif was installed (or not) there would always something be listening at 127.0.0.1:80.

2. The user actually HAS the old Webinterface installed but inactive.

The streamproxy connects to 127.0.0.1:80.

You should.
While the old Webif could easily be updated to IPv6 in <5 minutes, HDMU is the only image team that has such an IPv6-compatible old Webif, so the old Webif - if present - would most likely only listen on 127.0.0.1:80.

I can easily change that to [::]:80, but I don't trust ipv6 to work on every environment (image/enigma/webif/etc.)

... but you could add a -6 switch in order to make this configurable ...
Would be nice for possible future IPv6-only test-runs ...

PS:
It would be really, really great if you could have a look into the E2 source and rewrite the socket creator classes to support Dual Stack operation.
I think this is the best time for it, while you are writing socket creators anyways ...

The regular stream proxy on port 8001 is one of the show stoppers for an IPv6-only test run and unless I missed some update, E2 would be able to stream (out) via IPv6 but not to another E2-box, because that one wouldn't be able to connect to that IPv6-stream ...

Edited by SpaceRat, 15 April 2014 - 20:31.

[Erik Slagter]

... but you could add a -6 switch in order to make this configurable ...

There is no technical reason why it couldn't be added. I can even make it autoprobe. But it doesn't have priority.

It would be really, really great if you could have a look into the E2 source and rewrite the socket creator classes to support Dual Stack operation. I think this is the best time for it, while you are writing socket creators anyways ...

I am not at all familiar with that part of enigma. Same story, I might do it one time, but it doesn't have priority. Also I guess that whether the webif listens to ipv6 is merely determined by twisted not by enigma?

The regular stream proxy on port 8001 is one of the show stoppers for an IPv6-only test run and unless I missed some update, E2 would be able to stream (out) via IPv6 but not to another E2-box, because that one wouldn't be able to connect to that IPv6-stream ...

As long as everybody on the world can still get a valid ipv4 address, there is no priority on ipv6 (even though I've been using it since 1998).

You can always use the streamproxy at 8002 or 8002, using /livestream or /filestream url.

Edited by Erik Slagter, 16 April 2014 - 13:57.

[SpaceRat]

It would be really, really great if you could have a look into the E2 source and rewrite the socket creator classes to support Dual Stack operation. I think this is the best time for it, while you are writing socket creators anyways ...

I am not at all familiar with that part of enigma.

As far as I understand the source, it's one pretty clean class, which only needs one or two simple methods rewritten.

[SpaceRat]

The regular stream proxy on port 8001 is one of the show stoppers for an IPv6-only test run and unless I missed some update, E2 would be able to stream (out) via IPv6 but not to another E2-box, because that one wouldn't be able to connect to that IPv6-stream ...

As long as everybody on the world can still get a valid ipv4 address, there is no priority on ipv6 (even though I've been using it since 1998).

So you are saying it finally has priority?

Because the last time "everybody on the world can still get a valid ipv4 address" was true was in 2011:
IPv4 address space has been exhausted in 2011 for Asia and in 2012 for Europe.
There are already about 1 to 2 million lines in Germany without publically reachable IPv4 but DS-lite (Full IPv6 but only IPv4 Carrier Grade NAT through a tunnel mechanism).

You can always use the streamproxy at 8002 or 8002, using /livestream or /filestream url.

That's an OpenPLi-only, Vu+ Solo²/Duo²-only workaround.

Fixing the Enigma2 class which creates the socket for port 8001 would at least make things work for all boxes running OpenPLi 4.0 - not only Vu+ Solo²/Duo² - and probably "Based on OpenPLi" images.

I assume the problem to be
lib/network/serversocket.cpp
and
lib/network/socket.cpp
within the E2 core sources totalling to less than 500 lines of code, with only a fraction of those needing a fix.

[SpaceRat]

Also I guess that whether the webif listens to ipv6 is merely determined by twisted not by enigma?

OpenWebif already has full IPv6 support.
Wether it can provide it or not depends on Linux kernel (even DMM has IPv6-aware kernels), Python (IPv6 enabled in OpenPLi 4.0, HDMU and probably some "Based on OpenPLi" images) and a decently new version of Twisted (12.0.0 and up).
So on OpenPLi 4.0 and HDMU, the OpenWebif is fully IPv6-compatible.

However, the stream proxy on port 8001 is not part of the Webif but Enigma2, so that one remains IPv4 only unless it gets fixed inside Enigma2.

[Erik Slagter]

Ah okay clear.

[MiLo]

Those socket classes are in serious need of a rewrite (wasting resources, making things overly complex). But lacking time to do so, a patch to make them support ipv6 is welcome too...

[delavega]

not working... on 8002

[Erik Slagter]

Please check /etc/enigma2/streamproxy.conf

 

The bitrate there has been 1000 (= 1000000 bps = 1 Mbps), this okay for the duo2, but won't work on the solo2. I have changed the default, but that won't overwrite an existing config file. So if you have a solo2, you need to change this. 500 (= 500 kbps) seems to be a reasonable value there. After you changed it, you need to restart the streamproxy:

 

/etc/init.d/streamproxy.sh stop

/etc/init.d/streamproxy.sh start

[delavega]

it was already like that

 

listen = 8002:transcode

listen = 8003:transcode

size = 480p

bitrate = 500

profile = baseline

level = 3.1

bframes = 0

 

root@vusolo2:~# /etc/init.d/streamproxy.sh stop

Stopping Streamproxy: stopped /usr/bin/streamproxy (pid 405)

streamproxy.

root@vusolo2:~# /etc/init.d/streamproxy.sh start

Starting Streamproxy: streamproxy.

 

 

and it does not work

Edited by taboune, 16 April 2014 - 18:14.

[Erik Slagter]

Ok, then we can go on the next step. Did you check dmesg for something like this. If you see something similar to this (doesn't need to be exactly the same), the transcoding engine has crashed and you need to reboot.

[MENC]: TIMEOUT 0
Unhandled kernel unaligned access[#1]:
Cpu 0
$ 0   : 00000000 10008700 e10fbc58 00000001
$ 4   : da7adead b4f5bd5a 00000000 00000000
$ 8   : 00000000 cfc6c2b4 00000000 00000000
$12   : 00000000 00000000 00000001 00000001
$16   : cfc6c128 da7adead 00000000 e11541e8
$20   : e11535d0 e101ff94 e10440c4 e1023dc0
$24   : 00000000 e1043454                 
$28   : cf716000 cf717d28 e102441c e0ffff28
Hi    : 0000228e
Lo    : f9581600
epc   : e10fbc58 BVDC_Window_SetDelayOffset+0x0/0xc [dvb_bcm7424]
    Tainted: P           O
ra    : e0ffff28 NEXUS_VideoWindow_SetSyncSettings_priv+0x60/0x17c [dvb_bcm7424]
Status: 10008703    KERNEL EXL IE
Cause : 00800014
BadVA : da7aded1
PrId  : 00025a11 (Brcm4380)
Modules linked in: ipv6 rt5370sta(O) rt2800usb rt2800lib crc_ccitt rt2x00usb rt2x00lib mac80211 fpga_directc(PO) brcmfb(O) dvb_bcm7424(PO) procmk(O) fuse
Process nx_sched_low (pid: 87, threadinfo=cf716000, task=cf0611f8, tls=00000000)
Stack : cf717da4 e11541e8 cf079d00 e1043474 e10440c4 e1023dc0 e1bdfb34 cf4ba458
        cf717d60 e10099b4 00000010 00000000 00000001 00000002 da7adead 00000000
        00000000 00000000 00000000 e11541e8 e11535d0 e101ff94 cf4ba000 cf4ba034
        cf717da4 e100b2dc e101fddc e101ff94 ced3edc4 e1023dc0 806c1e80 00010100
        00000001 00000002 00000006 00000004 81e1ae80 10008700 cf6e0604 e1be0000
        ...
Call Trace:
[<e10fbc58>] BVDC_Window_SetDelayOffset+0x0/0xc [dvb_bcm7424]
[<e0ffff28>] NEXUS_VideoWindow_SetSyncSettings_priv+0x60/0x17c [dvb_bcm7424]
[<e10099b4>] NEXUS_SyncChannel_P_DisconnectVideoOutput+0x84/0xbc [dvb_bcm7424]
[<e100b2dc>] NEXUS_SyncChannel_SetSettings_impl+0x63c/0x840 [dvb_bcm7424]

Code: aca20000  03e00008  00001021 <ac850024> 03e00008  00001021  10a00003  00000000  8c822bc0
---[ end trace e75591b9b31214f6 ]---

[delavega]

nope nothing like that and the box didnt freeze.