923 replies to this topic

[josjansen]

Niks.

 

Anders dan dat de default skin in 4 de PLi-HD is (en die is dus 1280x720), en in 6 is de default de PLi-FullHD, en die is 1920x1080.

 

Als je zegt dat de PLi-FullHD wel goed werkt, maar de PLi-FullNightHD niet, dan haak ik af, wat die zijn op wat kleurtjes na exact dezelfde. Die laatste overigens niet verwarren met de PLi-HD-FullNight, die is namelijk ook 1280x720 !

 

Als blijkt dat de ET8000 geen full HD OSD heeft (dat kan, zo zijn er meer), dan zit er een foutje in de HardwareInfo, en in de wiki, en dan moet dat gefixt worden. Dan kun je geen full HD skins meer installeren.

 

Dat is volgens mij ook het probleem dat de default skin FullNightHD is. Als ik een nieuwe image 6.0 installeer en zorg dat de default skin Pli-HD is d.m.v. backup-instellingen en dan daarna als OpenPli 6.0 helemaal is geïnstalleerd gewoon in het menu de skin verander naar de FullNightHD skin. Dan heb ik geen foutmelding meer.

[cobus]

Gewoon de default skin gebruik ik.

[wortellica]

Bij jou wel, maar Bram55 zegt dat hij het ook op zijn Ultimo 4K heeft.
 
Ik zit er al even naar te kijken, maar kan het nog niet echt vinden. Het niet hebben van een VU+ 4K box helpt dan niet.
 
De box boot in ieder geval met het LCD in de middensetting, dat is zo voor alle displays. Zodra Enigma geladen is (het moment dat het beeld omschakelt van bootlogo naar OSD, nog voor er beeld is) wordt de LCD component geladen en wordt de C++ functie aangeroepen die de opgeslagen brightness instelt.  
 
Het enige wat ik me nog kan voorstellen is dat de box zo snel is, dat de ingelezen config klaar is met parsen nog voordat de LCD component geladen wordt (want dat werkt de notifier niet meer), maar dat zou vereisten dat dit in parallele threads gebeurd, en dat uitzoeken is boven mijn "paygrade"...

  

Ook op de Vu+ Ultimo 4K is het zoals de TS zegt. Zojuist even getest om dit verhaal te bevestigen cq te ontkrachten.
Wijzig de helderheid van het LCD, sla die op, herstart de box, en de helderheid is weer standaard, alsof de instelling in het midden staat dus.
Ga je dan naar de instellingen, dan staat daar toch echt de aangepaste instelling maar klopt dit niet met de werkelijkheid.
Zodra je de instelling opnieuw ga wijzigen, wordt de helderheid onmiddellijk overgenomen zoals je deze de vorige keer had ingesteld, donkerder dus in mijn geval.
Dus hij slaat de instelling wel op maar leest hem niet uit bij het opstarten van de box en wordt de helderheid automatisch ingesteld op de standaard waarde, in het midden dus.
Dacht dat de vorige post niet was aangekomen dus heb ik heel het verhaal opnieuw geschreven
[modbreak=Tech]ik heb het bericht voor je verwijderd[/modbreak]

  

Ik bedoel je stelt hem feller in zeg maar,maar zodra ik de box weer aan zet vanuit standby dan is het schermpje weer donker. Maar de balkjes zie foto in post 255 staan wel nog zoals ingesteld!

  

Ah, ok.
 
Dus de interface volgt je instellingen wel, het wordt blijkbaar ook opgeslagen (want bij opnieuw openen staat het nog zoals je het ingesteld had), maar als Enigma (her)start wordt die setting niet (goed) uitgelezen en het LCD aangestuurd.
 
Nu snap ik 'm.

is hier al wat meer over bekend...

[littlesat]

het enige nadeel van deze skin vind ik nog steeds die dunne lettertjes. Dat kan iknatuurlijk wel aanpassen maar ik ben daar een beetje te lui voor om kosmetische dingen te gaan aanpassen.

