52 replies to this topic

[ip_gr]

Problem 3:

The quality of the connection also depends on how the wifi signal is distributed. That means that even if your are next to the AP you might have a very noisy connection because the signal is distributed in another direction.

 

I know about the problems of wifi signal distributions etc. But sometimes it is necessary to use Wifi. The same behaviour is reproducible if you upload a huge amount of data, like mkv-files or a directory of picons. This is not a realtime buisness. And I don't think that there is any buffering going on.

But anyway... Let us assume that the problem is the signal itself. Why the problem only occurs for PLI-/PLI-based images and why the original DMM image has no  problem with the signal?

 

@malakudi

ela malakudi kane kati giati 8a me trelanoun oi alloi...

I don't know for sure the chipset. From an internet research it should be a Ralink RT5370 Chipset. How can I find it out? I am talking about the built-in wifi!

Edited by ip_gr, 4 December 2015 - 15:28.

[ip_gr]

ok the mentioned ralink RT5370 is nonsense...

[malakudi]

@ip_gr: Is this wifi installed on USB bus or on PCI bus? Please report output of:

lsusb

lspci

[ip_gr]

As far as I know the built-in wifi is on pci but I put the output for both:

 

root@dm8000:~# lspci
00:01.0 Class 0200: 168c:001a
01:00.0 Class 0101: 14e4:8602
root@dm8000:~# lsusb
Bus 001 Device 001: ID 1d6b:0002
Bus 002 Device 001: ID 1d6b:0002
Bus 003 Device 001: ID 1d6b:0001
Bus 004 Device 001: ID 1d6b:0001
Bus 001 Device 002: ID 04cc:1520
Bus 001 Device 003: ID 058f:6362
Bus 002 Device 002: ID 16d0:054d
Bus 001 Device 004: ID 0781:5571

Edited by ip_gr, 4 December 2015 - 16:16.

[malakudi]

Yes it seems it is 168c:001a, Atheros ath5k.

Can you also post the output of command:

lsmod

[malakudi]

It seems OpenPLi uses linux-kernel-3.2, patch 60 and dmm patch with tag 4e0356d04e89df800361b9252f990716f5523c6e, while oe-alliance uses patch 59 and same dmm patch. Merlin3 uses patch 68 and much newer dmm patch with tag 3c7230bc0819495db75407c365f4d1db70008044. So the kernel is different, and that explains the different behaviour.

[ip_gr]

Here it is!

root@dm8000:~# lsmod
Module                  Size  Used by    Tainted: P
cdfs                   25512  0
isofs                  34187  0
udf                    93938  0
crc_itu_t               1067  1 udf
tft_dm8000              2113  0 [permanent]
wlan_tkip               9714  3
nfsd                  260855 11
autofs4                25216  1
ntfs                  107053  0
dreambox_keyboard       3296  0
dreambox_rc2            5216  1 dreambox_keyboard
bcm7400              3993179 10
bcm4501                54528  1 bcm7400
alps_bsbe2             42739  1 bcm7400
fpga                  284413  1 bcm7400
snd_pcm                64308  1 bcm7400
snd_timer              19010  1 snd_pcm
snd_page_alloc          5453  1 snd_pcm
tu1216                 40318  1 bcm7400
max4397                 2464  1 bcm7400
cu1216mk3               7914  1 bcm7400
alps_bsbe1_c01a        17032  1 bcm7400
bcm4506                91538  1 bcm7400
helper                   540  1 bcm7400
cxd1981                14278  1 bcm7400
alps_bsbe1              6163  1 bcm7400
lnb_ctrl                5149  5 bcm4501,alps_bsbe2,alps_bsbe1_c01a,bcm4506,alps_bsbe1
stv0299                 9368  1 alps_bsbe1
wlan_scan_sta           8740  1
lcd                    18233  0
stb_core               16738 13 dreambox_keyboard,dreambox_rc2,bcm7400,bcm4501,alps_bsbe2,fpga,max4397,cu1216mk3,alps_bsbe1_c01a,bcm4506,cxd1981,lnb_ctrl,lcd
ath_rate_sample        11722  1
ath_pci               113606  0
wlan                  175735  5 wlan_tkip,wlan_scan_sta,ath_rate_sample,ath_pci
ath_hal               284889  3 ath_rate_sample,ath_pci
root@dm8000:~#

So could there be a correction with kernel in OpenPLI?

Edited by ip_gr, 5 December 2015 - 13:02.

[malakudi]

