Forums

I start this topic, more as discussion to make things clear.
I hope that other DM8000 users can post here too. So keep in mind, this is a DM8000 topic.

About ten months ago i was a fanatic openpli end-user. Then DMM starts with closed source.(don't want to start the discussion why).
Result was that Openpli added more and more features to their images, with exception of the ones for the dreamboxes.
I also don't want to start the discussion if it was good or bad of pli. I'm prefer to talk about the result that we have now.
OpenDreambox OE2.0 on a Dreambox, or Openpli, both latest versions.

I know that OpenDreambox offers me the following extra's: BluRay play(unprotected), BluRay/BDMV record, blindscan, webbrowser, hbbtv.
Of course you use a addon like the Geminiplugin 3.2 so that you also have plugins like crossepg, oscam.
At the moment OpenDreambox is stable enough to use. A time ago it had a tuner driver issue, that the signals where received like minus Decibel, and after a say 10 seconds positive decibel and working television. But that is solved now.
Also I don't use a swapfile, and the DM8000 is working fine with Opendreambox.

When I look here on openpli website (yes i do check it once in a while) then i see lots of topics about issues with DM8000 and openpli. Like the need of a swapfile and so on.
Then I wonder like, what is added that makes openpli so big? Now keep in mind my last openpli experience was 2.0, but I always liked openpli because it was default a light/lite image. That was for my experience very efficient with the hardware. What happens?

Yesterday I was thinking like, do I really use the closed source addons that Opendreambox OE2.0.x offers me?
It's fun that it can be used, but i realise it's like once in a month that i burn HD movies to a BluRay disc, so that someone else can play like 5 HD movies on a single bluray disc on a bluray player at their home in equal quality.
Blindscan is also something that i don't do often. Only when i read somewhere that their is a new channel, not to receive with automatic scan.
The webbrowser and hbbtv are often updated, and i must say they react fast enough now that you don't gert bothered.
But then again, if i need a webbrowser then i use my computer webbrowser. And hbbtv is fun, but not really something i need to have, because you can view the content also on internet with computer browser. And because i have computer and DM8000 in same room...well you know.

So is it possible that a DM8000 user with uptodate openpli tell me what their experience is? Why does it need a swapfile(in my opinion something that i prefer not to have because of slower preformance, what is logical if you understand how swapfile works). What makes openpli so big that it needs a swapfile, can it be more lite? Is it stable enough to use every day?

I'm jst curious, and not in the mood to keep flashing images all the time (my wife want to watch dvb-s2 without issues), and the DM8000 is the only DVB receiver here in the house.
Edited by J3r03n5ky, 25 January 2013 - 11:58.

The issue with dm8000 running out of memory is a problem with NFS/nic present in all "modern" kernels, it just shows sooner than other boxes as dm8000 doesn't have that much RAM memory (although it's sufficient).

This has nothing to do with whatever image or even what brand/type stb.

So the postings here of users who need swapfile on openpli3.0-DM8000, is of users who use so much plugins as it is a christmas tree ?
How much memory is free when openpli is default installed?
And another thing, I understand that most openpli developers don't have a DM8000 anymore. Does that influence the result of openpli3.x images stability on DM8000 boxes?
Edited by J3r03n5ky, 25 January 2013 - 12:19.

Result was that Openpli added more and more features to their images, with exception of the ones for the dreamboxes.
I also don't want to start the discussion if it was good or bad of pli.

This is a very odd statement. Those features are closed source, not released into the public domain by Dream Multimedia GmbH, and therefore not available to OpenPLi.

Your statement gives the suggestion that we actually had a choice in the matter. Which we haven't.

And another thing, I understand that most openpli developers don't have a DM8000 anymore. Does that influence the result of openpli3.x images stability on DM8000 boxes?

They're not using it on a day-by-day basis, that's something different from "don't have".

So the postings here of users who need swapfile on openpli3.0-DM8000, is of users who use so much plugins as it is a christmas tree ?