Gewoon ff een weekje gebruiken en je weet niet beter... Heel vaak is als iets ander is dan je gewend bent dat iets anders er niet uitziet... Het wordt dan "vanzelf" na enkele dagen beter (als je aan het nieuwe gewend bent)....

[WanWizard]

is hier al wat meer over bekend...

 

Nee, en volgens mij is er ook nog niet naar gekeken. De meeste energie gaat naar het releasen van 6.0 op dit moment, de bugfixes zullen voor 6.1 zijn.

[KlaasVV]

Goedendag,

 

Ik wil even een raar iets melden wat zich voordoet in Openpli 6.

 

Ik heb vanmiddag met mijn hoofdontvanger, een et8000 met 2 CD kaarten, de formule1 opgenomen op de interne hdd. Met een vertraging van 15-20 minuten heb ik op mijn andere ontvanger, een et 9500, de opname afgekeken.

Echter, elke 15 minuten moest ik weer vanuit de opnamelijst de opname weer opnieuw starten. Hij speelde dus die 15 minuten vertraging af en telde dus ook af naar 0 minuten, terwijl de opname op de hoofdontvanger nog bezig was. De resterende tijd moest dus blijven staan op 15 minuten.

 

Gisteren beide boxen geflashed met Openpli 6.

 

Misschien is dit al bekend, of misschien kan iemand dat even testen.

 

Met vriendelijke groet.

[Dream1975]

Klopt dat heb ik ook. Als een opname loopt en je start tegelijk de opname op een andere box speelt hij af tot het moment dat je startte. Stel je opname begint om 15:00 en je begint om 15:09 te kijken dan speelt hij 9 minuten af en dan stopt hij. Speel je vervolgens gelijk weer af doet hij het weer even af tot het volgende punt bereikt is (en moet je weer hetzelfde doen). Had ik al met 4 (eigenlijk nooit gemeld omdat het maar sporadisch voor kwam, maar heb er wel eens een opname kijken mee uitgesteld tot de andere ontvanger klaar was met opnemen)

Edited by Dream1975, 27 August 2017 - 18:31.

[KlaasVV]

Hoi Dream1975,

Met versie 4 nog nooit dit probleem gehad. Voor mij was dit dus nieuw.
Met F1 doe ik het altijd op deze manier. Had ook om de 10 seconden een beeldvervorming, maar kan ook aan de zender gelegen hebben.

M.v.g.

[littlesat]

Heeft iets te maken met de mount naar die andere box. Een of andere parameter, ik vind ook ff niet welke. Maar ik kan dit lopende opname ik een box die gemount is bevestigen...

[KlaasVV]

Littlesat,

 

Ik heb met behulp van autobackup de instellingen van openPli 4.0 in openPli 6.0 teruggezet. Dit is gebeurd bij beide boxen. Verder heb ik niets veranderd.

In de jaren dat ik openPli gebruik, heb ik dit nog nooit gehad.

Edited by KlaasVV, 27 August 2017 - 22:24.

[WanWizard]

Het ligt ook niet aan Enigma (dat is het deel dat wij doen) maar aan het operating system, dat de netwerk verbinding maakt en onderhoud.

 

Daar zal in een nieuwere versie van e.o.a. client of service wel besloten zijn dat default voor snelheid of efficientie e.o.a. optie nu uit staat, waardoor de client geen file attribute updates meer krijgt, en dus niet ziet dat de file aan het groeien is.

 

Hebben we het hier over een CIFS (Samba) of NFS mount?

[littlesat]

Bij beide methodes word dit niet meer standaard gedetecteerd. Zodra ik weet hoe je het moet instellen kan ik de e2 code aanpassen

[KlaasVV]

Betreft een mount van het type CIFS.
Ik begrijp van littlesat dat het niet specifiek aan dit mounttype ligt.

[WanWizard]

Ik geen geen flauw idee waar Littlesat het over heeft.

 

Voor NFS kun je een van deze opties gebruiken op de mount:

- lookupcache=none (disabled alle client file cache)

- actimeo=10 (waarbij [x] is een cache timeout in seconden) 

 

