Some things can not be lab tested.
It needed non-networked boxes for any problem to appear, one needs bad sat positions to understand why transponder sync doesn't really sync but only monitor (Astra and Hotbird usually deliver good times, we could throw out half of the code and still get better syncs, but then people from down under would complain as they appear to get crappy transponder times).
One question:
If everything would be as great as it gets painted sometimes, why does OpenViX switch oe-a core branches at all?
Using the perfect 4.0 branch where no changes happen anymore appears like the logical solution to me.
And why did OpenViX create a RELEASE version that bad? If the problem was that obvious, they should have noticed and waited for the fix ...
So sometimes things aren't as simple as they might appear at a first glance.
If OpenViX would do nighly builds, you would have had the stb-hwclock addition which also takes the pseudo-RTC into account, like only one or two days later.
That would have reduced the affected boxes to those that get fully powered off already.
The stb-hwclock btw worked great in tests, but on one box (AX51) it made the box get stuck at boot. How to know before someone runs it on one?
The whole concept of trying to create "golden" releases from a moving target is subject to fail. There have been enough snapshots in the past that were great for some boxes and sh$t for others.
Gesendet von meinem SM-N910F mit Tapatalk