Jump to content


WanWizard

Member Since 10 Sep 2006
Online Last Active Today, 15:30
*****

#362733 Openpli update troubles topic

Posted by WanWizard on 25 July 2013 - 22:25

Waar is "hier"?




#360201 Vu+Duo2

Posted by WanWizard on 8 July 2013 - 17:18

Which is an OpenVIX clone...




#353569 [Vu+ Ultimo] Stutter while streaming 720p channels

Posted by WanWizard on 30 May 2013 - 19:15

I'm not sure that will help, I'll check tonight if I see any difference between the VU+ and the ET9000.




#353426 [Vu+ Ultimo] Stutter while streaming 720p channels

Posted by WanWizard on 29 May 2013 - 23:15

You have to be careful with large buffers on a VU+. Their drivers are crappy, and contain memory leaks, so over time, less and less memory will be available.

 

Perhaps something else to test: do you see a difference between a box that just has been rebooted, and one that has been running a few days?




#353259 [Vu+ Ultimo] Stutter while streaming 720p channels

Posted by WanWizard on 29 May 2013 - 09:36

If you have the same over a wired connection, I sincerly doubt that the quality of the connection has anything to do with it. After all, there are no TCP errors and no dropped packets (except for the one). The only thing that can play a part on the network level is latency (and jitter).

 

You can test that simply from your box (easier then from the iPad), by doing a

ping -s 1492 <ip-address-of-the-ipad>

and check what the response times are, and what the variation is reponse times is.

 

I think the problem isn't that the data gets lost, the problem is that it arrives too late, causing the player to "stall"...




#353257 question

Posted by WanWizard on 29 May 2013 - 09:25

The DM800 image has been stuck on OpenPLi 2.1.

 

The manufacturer, DMM, has declared it end-of-life, and does not make any new drivers for it anymore, so we can't make an OpenPLi 3.0 image for it.

 

Since OpenPLi 2.1 hasn't changed since the release of OpenPLi 3.0, the image that you can still download is perfectly fine, it's the same as the week before, and it will be the same as one that would be generated today.

 

Once the build environment has been recreated we will start generating new nightly images again, as of this moment there has been no descision made to retire the DM800.




#353228 [Vu+ Ultimo] Stutter while streaming 720p channels

Posted by WanWizard on 28 May 2013 - 21:18

I doubt that, because I have the same issue as you, and I can easily reproduce it, if I make the connection unreliable enough.




#353213 [Vu+ Ultimo] Stutter while streaming 720p channels

Posted by WanWizard on 28 May 2013 - 20:32

I don't know if it's different from your issue, but I can easily reproduce similar VLC behavior, which is why I picked the crappy wifi link (from downstairs, other side of the house).

 

I wanted to confirm it's not an issue at the TCP layer. That one dropped packet is always there is seems, I think it's the first one received. Buf after that none, and my wireshark sniff confirms that the network or TCP layer is not the issue, all packets sent by the box are received by VLC.

 

I'm more puzzeled about the incrementing "corrupted" counter. What does corrupt the packet payload, and why?




#353210 [Vu+ Ultimo] Stutter while streaming 720p channels

Posted by WanWizard on 28 May 2013 - 20:00

How exactly do you stream? From the webif?

 

I've just streamed an HD channel over a crappy wifi link, and in VLC, if you choose Tools, Codec Information, Statistics, I can see that I haven't lost a single packet, but as soon as I get pixilation, the input discarded/corrupted counter goes up.

 

If network is no issue, then the question is what corrupts the input? I ran a wireshark session in the background, and that doesn't show any error at the TCP level, even over a crappy wifi...




#353177 [Vu+ Ultimo] Stutter while streaming 720p channels

Posted by WanWizard on 28 May 2013 - 17:38

TCP buffering happens at the network layer, and the way TCP works is that it will keep the packet until an ACK is received from the other side. TCP is connection oriented, retransmissions will cover for any packet loss.

 

So it must be an issue in the higher layers (client or server).




#352319 Solo2 New Kernel 3.3.8-2.0 & OpenPLi

Posted by WanWizard on 24 May 2013 - 15:11

You still singing the old DMM-song, and haven't explained what is illegal about it.

 

Fact is that GPL code can legally be forked, and GPL quite clearly states that any derivative work MUST be GPL too. Enigma was GPL from the start, Enigma2 was dual-licensed from the start. Which have given DMM a loop-hole to create a closed-source image.

 

The original licence stated:

 

The 'enigma2 core' is licensed under a proprietary license.

 

The 'enigma2 core' contains all files in this sourcetree except plugins in lib/python/Plugins which carry their own LICENSE file.

 

Those plugins are licensed under their own license. This proprietary license does not allow you to compile, modify or do anything with this sources. You are allowed, however, to distribute an unmodified version of the sources, including all license statements.

 

Additionally, this proprietary license will essentially allow you one thing:

 

You are free to take *THIS* version of enigma2, and derive a version which will be licensed under the GPLv2. If you're doing this, be sure to insert proper licencening statements to ensure that it doesn't get mixed up with the proprietary version.

 

The derived version can be, of course, modified, distributed etc. in modified forms, however, you have to publish all changes you made in source form if you are distributing a binary version. Exact details can be read in the GPLv2.

 