Die laatste is minder performance impacterend, maar heeft uiteraard een delay.

 

Voor CIFS zijn de equivalenten:

- directio (disabled all client file cache), voor kernels > 3.7 vervangen door "cache=none"

- cache=loose (dit was de default in oudere kernels, nieuwere hebben "cache=strict" als default)

- actimeo=10 (waarbij [x] is een cache timeout in seconden) 

 

Je zult even moeten kijken welke voor jou werken.

 

@Littlesat,

 

Ik ben tegen het default implementeren van dit soort opties. Niet veel mensen hebben dit nodig, en ze gebruiken het heeft een negatieve performance impact. Er staat een todo open om te kijken maar checkboxes voor opties als de netwerk layer in Enigma wordt herschreven, maar dat is niet voor morgen.

[Frenske]

Ik kan dit gedrag bevestigen. Dit was bij mij ook gewoon in V4 aanwezig. Dit is ooit uitgebreid onderzocht maar klaarblijkelijk is hier nooit meer een oplossing voor gemaakt. Hier idem met een cifs mount naar de hoofdontvanger.

[WanWizard]

Er is ook niet echt een oplossing voor, anders dan bovenstaande mount opties gebruiken. Het is inherent aan het gebruik van nieuwere kernels en modernere nfs en samba services. Idem met de "sec=" problematiek bij CIFS.

 

Het enige wat we kunnen doen is de mount manager meer gebruikersvriendelijk maken, door de meest gebruikte mount opties in checkbox vorm op het scherm te zetten, voorzien van een help text. En dan bij het saven zelf de mount optie string genereren op basis van deze checks, plus wat nog handmatig in het opties veld is ingevoerd.

[littlesat]

Ik begrijp dat jij alle details hiervan begrijpt. Hoe zit het met die kernel versies. Bedoel je de kernel van de client of de host?

 

Zoals het nu default is werkt het gewoon niet lekker en ik begrijp nu eindelijk waarom dit ineens zo gekomen is. 

 

Ik vind dan eigenlijk ook dat als je een mount maakt met een andere "openPLi" box dat dit dan ook currect met updaten van file attributes mag gebeuren,

 

De mount opties staan nu als een string in de mount configs.

 

We mogen of makkelijker opties kiezen -of- er voor keizen dit default te maken of iets toevoegen dat het eenvoudig in die string geschreven kan worden.

 

Welke van alle mogelijkheden is eigenlijk de beste?

Edited by littlesat, 28 August 2017 - 15:18.

[WanWizard]

De kernel van de client, en de server van de host (dus samba of nfs server).

 

Ik snap best dat het niet lekker werkt voor sommige mensen, maar het is even niet anders. Dat is de prijs van vooruitgang.

 

You can't please all of the people all of the time, just some of the people some of the time...

 

In het geval van CIFS is overigens Microsoft de boosdoener, die heeft met de introductie van SMBv2 in Windows 8 / Server 2008 de client-side caching bedacht, en de Linux kernel drivers conformeren zich slechts aan de "standaard".

 

Heeft nog veel meer vervelende bijwerkingen, bijvoorbeeld inode notificatie werkt ook niet meer, ga dus maar eens met een git GUI of een editor suite op een share zitten werken. Kun je continue gaan refreshen want je wijzigingen zijn niet meer zichtbaar voor zowel git als (in mijn geval) de lokale webserver.

 

Makkelijkst is waarschijnlijk de timeout waarde gebruiken, en die bijvoorbeeld op 30 seconden zetten. Dat is ruim genoeg om niet te veel performance impact te hebben, maar kort genoeg om een spelende opname vroeg genoeg van updates te voorzien. Maar dat zou getest moeten worden.

[KlaasVV]

Heb actimeo=30 toegevoegd aan de moutopties, dus de regel was rw,actimeo=30
Na opnieuw opstarten geen verbetering.

[WanWizard]

Kan zijn dat bij CIFS de filesize niet onder de "file attributes" valt.

 

Probeer dan de andere opties eens?