malakudi

Installed VTI 8.2 to test what is going on. There is no external application or different driver. The CI+ authorization is done from enigma2 binary. We find some string references like:

CIHost_CIPlusAuthenticationSuccess

CIPLUS [TBD] AuthenticationSuccess %d %x

Well after all very nice here in openpli.

 

1) A betateam member with an own new developed theorem 180 degrees against the rest of the world The malakudi theorem.

2) A Core member with suppositions out off his fantasy the Erik thaughts.

 

3) A real experienced C/C++ Core member Pieterg wich really does everything to counteract any possible evolution.

 

No wonder that after 1 year and a half there is still not 100 % ok gst-1.0 image.

 

So, what are you still doing here? Why are you waiting for others? Fork OpenPLi and build your Christophecvr image. We are all counting on you. If you can code as well as you can hear ultrasounds, it will be a great image.

@christophecvr: You misunderstood what I wrote. I know your patches are for the gst-1 branch. But since there is no daily build of experimental images for people to try, the progress in using gstreamer 1.4 will take some more time. Anyone who wants it "right here, right now" can of course fork OpenPLi and start building and distributing test images for people to try.

About your patch, it is clear that OpenPLi core team do not want to implement code with (if dreambox, if vu, if whatever), unless absolutely necessary. While you can disagree with this approach (and I have disagreed in the past), you can't change their point of view. In OpenPLi's point of view, the hardware manufacturers should make their drivers (the only thing they develop after all) "compatible" with OpenPLi and not the other way around. So, the ifdef dreambox etc is difficult to get in the code.

 

edit: and if VU+ does indeed make their drivers compatible like it seems they are going to do, then only dreambox will not be supported, which, of course, we don't care. They choose the path of not being open source.

Linux is not Gnome, KDE, Unity or whatever. Linux is also not Ubuntu, Fedora etc. Linux will conquer the desktop eventually or desktop will become irrelevant. Linux has already conquered the server market, the mobile market (Android), the embedded market (STBs, routers etc etc)  and is coming to laptops (ChromeOS). This is why in the end, Microsoft will die.

 

Saying Unix is something from 60s that will never get to desktop is rubbish. MacOSX is Unix, and the GUI is quite intuitive. As soon as M$ dies, Unix will be everywhere.

 

I personally use Windows (7) on my desktop, Debian on my storage/nas server (with Gnome but I rarely use it), Android on my phone, MacOSX on my laptop, android on my tablet. So I am not biased for one or another. I use them all.

If DMM's enigma2 has added support for native (that is non gstreamer) support of MPEG-TS streams over UDP or RTP, multicast and/or unicast, I think OpenPLi should add this too. Until it is added, udpxy (which converts udp/rtp multicast mpeg-ts to http mpeg-ts) is a very nice option. We could also add udpxy in the feed.

Lamer is a jargon or slang name originally applied in cracker and phreaker culture to someone who did not really understand what he or she was doing. Today it is also loosely applied by IRC, BBS, and online gaming users to anyone perceived to be contemptible. In general, the term has come to describe someone who is willfully ignorant of how things work.

http://en.wikipedia.org/wiki/Lamer

 

Maybe not lamers, since they do understand how enigma2 works. But indeed lamers since they don't understand how GPL works. And VU's enigma2 is a fork of DMM's enigma2, so licensed under GPL. Release your sources if you don't want to be called lamers.

 

 

 

@paokgate4: Those channels, although they are encrypted with constant CW (like BISS), they do not carry any info in their PMT that they are encrypted. Most emulators that read PMT, interpret them as FTA. Enigma2 also thinks they are FTA, although enigma2 has nothing to do with descrambling - it is the emulators job. mgcamd works because it tries to descramble the channel even though the PMT carries no information about the program being encrypted.

Guys this has nothing to do with HD pairing. Sly are transmitting these channels in the new H265 codec. If you are like me and have your card paired to an old Thompson HD box and prefer to use a VU/another Linux box then you will lose these channels. This is because no one has yet released the H265 codec. Now many are saying that (for example) the VU Duo can’t handle the new codec.....Well that's hard to believe as Sly have managed to upgrade 5 year old HD boxes to handle the new codec mmmmmmm come on someone, let's get this sorted.

 

