Jump to content


Photo

Solo2 New Kernel 3.3.8-2.0 & OpenPLi


  • Please log in to reply
52 replies to this topic

Re: Solo2 New Kernel 3.3.8-2.0 & OpenPLi #21 vubelt

  • Member
  • 41 posts

0
Neutral

Posted 21 May 2013 - 17:57

Also tested other images.
Always OpenPLi, Vusolo2 and Vuduo.
Essential, and stable. The best image quality, without any setting.
Everything works fine, hdd, nas, mediaplayer, timers, samba, raspbmc etc, etc.
Only things that are still missing rc input text and audio enabling 3d.
But in my opinion, always the best.


Re: Solo2 New Kernel 3.3.8-2.0 & OpenPLi #22 eozen81

  • Senior Member
  • 55 posts

+2
Neutral

Posted 21 May 2013 - 20:37

Keep watching the commit logs...

 

BTW what is it you need specifically from the new drivers?

 

With new drivers, "shaking subtitle" problem fixed aka deinterlacer problem fixed.

 

That's why I and lots of OpenPLi users are waiting kernel update.

 

For shaking subtitle problem, you can see my video below, this problem is fixed with latest drivers.

 



Re: Solo2 New Kernel 3.3.8-2.0 & OpenPLi #23 eozen81

  • Senior Member
  • 55 posts

+2
Neutral

Posted 24 May 2013 - 09:03

Hi all,

Still no progress about new kernel for Solo2?

Re: Solo2 New Kernel 3.3.8-2.0 & OpenPLi #24 Firex

  • Senior Member
  • 199 posts

+2
Neutral

Posted 24 May 2013 - 10:57

Hi Open PLi Team,

 

