Jump to content


pop_eye

Member Since 16 Jan 2010
Offline Last Active 19 Oct 2020 01:08
-----

#545246 USB Tuners position

Posted by pop_eye on 29 April 2016 - 21:42

You could try playing with options in modprobe.

 

options dvb_usb_xxxxxx adapter_nr=2

options dvb_usb_af9035 adapter_nr=3




#543889 X11 Desktop fbdev

Posted by pop_eye on 21 April 2016 - 16:34

Following is a VideoCore IV GPU driver GPL driver implementation which can be adapted for other mailbox mechanism (if one has access to the closed source sdk and tries to adapt).

The main benefit that I see is Share the GPU by multiple applications which a full blown computer can provide.

 

http://maazl.de/project/vcio2/doc/




#384269 OpenPLi stops actively supporting Dream Multimedia STB's

Posted by pop_eye on 1 November 2013 - 16:14

Referring to an posting I made previously in Prismcube topic, to continue the idea.

 

Development of Enigma2 has not ceased as you may think. And you can see that in the current closed enigma2 branch as well as in Openpli

which have used the older source to improve on them - nothing bad with that.

 

Not discussing about the event view bars as one poster was trying to make as great addition but other features relating to dvb.

example: blindscan support,  new tuxtxt, usage of libvbi etc.) and other "small" things we all consider as necessary for an stb.

 

@ SatKiekerd - why you are not considering that as true development instead of nice skins and blinking lights with nice oled and graphics ?

 

dm8000 hardware was used as reference for competitors but even at today standards there are not many stbs available to compete for its status.

Why is that ? And you consider Vuplus as true developers..take another guess.

 

This is where all started: dm8000 entered the market and monikers waiting around the corner to grab the source code and run.

Is that true development ...they now call opensource ?

 

Let`s see who is laughing now.




#384069 OpenPLi stops actively supporting Dream Multimedia STB's

Posted by pop_eye on 31 October 2013 - 16:10

Openpli team, you have chosen not to answer this but please clear your arguments.

They are not as truthful as you are trying to sell here.




#384049 OpenPLi stops actively supporting Dream Multimedia STB's

Posted by pop_eye on 31 October 2013 - 15:25

yet another joke

my suggestion : first go to school then talk

do you even know the history of DBox ? or you're just another DMM's pet ?

 

for your own sake grow up !

yes I like jokes.

Especially the ones with copycats involved...

 

All that I see on this when I read you comments is: another cloner douchebag bragging rights for work he never done himself.

The sad part is that your complete mindset is done such way that you cannot resist spoiling others work.

Whatever , not here to change the world.

Do whatever you want..I see you are accepted for now.




#384045 OpenPLi stops actively supporting Dream Multimedia STB's

Posted by pop_eye on 31 October 2013 - 15:09

pop_eye: and DMM == DBOX2?

if

DMM == DREAMBOX

else

OPENPLI == ?




#384038 OpenPLi stops actively supporting Dream Multimedia STB's

Posted by pop_eye on 31 October 2013 - 14:59

The descision is final.

 

Contrary to most other images, we have our own codebase, and don't use a standard DMM image.

 

To keep this codebase compatible with DMM, we need access to the DMM source code, and we need the two codebases not to deviate from each other too much. In the past, with Enigma1, this worked well. We merged pieces of DMM's code, DMM cherry picked new features from us. Now that DMM decided to close the source on Enigma2, this is no longer possible, so it became more and more complex to maintain compatibility. DMM still seem to borrow new features from us (which is against the license but since their source is closed we can't prove they do), and implements these features slightly different so there is no compatibility anymore.

 

DMM clearly doesn't want "their" code to be used on other hardware platforms, and they don't seem to want users of DMM hardware to use other images then their own. So they closed the door.

With a high chance of getting banned on this board - which in my opinion does not matter anyway - since I do not really matter to the topic at stake - as I perceive this

matter on a different stance - (coverup would be better word for it), let me just say that "their" code is actually "theirs" and not "yours". You are only hiding yourself

behind GPL requirements , the same as they did when they decided to close it. When you mention the following in sentence "our own code base" , do you really understand the meaning ? Yes, in my opinion two wrongs are not making a good decision in neither case. What you fail to comprehend is that all the benefits you have taken for granted were not innovated or created by you, but by DMM...and all others are ripping and enjoying the benefits. It is exactly here you blatantly refuse to give credit where is due and at least maintain the common sense which everyone is expecting from you. The definition is a bit wider - everyone in this case are DMM users. But no issue with this since that is the reason we have "fork" and continue away from the praying eyes. Whoever is closing the door on you are the users....and this will always be against you. :P




#382367 Dd+

Posted by pop_eye on 24 October 2013 - 18:10

We know this patch is easy and in fact it was also very clean... but I think we will not do this anymore....

 

I would strongly recommend to ask DMM to change this to 0x22. This is the existing tender standard for several years...

 

But I'm scared arguing at DMM will have no effect and to date it might be too late... as likely we do not upgrade the drivers of DMM boxes anymore.

 

That DMM is using 0x6 indicates somehow that they are not willing to be compatible with our OpenPLi based images....

 

If 2 people make a decision saying that ac3+ should use 0x22 and that because the drivers used

are very similar in their essence...yeah, believe me or not driver teams are not very distinct as some are trying to portray here...

then suddenly we have " a standard". And this "so called standard" is the reason to completely bad mouth a receiver which by all means

is not suffering of missing codec but because of stupid integer value ?

 

I am not provoking any disbelief here, and your decision is respected..but please don`t say it load and clear that this integer value is a standard.

 

I do not believe you :P