WanWizard

Ik had gehoopt dat 7.1 klaar zou zijn deze week, maar dat is niet gelukt. De enige reden dat ik 7.0 niet bijgewerkt heb.

Ik heb zowel 7,0-release als 7.1-rc bijgewerkt naar de laatste versie, want ik zie dat @Caught github heeft bijgewerkt. Met het zonnetje.  

First rule of development: "there is always one more bug".

Having said that, in general stability issues are virtually always related to drivers.

When it comes to vendors there are two types, manufacturers and OEM distributors. The first design and build their own hard- and software (like VU+, Zgemma, Dags), the second buy their hardware from an OEM manufacturer, with several degrees of customisations. In some cases the second are actually local or regional distributors, for example Ceryon / AX / Mutant, or Qviart / Xsarius. In some cases they are supported by the development team of the manufacturer, others don't have their own developers, but have outsourced the development, which of course has a cost. Support varies, some are very on it (like Mutant / Qviart / Xsarius), some are responsive in the beginning, but sometimes are not willing to spend any money on a box no longer being produced or approaching end-of-life. It is quite a bit of work, having to chase them for all outstanding issues.

As to hardware, I think the shift from Broadcom to others will continue, Broadcom is discontinuing it's products for the bottom end of the market, and that is still the bulk of the sales in STBs.

And if you see issues, post them. We can't fix the issue, or forward them to the vendor, if they are not reported.

Misschien niet te lang mee wachten, 7.1-release komt er aan, en het zou mooi zijn als daar de update in mee zou kunnen.

Nog als toevoeging, het ligt in de planning om de functionaliteit van systemtime te integreren in OpenPLi 8.

Wij bouwen daar ook gewoon van. Maar we pinnen release en rc dependencies (op commit hash), om te voorkomen dat een build run "work in progess" gaat bouwen en een release image instabiel maakt.

Dus als er een update is die wel doorgevoerd moet worden, moet de commit hash manueel aangepast worden. Die staat hier (https://github.com/O...porefs.conf#L92) voor de rc, de release branches hebben deze file ook.

Dat aanpassen kan gebeuren door middel van het indienen van een pull request (bij voorkeur, jij weet zelf het beste wanneer een update in productie kan), of via een melding hier, dan passen wij hem aan.

Ik heb dat nu voor deze versie gedaan: https://github.com/O...5f3385d5312ca35, dus die gaat in de rc build van vannacht mee.

Known problem, a workaround is implemented for tonights build, we're still looking for a permanent solution.

Yes, the drivers in 7.1-rc are dated 20190429.

Dit zou misschien wel eens kunnen. Ik heb de laatste tijd een constante smb-verbinding met mijn iMac en deze zet ik in slaapstand als ik tv ga kijken. 

Dat is zeer waarschijnlijk de oorzaak, daarmee hang je de client (je box) op. Zowel SMB als NFS zijn gemaakt voor connecties met servers, en servers horen niet zo maar te verdwijnen. 

Dat heeft overigens wel een timeout, na verloop van tijd (en dat kan zeker 10 minuten zijn) moet de box weer gaan reageren.

Je zou je eventueel kunnen gaan verdiepen in autofs, en dat installeren. Dat maakt dynamisch mounts zodra je deze wilt gebruiken, en dan heb je minder van dit soort problemen.

Maybe, maybe not.

We require the BSP to come from the manufacturer, including full (developer) support, and not from some unknown third party. If that were the case, we could make it ourselfs.

If they can't create a BSP, they will not have the expertise to provide proper support, in which case we're not even interested.

We've been in discussion with Octagon for quite a while now. The ball is in their court, we're waiting for a working BSP so we can move on, but which they can't seem to produce.

Bij voorbeeld niet nodig als er niets is veranderd? Je antwoord zou nu kunnen zijn: "Misschien is er wel wat veranderd"!

Inderdaad.

Onze generator is slim genoeg om te zien of er wat verandert is (op basis van de git status), en bouwt niet opnieuw als dat niet het geval is.

Vroegah bouwden we maar eens per week, veranderingen of niet, en daar kwam commentaar op, dus hebben we dat intelligenter gemaakt.

...dan moet je wel de arm versie gebruiken

Nee, het probleem is dat de Oscam die je nu uit develop bouwt tegen veel nieuwere libraries gebouwd wordt als in OpenPLi 4 aanwezig zijn.

Ik ga daar morgen wel even mee aan de slag, hoe ik die modules moet enablen is me wel bekend

Zou fijn zijn, want:

Gelukkig een ommekeer te constateren  , voor het laatste verzoek van @Mimisiku gebruik je de regel in jullie speciaal "bouwsysteem" XTRA_OECMAKE     ===> -DHAVE_PCSC=1

Er is helemaal geen ommekeer, ik wil best naar alles kijken, als er tijd en energie voor heb. En beide heb ik niet zo veel, dus als er dan geen hulp komt, haak ik af. En uberhaupt snap waar het over gaat. Uiteindelijk was uit deze thread wel wat "hulp" te destilleren. Met wat moeite.

En helaas is het zo eenvoudig niet. "HAVE_PCSC=1", "WITH_PCSC=1, "USE_PCSC=1", allemaal blijven ze "cardreader_pcsc:  no" roepen na compilatie. En dus stopt het zonder hulplijn hier voor mij (weer), geen idee hoe ik verder moet. Er zal wel iets meer missen.

Over CW en caching is hierboven door Littlesat al het een en ander gezegd. Dat is boven mijn paygrade. 

Het staat blijkbaar uit voor een reden, en er is geen moverende reden om het weer aan te zetten. Tenzij je een cardserver farm hebt, en dan compileer je maar lekker zelf. Als die moverende redenen er wel zijn, dan hoor ik het wel.

Please attach these files here, instead of on some external medium. Use the "More Reply Options" button to do so.

Traceback (most recent call last):
  File "/usr/lib/enigma2/python/Components/ActionMap.py", line 69, in action
  File "/usr/lib/enigma2/python/Components/ActionMap.py", line 49, in action
  File "/usr/lib/enigma2/python/Screens/Menu.py", line 57, in okbuttonClick
  File "/usr/lib/enigma2/python/Tools/BoundFunction.py", line 9, in __call__
  File "/usr/lib/enigma2/python/Screens/Menu.py", line 72, in runScreen
  File "/usr/lib/enigma2/python/Screens/Menu.py", line 78, in openDialog
  File "/usr/lib/enigma2/python/mytest.py", line 289, in openWithCallback
    dlg = self.open(screen, *arguments, **kwargs)
  File "/usr/lib/enigma2/python/mytest.py", line 302, in open
    self.execBegin()
  File "/usr/lib/enigma2/python/mytest.py", line 223, in execBegin
    c.execBegin()
  File "/usr/lib/enigma2/python/Screens/Screen.py", line 93, in execBegin
  File "/usr/lib/enigma2/python/Screens/ServiceInfo.py", line 190, in ShowServiceInformation
  File "/usr/lib/enigma2/python/Screens/ServiceInfo.py", line 224, in getTrackList
AttributeError: 'NoneType' object has no attribute 'getCurrentTrack'

De TS heeft eerder al gezegd dat de box NIET in deep standby staat op het tijdstip van de backup.