The problem is DM boxes are no longer supported. And no member of OpenPLi team has a DM8000 to test the issue.

[ip_gr]

Thank you for investigate the issue!

[Dimitrij]

Use another WIFI USB for test.

Edited by Dimitrij, 5 December 2015 - 17:10.

[LeoGR]

I will test it if I found a usb wifi dongle. Thank you!

[goldeneye]

This one works like a charm (hope it never dies)

Attached Files

•  image.jpeg   8.76KB   6 downloads

[Erik Slagter]

Yeah we've mentioned that so many times. But people don't want to know.

Edited by Erik Slagter, 6 December 2015 - 10:40.

[ip_gr]

If your comment is about using the one goldeneye mentioned let me explain something...

Assume I buy a device and this device has a built-in functionality I want to use and this functionality does work well with several operating systems. If I now install a operating system on it and with this operating system the built-in functionality does not work because of any reason, then the solution for this problem is not to buy some other hardware and bypass the problem. This is a workaround which one can use to do his work until a solution is found. The solution which have to be found is, to fix the issue in the used operating system.

So the behaviour of PLI-image is a bug and nothing else. People could talk around and give several workarounds (for what I am very thankful!) but it remains a bug.

[malakudi]

Yes, it is a bug that affects a no longer supported box. http://openpli.org/n...ultimedia-stbs/

 

I would say you might have a better luck with reporting the issue to some oe-alliance image (where they claim continued support for DM boxes) but I doubt you get noticed. Your best chance I think is the greek SatDreamGr image. They support DM boxes, they are completely OpenPLi compatible and I think they also have DM8000 so it is easier for them to support it.

[goldeneye]

@Malakudi

I don't agree.. As long as a device is supported updates should become available as new devices enter the market. In the case of USB Wifi dongles this now no longer applies. Older USB sticks that were suported in OpenPli are now obsolete and very hard (if not impossible) to come by. Newer USB Wifi dongles support 54Gb and higher. Apart from the usual WiFi problems causing the connection to fail you can't force OpenPli to update just because somebody wants to. This is a simple case of technical progress. Simply ditch the old box and buy a new one if you insist on using WiFi over USB. My solution is simple and works regardless of image and/or kernel. You can use WiFi via this bridge and do not need to lay cables.. Another nice thing is that the WiFi bridge is always on and ready for use (even at boot time) which is not always the case with USB Wifi dongles...

[goldeneye]

I meant @ip_gr

 

Sorry Malakudi..

[Erik Slagter]

Assume I buy a device and this device has a built-in functionality I want to use and this functionality does work well with several operating systems.

That is where your assumption is wrong.

 

Any functionality using USB is supplied as-is without any warranty. That's not only because of the dodgy USB hardware in STB's, but also because we can't give any guarantee whether any hardware is supported and will remain supported. That's up to the developers of the Linux kernel and up to the manufacturer. OpenPLi has no saying in that.

 

So I repeat: play it safe and use a wireless bridge.

[ip_gr]

 

Assume I buy a device and this device has a built-in functionality I want to use and this functionality does work well with several operating systems.

That is where your assumption is wrong.

 

Any functionality using USB is supplied as-is without any warranty. That's not only because of the dodgy USB hardware in STB's, but also because we can't give any guarantee whether any hardware is supported and will remain supported. That's up to the developers of the Linux kernel and up to the manufacturer. OpenPLi has no saying in that.

No that's not were my assumption is wrong. For me as an end-user that fact that I do not need additional hardware for realising a wifi connection fulfils the fact that it is a built-in functionality. Hoe this functionality is relaized, I do not care as an end-user.

 

And yes OpenPLi has a saying in that. That's what I meant with "talking around the problem". The fact that with other images the functionality works as it should, but only with PLi-/Pli-based images it doesn't proves that it is a problem of PLi-/Pli-based images and only for them. The fact that wifi connections work with other images proves that the Linux kernel and the manufacturer ensures the working functionality.

As I said, you can talking around but the problem remains a bug in PLi-/Pli-based images. Nothing more nothing less. And in the time were it is talked around the problem could be solved without any workaround. Malakudi has analyzed it.

[malakudi]

I haven't analyzed it, I just discovered differences in kernel that "might" be the origin of the problem. There could be other issues too. As I said, since DM8000 is a no longer supported STB from OpenPLi, you can't expect your problem to be fixed. OpenPLi has been very clear about the support of DMM boxes and the reason behind it. You should blame the company you gave your money (and a lot money for the DM8000) for choosing to become open-source non-friendly.