WanWizard

Sure, if you istalled it, it's in the feeds.

OpenPLi doesn't use autofs, so this isn't going to work.

You can create the same mount with the mount manager. Possibly, depending on the kernel version on the box, you might have to add

vers=1.0

to the mount options, chances are the Fritz still wants SMBv1.

Danke, merged.

It could be it doesn't advertise its services?

You can always create the mount manually.

No clue what happened, the only thing we know is that the current version of the SDK no longer supports it, so new drivers will no longer have that support.

We don't have access to the SDK or contact with Broadcom, that is all under very heavy NDA.

And I doubt VU+ ever looks at that github account, they don't use it for development, it only contains the BSP they make for us.

De plugin staat gewoon in de feeds, hij moet alleen de commit hash aanpassen na een update. Ik heb dat voor de build van morgen voor hem gedaan.

Known problem, but we don't know why.

Can be fixed by

opkg install fakelocale --force-reinstall

Done in develop. If all is well, I'm backport it to 7.1-release.

Aangepast: https://github.com/O...1ee4abdbb808934

What does this copy and paste add to the discussion? It is A to Z unrelated bollocks.

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.