No, the problem is that:[list]
[*]the new 3.x kernels and NFS settings will negotiate very large buffers when creating a connection via TCP (up to 128Kb). The old stone-age 2.6.18 kernel didn't do that
[*]the Broadcom closed-source network interface card drivers don't support fragmented memory (scatter/gather), so these buffers MUST be in one consecutive block in memory
[*]the DM8000 doesn't have much RAM, so the longer the box is running, the less likely it is that such a consecutive block can be allocated
[/list]
Solution:[list]
[*]use UDP (it doesn't use very large blocks)
[*]define a fixed block size on your mount command when using TCP, which a smaller blocksize (for example 4Kb or 8Kb)
[/list]
The last requires some testing, to find the optimal buffer block size, because it depends on your usage of the box, how much plugins are running, their memory usage, how you use your EPG, etc.

All of which have been mentioned several times, so should be no news.

Result was that Openpli added more and more features to their images, with exception of the ones for the dreamboxes.
I also don't want to start the discussion if it was good or bad of pli.

This is a very odd statement. Those features are closed source, not released into the public domain by Dream Multimedia GmbH, and therefore not available to OpenPLi.

Your statement gives the suggestion that we actually had a choice in the matter. Which we haven't.

I'm sorry. I did my best to be polite in this sensitive topic.
What i do know is, that their are more images who build on OE2.0 (like Newnigma2, Oozoon, Merlin3, LT have for example images build on OE2.0 and closed source parts)

I also wrote that i don't want to start the discussion "why". I only want to know what the experiences are between OE2.0 based with closed source and openpli without.

Good to read that their are still DM8000 in use at the developers.
Keep in mind i try to be as polite as possible, and i'm just a end-user.
Edited by J3r03n5ky, 25 January 2013 - 12:28.

All of which have been mentioned several times, so should be no news.

But fragmented all over this forum. Hard to find for me.

So the postings here of users who need swapfile on openpli3.0-DM8000, is of users who use so much plugins as it is a christmas tree ?

No, the problem is that:[list]
[*]the new 3.x kernels and NFS settings will negotiate very large buffers when creating a connection via TCP (up to 128Kb). The old stone-age 2.6.18 kernel didn't do that
[*]the Broadcom closed-source network interface card drivers don't support fragmented memory (scatter/gather), so these buffers MUST be in one consecutive block in memory
[*]the DM8000 doesn't have much RAM, so the longer the box is running, the less likely it is that such a consecutive block can be allocated
[/list]
Solution:[list]
[*]use UDP (it doesn't use very large blocks)
[*]define a fixed block size on your mount command when using TCP, which a smaller blocksize (for example 4Kb or 8Kb)
[/list]
The last requires some testing, to find the optimal buffer block size, because it depends on your usage of the box, how much plugins are running, their memory usage, how you use your EPG, etc.

Is it possible that openpli image has the solution default configured?

We are working on a solution, which can be expected any day now. It's not as simple as it sounds.

You can not build a proper image on DMM's closed source OE2.0.

You don't have access to the source, so the only thing you can do, is add some window dressing (skins, some fiddling in the python code). You can not make significant improvements (because that requires access to the closed C++ code, and that code is not available), and you can not add significant new features (for the same reason).

We at OpenPLi build our own image, based on our own OE version, and our own Enigma code. For the simple reason that we're not window dressers like most of the other image builders. On the contrary, we don't like window dressing at all (the christmas tree as you referred to it earlier).

Now, Dream Multimedia GmbH has, in (imho) a last desperate measure to retain some of their customers, decided to no longer release their source code. It is their right to do so, and by doing so, they have created an impact on users that have bought their (overpriced) products, but want to run alternative software.

Which means that it is up to you, as a DMM customer, to decide what to do:[list]
[*]stay with the original software, or use one of the window dresser images
[*]stay with OpenPLi, and accept it does not provide the same feature set as the DMM image
[*]sell your box and buy something else
[/list]
In neither of these choices OpenPLi is involved. Most of us went for the last option (when it still had a bit of value)

I bought my first DMM box because of the value opensource...I accepted that the drivers were still closed source...

Since in fact May 2011, so almost two years ago, it looses this added value almost completely....
Edited by littlesat, 25 January 2013 - 14:43.

I don't use swap and have no problems with my box.
I do have problems with my leds but those problems i have also with the original image.

As long as Openpli support this box ,i will use it.
And when there's something wrong with something ,ha!!!! that's just the fun of it

Tried all OE2.0 images and keep coming back to openpli, everything works like it should and I use swap file only because I have many plugins.
Last time I had a green screen was erm.......oozoon.
It's not all about the image the forum works well too, you can ask whatever you want without feeling stupid or you should be asking in German !

Well, this is a little bit like the 'Windows XP' is the best threads :-)

the Broadcom closed-source network interface card drivers don't support fragmented memory (scatter/gather)

actually, they are opensource.
should be fairly straightforward to implement scather-gather, but not a lot of people care, because the issue only affects nfs users

I do have problems with my leds but those problems i have also with the original image.

explain the led problem, because i don't know what you mean. (I\m a OE2.0.2 user)
Edited by J3r03n5ky, 26 January 2013 - 21:47.

Well, this is a little bit like the 'Windows XP' is the best threads :-)

Totally offtopic. Because i wonder, what is xp then.
It's a big difference in function support. Both are updated (and so bugsolving) frequently.
Edited by J3r03n5ky, 26 January 2013 - 21:50.

well, the commits speak a different story. If you read there how much and what PLI actually changed in their 'open source' C++ part then we would need to agree that this is not an really exciting story if you consoder the time you had for progress. And if your quota is bugsolving ...
Edited by MostlyHarmless, 26 January 2013 - 22:24.