If you wish do send us patches to be included in the "official sourcetree", which will be based on the proprietary license, you have to agree that your code will be licensed under the proprietary license.

 

Note that "official sourcetree" just means the version which is included in the main developer CVS hosted at, or on behalf of, Dream Multimedia.

 

You are, of course, free to make patches to a GPL-only version. These changes won't show up in the "official release" then, though.

 

Additionally, this license allows Dream Multimedia to change terms of this license. If you don't like a change in this license, you are free to derive a GPL version from a previous version, of course.

 

The same goes for plugins. You can decide whether you want your plugins to be compatible to the "official release" (so you must explicitely allow "linking" code licensed under the proprietary license to your code), or you can decide that your code should be only linked to the GPL'ed ("free") version of enigma2. Your plugins are also allowed to be closed-source, though we strongly discourage this for technical reasons.

 

Then, DMM changed it to

 

Enigma2 is property of Dream Multimedia GmbH. All copyrights with regard to Enigma2 belong to Dream Multimedia GmbH only. The copyrights with regard to plug-ins may belong to third parties.

 

Any existing version of Enigma2, original or derived, may only be used by the owner of a Dreambox for private purposes only.

 

Explicitly, no one is allowed to reproduce, license, rent, lease, sell, broadcast, publicly display, transmit or otherwise distribute or compile any version of Enigma2 for commercial purposes.

 

Explicitly, no one is allowed to use any version of Enigma2 for offering, distributing or selling any hardware or box product offering Enigma2 functionality.

 

Explicitly, no one is entitled to make any commercial use - directly or indirectly - of Enigma2.

 

By downloading and/or using any version of Enigma2 you indicate your acceptance of the terms of this allowance. Dream Multimedia GmbH is entitled to change the terms of this allowance.

 

Any intended use of Enigma2 going beyond the present allowance has to be presented to Dream Multimedia GmbH and depends on the explicit agreement of Dream Multimedia GmbH. Feel free to contact Dream Multimedia GmbH.

 

So we did what was explicitly granted in the original license: we forked the Enigma2 repository with the state of the day before the change of license, and made that GPLv2.

 

Anyone can do the same, or use OpenPLi as the basis, create a driver set for a particular box, and they are in business. That's how it works. I understand perfectly that DMM would prefer to have a few more Ferrari's on their doorstep, but then they should have thought about it before they gave Enigma2 a GPL license.

 

You also seem to forget that if it were not for the efforts of the opensource teams (Gemini, PLi, Rudream, etc), it is very likely that DMM wouldn't have been such a bit hit at the time...

 

If you really want to discuss "dodgy" behaviour of people, please explain to us why improvements in our GPL version find their way into dream's closed-source version, which is explicitly forbidden by the GPLv2 license...




#350607 no files in download section

Posted by WanWizard on 16 May 2013 - 15:11

I've restored the last image generated from the backups for all E1 CDK images (dm500/dm56x0/dm7000) which is from May 5th.




#347555 Wanneeer PLI voor de VUPLus SOLO2

Posted by WanWizard on 3 May 2013 - 11:14

4 === 1.

 

En dacht je nu echt dat we daar van wakker liggen?

 

OpenPLi is geen commercieel product waarbij de focus ligt op zo veel mogelijk klanten. Dat lijken veel mensen te vergeten (gezien de soms dwingende toon waarop zaken "ge-eist" worden).

 

Het is ons open source hobby project, iets wat we leuk vinden om onze (soms schaarse) vrije tijd aan te besteden, en waarvan het leuk is als andere mensen waarderen dat we leuke dingen maken en dat vervolgens gebruiken.

 

En dus hanteren we principes en maken we keuzes. We snappen best wel dat dat betekent dan sommige mensen daar niet happy mee zijn, maar dat is dan zo. Dan moeten ook zij een keuze maken. Net zoals met elk ander product dat je koopt of gebruikt.




#347552 Wanneeer PLI voor de VUPLus SOLO2

Posted by WanWizard on 3 May 2013 - 11:04

VU+ zelf maar vooral ook omdat andere image bouwers die lelijke patch in hun image stopen is het voor VU+ blijkbaar niet zo noodzakelijk om deze "beginnersfout" te herstellen uit de drivers....

En jij blijft maar denken dat imagebouwers macht hebben. Is er in de geschiedenis (van E2) ook maar één moment aan te wijzen dat hierop wijst?

 

Image bouwers hebben geen macht. Consumenten hebben die wel.

 

Wij hebben ons standpunt ingenomen. Het is aan jullie als consument om te beslissen of je kiest voor:

1. Solo2 + Image met hack

2. Solo2 + niet volledig functionerende OpenPLi

3. andere hardware waarop OpenPLi wel volledig functioneert

 

Kiest de consument voor 3, dan zal VU echt vroeg of laat zijn kar wel keren, er is namelijk een flinke bak centen mee gemoeid. Kiest de consument voor 1 of 2, dan blijft het business as usual.




#346730 merge requests for PLi's git

Posted by WanWizard on 28 April 2013 - 17:07

The developers might be busy with other things. It's a hobby, which doesn't necessarily comes first in their lives...