malakudi

Following patch supports both zapmode and zapping_mode. I think the patch does not degrade enigma2 code quality.

I agree that it would be best for VU+ to use same variable name, but if the patch does not hurt the overall code quality, it doesn't do any harm, it just helps people that use OpenPLI. Do as you please.

Just to let you know, usb boot worked fine. It now has 4GB of / space

We even are preparing openpli4 now.. It is due to dmm doesn't support new kernel drivers that they are still on openpli2.1

Staying with 2.6.18 is only for one reason ... clones.

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 think you have original DM800SE, but you flashed newnigma2 image patched for some clone box. Use dreamup from DMM, flash SSL84, then flash image.

Where did you download this newnigma2 image you flashed?

Newest upatched OpenPLI images can be used in clone boxes that have the new SIM which is a DM800SE SIM clone. The key in SIM can be revoked, but it hasn't been revoked till today.

Question is: Why is the PQ with UFS 910/Original Software so much better than with e2?

PS: The PQ of my et9x00/e2 is equivalent to the PQ of the UFS 910/e2.

Have already answered that. The drivers for enigma2 images are not by STi. Official STi drivers support STAPI. Drivers for E2 images are built based on leaked source (called Havana Project) from STi that was never finished and was never supported. 3rd party people (team-ducktales, Tideglo for IPBOX and others) have improved the Havana project derived drivers, but still they do not perform as well as original STi drivers.

@Erik: Hardware does matter, but software drivers have to support the hardware options. Fot STi boxes with E2, we are talking about completely unsupported drivers from the SoC manufacturer, and people developing them don't have access to undisclosed chipset APIs for STi chips and reverse-engineering is difficult.

So I'd say, the major causes of the distortion in the chain are not in the stb, but in the camera and in the television set, actually. Both should be corrected (as far as possible) at the point they're occuring and not somewhere at a random point in the chain. Each part of the chain should always be as transparant as possible.

In very short, if there is something wrong with the picture, and all artificial distortions ("enhancements") are disabled, then the most logical place to look for problems, is where they are most likely to occur, and that's in the television set...

Although I agree with you, you are missing the point here. There are many reasons someone would want to have deinterlacing and upscaling in the STB and not in the TV set. Maybe TV set sucks at deinterlacing or upscaling. I've seen TVs that can't handle 576i as input from HDMI. It's good that an STB has an option to pass the original signal without touching it, but it is also good to have a great scaler with vector antialiasing and a great deinterlacer like adaptive bob+weave with motion compensation. So, you are defending Broadcom for it's ability to pass the original untouched signal (and this is good) but you are hiding the problem of the Broadcom chip that WHEN deinterlace and scaling is used, the quality is greatly degraded - or at least it is degraded more that other SoCs of other manufacturers.

So, instead of praising Broadcom for its passthrough untouched capability, we (as customers) should demand improved performance when it comes to deinterlacing and scaling. When you pay 650 or 900 euros for an STB (Vu+ Ultimo / DM8000) you demand the best.

The color problem (saturated reds) does exist, even if you deny it. I have configured my TV set and my projector for correct color representation (as much as it can be done) with a help of professional. Then, comparing playback of an MKV in Popcorn Hour (Sigma chip) and an MKV in ET9000 (Broadcom) and an MKV in IPBOX 9000 (STi chip), shows saturated red only in Broadcom. I would also like to find an explanation, but I can't.

@Erik: Not all content received by an STB can be displayed without proccessing in a TV set.
First of all, it is the SD content. You need deinterlacing (in STB or in TV - since the TV set features a progressive display) and upscale, in STB or TV or both.
The it is the HD 720p content. This doesn't need deinterlacing, but may need upscale.
Finally there is HD 1080i content. This might need downscale and it needs deinterlacing.

So, you always have some postprocessing. Being an owner of an STi chipset box (IPBOX 9000) I must say that the big difference is in the SD content. SD content is perceived better with an STi chipset box. Whatever the reason is, it does happen. For example, on my broadcom boxes i have noticed many times in fast scrolling text the fields to be reversed (thus jerky movement) and after 500-1000ms, the fields are reversed and text scrolling is smooth again. However, I've never seen that in STI boxes. I run the boxes in 720p mode when displaying SD content, so interlaced to non-interlaced transfom is happening to the STB. Same box (IPBOX 9000) with non-Sti dvbapi drivers performs much worse than Broadcom, which I assume is happening because of incorrect drivers.

Then, there is the color problem. You say that Broadcom does not change anything and I am not the one to tell you otherwise. However, what I perceive from Broadcom chipset boxes is saturated red, especially in human flesh. Colors seem better in STi boxes. I don't know why but that is what I see, and many people have the same experience, so I don't think there is something wrong with all those people.

open source is for freedom. Freedom of choice, freedom to change whatever you don't like. So please don't say to people what sucks and what does not suck.

That said, you also can't force the programmers to implement an option they don't like. You'll have to program it yourself.

What all this fuss is about? DMM just switched to newer kernel and adopted interesting features that were already available in their competitors' products. They didn't copy OpenPLI and OpenPLI didn't steal anything from DMM.

I guess 3.2 kernel will be available for DMM boxes on OpenPLI, when the support is mature enough.

For mkfs.vfat, you need to build dosfstools recipe. It is available in our openembeedded, haven't checked if it compiles OK.

edit: it builds and runs fine in my et9x00.
So recipe dosfstools just needs to be added in daily build.

root@et9x00:~# mkfs.vfat
mkfs.vfat 3.0.11 (24 Dec 2010)
No device specified!
Usage: mkdosfs [-a][-A][-c][-C][-v][-I][-l bad-block-file][-b backup-boot-sector]
       [-m boot-msg-file][-n volume-name][-i volume-id]
       [-s sectors-per-cluster][-S logical-sector-size][-f number-of-FATs]
       [-h hidden-sectors][-F fat-size][-r root-dir-entries][-R reserved-sectors]
       /dev/name [blocks]

The usage of hardlinks is an easy and very clever way to separate data of different events without having to do file operations (copy, truncate etc). When timeshift starts, PTS creates a hard link to the running timeshift file. When event changes, PTS starts timeshift ftom the beginning, zeroing the timeshift buffer and creating a new hard link. Previous hard link is still available and holds the data of the timeshift session of the previous event. Data in hard linked files is only deleted when all of the links have been removed.

systemtools for ppanels have a restart cam function. You can even create your own ppanel very easily to do whatever you want it to do.

Put attached file in /etc/ppanels

 restartcam.xml   216bytes   106 downloads

I have updated plugin.py to use dst_apply and seems to work fine now. I have one issue. I use startup service option and when I enable or disable splitscreen plugin, it changes to defined startup service, but I don't seem to understand why this happens.

 enigma2-plugin-extensions-splitscreen_0.3a_mipsel.ipk   2.19KB   105 downloads

No... i use default skin for openpli.... and i have two boxes original and clone ... pvr and mediaplayer work fine in original but in clone movie doesn't worked just Mp3 files work... why? this just plugin must be run on original and clone!

Your clone box uses old patched drivers that don't support the DVR interface. Get a box with correct support, either original Dreambox or boxes from VU+ and Xtrend