Channels are transmitting H.264 as always. The only thing changed is that the CWs now need a post-process key (usually AES or 3DES), also known as chipset pairing. I can decode H.265 streams wih ffmpeg on my PC and those streams are NOT H.265.

@SpaceRat: Replying with such language will not help you. Expressions like "bullshif" etc cannot make other people try to understand and help you.

 

@WanWizard: The "problem" is that the enigma2 internal web server on port 8001 does not support simple http auth request. So, SpaceRat and others complain because original streamproxy was removed by something inferior in their opinion - since it does not provide http basic auth support. If we would implement http basic auth on the internal web server, it would be OK.

 

In my opinion http basic auth is useless. If you want security, setup a tunnel with your box. openvpn, ssh tunnel, whatever. http basic auth is no security.

kernel modules run in kernel space.

Just for the record, the TPM board of Xtrend IS prone to failures. Actually the big problem with them is that ALL such boards will fail in the future, leaving a dead box. I currenlty have 2 ET5000 and 1 ET6000 with dead TPM board due to battery failure. All three boxes failed when the boxes stayed out of power supply for 7-10 days, about two and a half years after they were bought (so out of warranty). Why should I pay for fixing those? It is a flawed by design TPM solution that will fail ALL boxes sooner or later - the battery doesn't live for ever. What Xtrend should do is to provide drivers without the TPM checks for all those owners with broken boxes. Until it does, I am not considering buying Xtrend boxes EVER again - even though I recognise their driver support is superior to the VU+ Solo2 I am using now.

I completely support the decision of the core team. DMM is the one that abandoned the principles of open source, so it was time to anandon DMM. They also abandoned their DM800 customers - no new drivers for them. v2 boxes are irrelevant anyway, they are just offering what competition offered years ago (PiP/larger flash/Web browser/HbbTV). Changing a flash chip and a ram chip is no new hardware from DMM.

 

And because I've read some rediculous comments in the dreambox forum about OpenPLi and DMM clones, someone has to inform them that clones with A8P and recently SIM 2.x can run DMM closed-source images just fine. So they don't "need" OpenPLi.

@buyukbang: Please upload your ipk with .py source file and without those postinst scripts. This is a board and an image that respects open source ethics and open source movement in general.

 

I understand someone would like to give binary only versions of a python or other type of source, if the source is a work he expects to be paid of. I am sure that with this plugin you don't expect something like that. If you enjoy enigma2 and linux that, as a project, have hundred of thouisants lines of open source, you should give your plugin as open source. You will still get the credit you deserve, don't doubt thsat. Open source community respects the work of any individual, even if it is a few lines of code.

 

@gutemine: Even if there are tricks to confuse python decompilers (and there are), what's the purpose? Try to realise what python for enigma2 is all about. It's about easy changes in enigma2. Changing things without need of a full build system.

 

And, IMHO, no enigma2 python plugin, blue panel, extension or whatever deserves to be binary only. Respecting the spirit of enigma2 and open source requires delivering sources. If you don't like sharing, don't mess with linux, enigma2 and open source in general.

Why would anyone want to mix kernel binary from one image and kernel modules (usb dvb-t, wifi, iptables, ipsec, ipv6 etc) from another? This will only lead to unsupported configurations, and if there is a bug nobody could help.

Is there a feature in new DMM drivers that someone would really want to have it rignt now and not wait till these changes get imported to OpenPLI's kernel? My DM800SE works fine with current OpenPLI drivers.

I truly understand the point of view of the developers. It's their work and they are not willing to make VU+ any favors. It's VU+ fault, they should fix it, I aggree with that. But still, I would like to help those users that bought VU+ Solo2 to experience the superiority of OpenPLI. OpenPLI drives the advancements in enigma2.

What if I could provide a kernel module or userspace utility that goes between enigma2 and VU drivers, fixing wrong reporting about the remote? (capturing ioctl or something - it is not clear to me right now how this could be done) Would this be accepted?

edit: I have an issue with vtuners on VU+ Solo2. When restarting enigms2, sometimes USB DVB-T tuner is shown as multituner (supporting DVB-S/DVB-T/DVB-C). It usually happens if I do init 4; init 3 . Further restarting enigma2 doesn't help, you need to reboot box.