I also wait quite looking forward to an Open PLI image for VU+Solo2 with the new kernel and the new drivers, because I frequently make records of SD broadcasts (records with two receivers partially on different hdd`s - via dlan network SD just runs better ...) and the picture quality is supposed to have become significantly better with the new drivers just in SD area.

 

Is it already possible to say when we can expect (my favorite) Open PLi Image including the new kernel / the new drivers?

 

Regards



Re: Solo2 New Kernel 3.3.8-2.0 & OpenPLi #25 littlesat

  • PLi® Core member
  • 57,117 posts

+698
Excellent

Posted 24 May 2013 - 11:00

When ET/XT makes a driver update we receive a commit request from the manufactur. VU does not do this. So we need to commit for ourselves or wait someone gives us a proper working commit request. It seems that VU does not really support OpenPLi....so you should be patient here.


WaveFrontier 28.2E | 23.5E | 19.2E | 16E | 13E | 10/9E | 7E | 5E | 1W | 4/5W | 15W


Re: Solo2 New Kernel 3.3.8-2.0 & OpenPLi #26 Firex

  • Senior Member
  • 199 posts

+2
Neutral

Posted 24 May 2013 - 11:07

Not good news, but the/my hope dies at last ...

 

Nevertheless, many thanks for the quick reply.

 

Regards



Re: Solo2 New Kernel 3.3.8-2.0 & OpenPLi #27 AEPHFF

  • Member
  • 3 posts

0
Neutral

Posted 24 May 2013 - 12:22

Who wrote an angry letter Vu +, let's see whether or not the answer. We have nothing to do but all together peck their questions.



Re: Solo2 New Kernel 3.3.8-2.0 & OpenPLi #28 Rob van der Does

  • Senior Member
  • 7,766 posts

+184
Excellent

Posted 24 May 2013 - 12:36

Who wrote an angry letter Vu +, let's see whether or not the answer. We have nothing to do but all together peck their questions.

Why that? An image builder supports an STB (or not....), not the other way around....

How could you expect manufacturers to support all hobby-teams that build images?

 

And let's be honest: if an hobby-team finds supporting hardware not a hobby, why make an image at all?

 

Xtrend is a different matter altogether: as their OI is PLi based, they have of course a pull-request ready on every update of their drivers/kernel/whatever.

 

Anyway: other PLi-based images have the new kernel & drivers implemented weeks ago.


Edited by SatKiekerd, 24 May 2013 - 12:39.


Re: Solo2 New Kernel 3.3.8-2.0 & OpenPLi #29 MiLo

  • PLi® Core member
  • 14,055 posts

+298
Excellent

Posted 24 May 2013 - 13:24

Why that? An image builder supports an STB (or not....), not the other way around....

That have been explained to you a few dozen times now.

How could you expect manufacturers to support all hobby-teams that build images?

Well, uh, just like they have done in the past years?
 

And let's be honest: if an hobby-team finds supporting hardware not a hobby, why make an image at all?

Supporting hardware is my work. If any manufacturer wants me to support their hardware, they can call my employer and hire me at a very reasonable rate. I'd like to keep at least the illusion of keeping work and play apart.

Supporting hardware is more a "necessary evil".

Anyway: other PLi-based images have the new kernel & drivers implemented weeks ago.

So why doesn't any of them send back a merge or patch or whatever? If I fix something in Openembedded-core or in the Linux kernel, I push it upstream.
Real musicians never die - they just decompose

Re: Solo2 New Kernel 3.3.8-2.0 & OpenPLi #30 Rob van der Does

  • Senior Member
  • 7,766 posts

+184
Excellent

Posted 24 May 2013 - 13:52

Nope, you have not explained that at all. The only thing you keep repeating, is that you expect manufacturers to do the work for you. And saying/repeating is not explaining.

And I indeed still don't get it: either it's a hobby to make images for STB's (and you do it completely) or it's not (and then you don't do it at all). As I said: do you really think all manufacturers support all hobyteams? I can assure that that is not the case: hobyteams build images and hence support hardware just because of the fact that it's a hobby. And if others would do all the hard work, what has become of the hobby then?

 

And regarding your question about supplying patches: I have absolutely no idea about the way your team and other teams cooperate, so you might ask that question to them. I can't answer that.



Re: Solo2 New Kernel 3.3.8-2.0 & OpenPLi #31 Lost in Space

  • Senior Member
  • 876 posts

+69
Good

Posted 24 May 2013 - 14:03

You know what a fig leaf is used for in art ?

 

OpenPLi created a more or less legal fork of the enigma2 git from DMM some time ago.

 

From then all manufacturers could legally fork enigma2 from PLi.

 

From then for some manufacturers the fig leaf already did his job and they didn't need it anymore.

 

It is that simply and it doesn't make a difference if the fig leaf complains that the artist preferes now to paint nudes ...

 

Sorry for the wording, but it illustrates quite well was has happened here.


Edited by gutemine, 24 May 2013 - 14:04.


Re: Solo2 New Kernel 3.3.8-2.0 & OpenPLi #32 blzr

  • PLi® Core member
  • 2,270 posts

+118
Excellent

Posted 24 May 2013 - 14:24

OpenPLi created a more or less legal fork of the enigma2 git from DMM some time ago.

just curious, what was 'less' legal in this case?  ;)
 

From then all manufacturers could legally fork enigma2 from PLi.
From then for some manufacturers the fig leaf already did his job and they didn't need it anymore.

hmm, unfortunately your ornate metaphor can not be applied in vuplus case at all...
actually vu uses some antediluvian dmm e2 fork and more or less forked dmm's OE2.0 for their 'original' images...


True sarcasm doesn't need green font...

Re: Solo2 New Kernel 3.3.8-2.0 & OpenPLi #33 Lost in Space

  • Senior Member
  • 876 posts

+69
Good

Posted 24 May 2013 - 14:42

The timing when the leaf was used doesn't make a big difference.

 

More or less legal, is when drivers and loaders are re-distrubuted and when old versions of GPL Software is forked (as DMM and Plugin builders did some struggling changes during that time) and after this then by 'self' built commits it is kept in sync with later developments. 

 

And please let's not start the who copied from whom discussion, as this is not the point I tried to explain.

 

Sometimes you simply need a fig leaf for whatever (obvious) reason ...

 

If people would understand what has happened they would understand why we have the current situation and simply stop complaining - from both sides.


Edited by gutemine, 24 May 2013 - 14:44.


Re: Solo2 New Kernel 3.3.8-2.0 & OpenPLi #34 Rob van der Does

  • Senior Member
  • 7,766 posts

+184
Excellent

Posted 24 May 2013 - 14:43

From then all manufacturers could legally fork enigma2 from PLi.
From then for some manufacturers the fig leaf already did his job and they didn't need it anymore.

hmm, unfortunately your ornate metaphor can not be applied in vuplus case at all...
actually vu uses some antediluvian dmm e2 fork and more or less forked dmm's OE2.0 for their 'original' images...

Correct. And as far as I know only Xtrend forked PLi (even completely: their OI is simply PLi).



Re: Solo2 New Kernel 3.3.8-2.0 & OpenPLi #35 Lost in Space

  • Senior Member
  • 876 posts

+69
Good

Posted 24 May 2013 - 14:45

In some/catholic countries fig leaves are simply more popular :)

 

Start counting the inofficial forks and copies and how they behave and then you will realize that I'm right.


Edited by gutemine, 24 May 2013 - 14:46.


Re: Solo2 New Kernel 3.3.8-2.0 & OpenPLi #36 Rob van der Does

  • Senior Member
  • 7,766 posts

+184
Excellent

Posted 24 May 2013 - 14:46

If people would understand what has happened they would understand why we have the current situation

Well, feel free to do the explaining then.



Re: Solo2 New Kernel 3.3.8-2.0 & OpenPLi #37 Lost in Space

  • Senior Member
  • 876 posts

+69
Good

Posted 24 May 2013 - 14:49

Then read once more what I wrote. VU 'paid' Marusys to copy all the needed stuff including ho to make the camembert eatable and now that they have the code AND the knowledge they don't need us/you anymore.


Edited by gutemine, 24 May 2013 - 14:49.


Re: Solo2 New Kernel 3.3.8-2.0 & OpenPLi #38 Rob van der Does

  • Senior Member
  • 7,766 posts

+184
Excellent

Posted 24 May 2013 - 15:05

Ahh, I thought you were going to explain why DM went 'closed source'.



Re: Solo2 New Kernel 3.3.8-2.0 & OpenPLi #39 WanWizard

  • PLi® Core member
  • 70,371 posts

+1,807
Excellent

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


Currently in use: VU+ Duo 4K (2xFBC S2), VU+ Solo 4K (1xFBC S2), uClan Usytm 4K Ultimate (S2+T2), Octagon SF8008 (S2+T2), Zgemma H9.2H (S2+T2)

Due to my bad health, I will not be very active at times and may be slow to respond. I will not read the forum or PM on a regular basis.

Many answers to your question can be found in our new and improved wiki.


Re: Solo2 New Kernel 3.3.8-2.0 & OpenPLi #40 Lost in Space

  • Senior Member
  • 876 posts

+69
Good

Posted 24 May 2013 - 15:20

I know all this but this is history now and you and others served their purpose.

 

But instead of telling the war stories all over again and how great you did, you should realize what has happened and behave accordingly.

 

It is only my personal comment and advice, and I'm not singing anybodies song.

 

And made that ... is the important point - as now the others can take without giving - so why complaining on the problem you caused yourself ?


Edited by gutemine, 24 May 2013 - 15:23.



6 user(s) are reading this topic

0 members, 6 guests, 0 anonymous users