Hier wel hoor en werkt gewoon.
Cobus laat ons op 2 juli van dit jaar keurig weten dat OpenPLi6.0rc dat het op een Xtrend 10K gewoon werkt, misschien raadzaam voor sommige om deze release/datum te gaan gebruiken.
Laten we maar even terug on topic gaan. 
Ik zal proberen e.e.a. uit te leggen om het voor jullie duidelijker te maken.
Het probleem is de volgende:
De default instellingen van de drivers is dat er overscan wordt gedefinieerd voor de OSD, iets van 20 pixels rondom. Daarom krijg je bij alle skins een rand rondom (ongeacht het type skin) te zien, als op je TV de overscan is uitgeschakeld. Als je TV wel overscan doet, dan is die groter dan die 20 pixels, en dan zie je er niks van (en heb je ook geen probleem ).
Om dit op te lossen is de overscan wizard bedacht (OSDpositioning plugin). Zodra Enigma opstart zorgt deze er voor dat die 20 pixels op nul worden gezet, waardoor de skin keurig tegen de randen van het beeld wordt gezet, en waardoor een full screen OSD mogelijk wordt. In de meeste gevallen, en bij de meeste mensen, werkt het tot zover prima (als in: de driver bug wordt niet getriggerd). Niet bij allemaal, sommigen rapporteren de fout ook al bij het opstarten, bij een herstart gaat het dan soms weer wel goed.
Echter, zodra je de overscan wizard in gaat, en gaat resizen, dan wordt voor elke aanpassing een update van de OSD coordinaten naar de driver gestuurd. En dan is de bug snel te triggeren. De bug zorgt er voor dat er een bit-shift optreed in de waardes, zodat als je bijvoorbeeld "0x240" ( = 576 pixels ) naar het hoogte register schrijft, er "0x2408" ( = 9224 pixels! ) in staat (de waarde van de laatste byte is random). Met als resultaat dat de OSD ernstig uitgerekt wordt, je alleen een stukje van linksboven zien, met letters de hoogte van het scherm.
Dit was een issue dat in het verleden al eerder geconstateerd is, en in de drivers is opgelost. Er zijn meer issues met deze serie Xtrends die op waren gelost en nu weer terug gekomen is, zoals het probleem met het plots wegvallende geluid als je het volume aanpast. De problematiek bij deze is dezelfde, de registerwaarde loopt van 63 naar 0 (het zijn negatieve dB waardes), als het geluid weggevallen is heeft het register ineens een waarde ver beneden die 63.
Wat wij denken dat de oorzaak is:
Vorig jaar is plotseling de duitse firma die achter Xtrend zat buiten beeld verdwenen. Na enige tijd en veel communicatie is het beheer van de BSP overgenomen via de moeder maatschappij die de Xtrend fabriceerde. Hierbij is blijkbaar ook het driver development team veranderd naar het team dat ook de laatste generatie Xtrends deed. Toen dit team zijn eerste BSP update leverde hebben we geconstateerd dat een aantal oude bugs weer teruggekomen waren. Wij vermoeden dat dit nieuwe team niet de beschikking heeft gehad over de laatste driver sources, en dus uitgegaan zijn van de versie die zij nog hadden, waarin die bugs dus nog zaten.
Wat we daarna zien is dat ze bij de OE-Alliance (tot twee keer toe) een kernel en driver update doorvoeren, waarbij de source van de driver files niet langer meer de server van Xtrend is, maar hun eigen download server. Dit suggereert dat deze updates niet geleverd zijn door (de nieuwe) Xtrend, maar door anderen. Deze updates lijken wel gebaseerd te zijn op de laatste source, wat suggereert dat OE-A of wel gelekte drivers heeft gekregen, dan wel contact heeft met dat oude development team om bugs te fixen en kernel updates mogelijk te maken, want toegang tot driver source is strict gebonden aan zware non-disclosure contracten, die alleen aangegaan worden tussen Broadcom en hun afnemers.
Wat nu verder:
Wij snappen natuurlijk wel dat je, als gebruiker van zo'n box ( is duur geweest ) daar allemaal weinig voor koopt. Ik heb hier ook zo'n ding met 4 tuners werkloos in de kast staan, en had dat graag anders gezien.
Als OpenPLi team hebben wij een aantal principiele uitgangspunten gedefinieerd. Die zijn deels gebaseerd op onze kwaliteitsvereisten, en deels op het feit dat onze menskracht en kennis beperkt is, en we die dus graag inzetten voor verbetering en innovatie, en niet om voor de fabrikanten de kolen uit het vuur te halen, zodat zij goedkoper uit zijn en meer winst kunnen maken.
Een van die principes is dat wij de ontwikkeling van de BSP, de board support package (zeg maar de hardware abstractie laag van de box, waarin de drivers zitten), aan de fabrikant laten. De fabrikant moet dus OpenPLi ondersteunen, OpenPLi niet de fabrikant.
En dus is de eerste stap in dit proces, zoals hierboven in eerdere posts al is aangehaald, de fabrikant op het matje roepen. En dat is inmiddels gebeurd. Op basis van het antwoord kunnen we vervolgens besluiten wat de volgende stappen zijn.
En de andere reacties (waaronder die van mij) waren eigenlijk meer onderkoeld. 
