182 replies to this topic

[malakudi]

Sources for VU+ Solo2 are public. They don't need to deliver anything (at least from their point of view), they have their own developemnt tree, public. The problem is that their enigma2 code (called dvbapp) is much different than OpenPLI. So someone has to adapt the code to the OpenPLI tree. Core devs think this should be done by VU+. It seems VU+ has chosen their image of preference (Blackhole) since they also send pre-production boxes to BH team. Another problem is that usually VU+ makes "hacks" in their dvbapp code, hacks that would break other boxes if implemented globally. Instead of fixing things in their drivers, they hack the enigma2 source. So this is another issue that needs to be fixed.

Having a pre-release box myself to review it for a greek satellite tv magazine, I must say this is a very good box. Drivers are also OK, no major issues. So the biggest problem I think is the "hacks" they use in dvbapp.

People should ask VU+ to support OpenPLI, not the other way around. Or, if someone really wants it, he can fork an OpenPLI code and support VU+ Solo2. All sources are public and GPL, so go ahead.

Edited by malakudi, 22 December 2012 - 15:42.

[bacicciosat]

If I was manufacturing an engima based box, before releasing it in public I would send preproduction models to some lead programmers of popular opensource images.
Along with latest drivers and request to give some feedback. Once the box is released the customers can enjoy their new toy with the image of their choice.

But perhaps this is already done but the drivers are still crap?!

And don't think that the world is too small.
You should know that there are teams that have received preproduction models.
This is not an argument because the private issues about teams and companies are confidential.
I have never read an offence of Pli team against Vu+ because Pli team is polite also if Pli could be not happy about Vu+ support i think that they are wise person that don't need to offence or to blackmail a company.

Edited by bacicciosat, 22 December 2012 - 15:41.

[theparasol]

I know pli team is polite and correct. My reply should not be read as criticism but merely a hint how to make things better / avoiding the situation box released but no broad image support.

Ok, understand now that implementation is complicated due to fact that vu+ is hacking instead of sound rewriting the dvb app.
I can understand that coders are thinking: I'm not going to clean the shit for this manufacturer, they should do the correct implementation themself instead of hacking around
and launch it to the world. Most coders are doing it in their free time and that free time should go to innovation instead of doing the dirty work for others.

[bacicciosat]

I know pli team is polite and correct. My reply should not be read as criticism but merely a hint how to make things better / avoiding the situation box released but no broad image support.

Ok, understand now that implementation is complicated due to fact that vu+ is hacking instead of sound rewriting the dvb app.
I can understand that coders are thinking: I'm not going to clean the shit for this manufacturer, they should do the correct implementation themself instead of hacking around
and launch it to the world. Most coders are doing it in their free time and that free time should go to innovation instead of doing the dirty work for others.

Ahh this is your idea to be correct and polite ?
congratulations. You don't help companies users and teams in this way.
Vu+ have his own git and are developing hbbtv transcoding and other features. It is normal that it is not easy to implement like other companies that don't invest money and don't have any kind of own sources.
It is easy to support that kind of companies. Yes there are not compatibility issues.
But this is not positive.

[bacicciosat]

By the way i don't want to improve any kind of flames here.
I hope only that here at Pli board there will be not another campaign and offence against Vu+ like seen in other places.

Because i have great respect for Pli team and Pli work i hope that Vu+ will support Pli in the better way as possible in the future because the Pli support to Vu+ products is important for all the sat community.
Pli is an aexample and a guide for many other teams (also for many that seems are forgetting now).

[theparasol]

Ahh this is your idea to be correct and polite ?
congratulations. You don't help companies users and teams in this way.

I'm for sure never correct and polite. I know my shortages
I'm also not a member of pli-team so I can never speak for them.
Since I'm not an experienced coder there is little I can do to support the VU+ community right

[bacicciosat]

ok theparasol excuse me and sorry if i have misunderstood your words.

[litemotiv]

I hope only that here at Pli board there will be not another campaign and offence against Vu+ like seen in other places.

OpenPLi is impartial to any manufacturer. If they would like to see their hardware supported and are able to provide the right materials needed to make a proper open source release, then they are welcome to approach us. So there will not be an anti-Vu, or anti-whatever campaign on these boards, and if any thread tends to derail into a rant- or troll topic targeting a specific manufacturer, it will be closed.

[bogdanm]

guys, good advice - stay away from marusys and vu+, wait when other more responsible manufacturers release new products

