WanWizard

For those building their own images from our sourceforge repositories:

The URL's of the repositories have been changed due to a migration to the new SourceForge Allura platform.

Change the origin of your local repo's from git://openpli.git.sourceforge.net/gitroot/openpli/<repo-name> to git://git.code.sf.net/p/openpli/<repo-name>

We are aware things work (different) in the original image.

Issue here is that the drivers, supplied by VU+, report the wrong RC type. The original image has hacked it's way around that in the Enigma2 code, which they can do, because they only have to support one brand. We have to support over 15 different brands and models, so hacking is out of the question. It will lead to code that is no longer maintainable. The vendor must fix this.

If the vendor doesn't do that, maybe OpenPLi users should not buy a VU+. A vendor has to listen to it's customers if it wants to make money.

So (as Hemertje already implies) it's not a PLi issue, it's a driver, and therefore a vendor, problem.

It gets worse.

USB 2.0 has a theoretic maximum speed of 480 Mbit/s, so not even half of the gigabit speed required. And in real life you'll never get to this speed on the box.

However, if you connect this to a gigabit switch, with a gigabit connected server or NAS on the other end, you potentionally get a lot more data in than the device can process. Which will lead to retransmissions and drops, which in turn will lead to buffering issues which will cause drops in your recordings or streams. So, a bad idea.

100Mbps is more that enough for 5 to 6 very high-end HD streams, so that should not be a problem.

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.

Diese Diskussion bringt nichts nützlich. Nachrichten entfernt und Thema geschlossen.

Eh, not open source? You are aware that virtually everything in the image is GPL licenced, which means you are required to open source your code?

if you are willingly violating the license, this discussion has no place here, and I would like you to refrain from mentioning it again. We do not condone license violations!

It doesn't really help that people complain elsewhere, we're not omnipresent. Like it doesn't help complaining to your butcher that the bakers bread isn't good...

Report issues here, document the issues, provide crash logs and how-to-reproduce steps, and we might be able to fix it. If you don't, then the issue does not exist.

there is no pli 3.0 there they are all 2.1.

All boxes have a OpenPLi 3.0 version, except the DM800 (not SE) and the DM7025. As far as DMM is concerned they are end-of-life, no new kernel drivers have been released for these boxes.

We have decided not to.

The basic principles we already apply for years, so for us there is nothing new.

We do have an issue with the philosophy behind it, we don't like hack and patch work. We are absolutely focused on a clean and stable OE core, which is impossible with everyone having write access to the repo. If not very stricktly managed it will become a mess. And as far as I can see it isn't. Try to imagine all linux develops having write access to the kernel repo...

Zou wel moeten ja, de mirror die op deze server draait is weer in sync.

You seem to forget that all this code is GPL licenced, which EXPLICITLY allows you to borrow. Just like VIX borrowed the ENTIRE OpenPLi image.

This is perfectly fine, this is how Open Source works. You borrow from me, I borrow from you, and together we both have a better product then before. If that is not fine, write closed-source code (in which case you are not allowed to use anything from OpenPLi or Enigma2, the license strictly forbids that!).

Let's be honest, if OpenPLi had never decided to honour the GPL license and make all their sources public, then today there would not be a VIX (or any other OpenPLi based image).

I don't have a problem with you, Vixfan, but this is not the VIX fan site, so if you don't have anything constructive to add to this conversation, I would suggest you leave it at this.

In principe komt de EPG data van de provider. Die kan dat er zelf op steken, of het kan van een andere provider komen (bv omdat de zender wordt ingekocht).

Die data arriveert op de box of in een open/standaard formaat (zoals bv EIT) wat Enigma2 snapt en kan verwerken, of in een propriatair formaat (bijvoorbeeld het OpenTV systeem van Sky UK) waar we niets mee kunnen.

Het is ook de provider die bepaalt voor hoeveel dagen EPG data er mee gestuurd wordt. Wat pieterg bedoelt is als de provider 7 dagen mee stuurt, en jou box die binnen heeft, dan kan deze in principe 6 dagen niks meer sturen zonder dat je dat in de gaten hebt (tenzij je natuurlijk vooruit opnames gaat inplannen). Die 6 dagen stonden immers al lokaal op je box.

En dan heb je nog data van alternatieve bronnen, waarvan XMLTV wel de belangrijkste is. Deze data wordt door een groepje vrijwilligers op het internet bij elkaar gesprokkeld, en in een dusdanig formaat gegoten dat Enigma2 er wat mee kan. De betrouwbaarheid van die data staat of valt natuurlijk met die van de website waarvan het gehaald is, en dat kan nog wel een fluctueren. Daarnaast willen deze sites nog wel eens layout aanpassingen maken, waardoor het "scrapen van de informatie" van die pagina's mislukt en je dus geen data hebt totdat de vrijwilligers het probleem hebben aangepakt.

I don't think this is needed, the battery will easily last 10 years, even with the box switched off for they entire period.
The issue here is about a percieved technical defect that might or might not occur.

I think we can talk about it until we're blue in the face, but other then complain about some guesswork we can't do, and therefore this discussion isn't very meaningful.

So let's leave it at this, until there is some positive evidence and we can re-open this discussion.

Have you plugged in your SKY smartcard? The correct way? Have you installed a softcam (CCcam will do fine) to read the smartcard?

Het is een wijdverbreid misverstand dat de kwaliteit van een netwerk te maken heeft met poortsnelheid. Niets is minder waar.

Een hele vette HD stream (pak bijvoorbeeld Sky F1 tijdens een live uitzending) komt binnen vliegen met 16Mbps + AC3 5.1 audio. Die past dus wat bandbreedte betreft zonder problemen in die 100Mbps die je ter beschikking hebt.

Probleem is latency (de vertraging die door alle componenten in de ketting wordt veroorzaakt) en jitter (variaties in die latency). Het is namelijk essentieel dat het volgende frame volledig in de buffer zit voordat de box klaar is met het huidige frame. Als dat niet zo is dan ervaar je dat als gestotter, de box staat met een lege buffer op 't volgende frame te wachten terwijl de tijd doorloopt.

Om een voorbeeld te geven: de effectieve beschikbare bandbreedte op een 100Mbps link bij 75ms latency (en industry standard packet size distribution), zelfs met 0% packet loss, is slechts 6.99Mbps! Dit komt omdat er zoveel vertraging op de lijn zit dat zender en ontvanger meer op data staan te wachten dan dat ze versturen cq ontvangen.

De clou van dit verhaal: als je dus flut materiaal hebt dan kunnen de poorten wel 100Mbps zijn, maar kan het best zo zijn dat het switch materiaal dusdanig beroerd is dat er veel variatie in de latency zit, eventueel zelfs met packet drops, als er veel data door de switch moet.

Ik heb hier ook altijd low-budget spul gehad, wat altijd wel redelijk werkte (in de SD tijd), hoewel ik soms ook opnames met hikjes had (ik neem op een centrale server op). Totdat ik een 100Mbps internet pijp kreeg, en deze vanaf mijn PC (die achter modem en twee switches zit) bij lange na niet die 100Mbps vol kreeg (speedtest). Ik heb nu gigabit switches van Netgear staan, en server -> PC trek ik zonder problemen meer dan 900Mbps.