WHY ?!?!?! I have VU in my home and this is great box.On this box work all whot im used.My box have now more 2 year and hsi hardware is good too.

[atilaks]

read about problems with sundtek tuners, what sundtek wrote about marusys, about problems with mem leaks, and where are drivers for kernel > 3.1?

i do not want to offend anyone, just sharing some info with you, and I do own vuduo myself

[littlesat]

As far I can see the new VU boxes do run on kernel 3.3.6... correct me if I'm wrong...

[Ev0]

As far I can see the new VU boxes do run on kernel 3.3.6... correct me if I'm wrong...

Yes the solo2 is on kernel 3.3.6

[atilaks]

You are right, I wasn't precise enough. I was referring to all previous models like ultimo, uno. They were released in 2011, but it looks like Marusys has not enough manpower to focus on new products and maintain released ones

[littlesat]

And even 3.3.6 is not the latest.... While ET is running on 3.6.0 and XP on 3.5.9.....
But we never know if VU will also migrate to later kernels....

Edited by littlesat, 22 December 2012 - 17:22.

[Ev0]

You are right, I wasn't precise enough. I was referring to all previous models like ultimo, uno. They were released in 2011, but it looks like Marusys has not enough manpower to focus on new products and maintain released ones

Why delay the release of a new product just to update the kernel of the older models ?

They can update the Solo, Duo, Uno and Ultimo kernel to 3.3.6 at a later date if they see fit surely ??

[atilaks]

I am waiting long enough for Marusys to upgrade from 3.1. I am not complaining about new drivers for kernel 3.3 were not released now for other boxes. I am complaining that drivers for 3.1 were released one year ago and since then they were more focused on developing xbmc based box and other boxes like solo2, then solving problems people or other companies (like sundtek) were reporting to them.

but again, this is my humble opinion, not everybody has to agree with me or follow my advice... it is a free world

Edited by atilaks, 22 December 2012 - 17:29.

[MachIII]

Sources for VU+ Solo2 are public. They don't need to deliver anything (at least from their point of view), they have their own developemnt tree, public. The problem is that their enigma2 code (called dvbapp) is much different than OpenPLI. So someone has to adapt the code to the OpenPLI tree. Core devs think this should be done by VU+. It seems VU+ has chosen their image of preference (Blackhole) since they also send pre-production boxes to BH team. Another problem is that usually VU+ makes "hacks" in their dvbapp code, hacks that would break other boxes if implemented globally. Instead of fixing things in their drivers, they hack the enigma2 source. So this is another issue that needs to be fixed.

Having a pre-release box myself to review it for a greek satellite tv magazine, I must say this is a very good box. Drivers are also OK, no major issues. So the biggest problem I think is the "hacks" they use in dvbapp.

People should ask VU+ to support OpenPLI, not the other way around. Or, if someone really wants it, he can fork an OpenPLI code and support VU+ Solo2. All sources are public and GPL, so go ahead.

I will mail Vu+ and ask for continuous OpenPLI support, hope many other OpenPLI fan will do the same...

[bacicciosat]

Why you don't ask to dmm to to change their sources to be compatible with Pli ?
I think you are not in the right direction here.
Vu+ have their own git and develop features.
You cannot think it is like the other minor companies without own sources.

But everyone is free to think and act like he prefer and this is only my opinion.

[malakudi]

Why you don't ask to dmm to to change their sources to be compatible with Pli ?
I think you are not in the right direction here.
Vu+ have their own git and develop features.
You cannot think it is like the other minor companies without own sources.

But everyone is free to think and act like he prefer and this is only my opinion.

If you ask my opinion, OpenPLI should stop supporting DMM boxes since they decided to walk the closed-source way.

VU+ should at least base their "dvbapp" to OpenPLI sources. The e2 code they used in "dvbapp", is lacking many options available in OpenPLI's E2.

Edited by malakudi, 22 December 2012 - 19:46.

[theparasol]

If you ask my opinion, OpenPLI should stop supporting DMM boxes since they decided to walk the closed-source way.

I dont think openpli should do this. In my opion this will only polarize the image scene further.

As long there are drivers for the boxes, the dreambox users that choose to use openpli instead of the manufactures
closed source image should be able to do this.

VU+ should at least base their "dvbapp" to OpenPLI sources. The e2 code they used in "dvbapp", is lacking many options available in OpenPLI's E2.

Does anyone happen to know if this has anything to do with lawsuites in the past of dream against using enigma by other manufacturers?

Edited by theparasol, 22 December 2012 - 20:09.