The commit has been made to affect tuning lock of all receivers.
The commit has been made to affect tuning lock of all receivers.
RustySpoons (31-03-18)
LOL. We do it right, everyone else is doing it wrong. But our box doesn't work properly. Truth is enigma2 is open source and the drivers are closed source. So it is easy for them to look at our open source and make the drivers compatible. Not so easy for us to look at their closed source and make our open source compatible.
I can confirm this "Commit" has resolved this issue on the Miraclebox Premium Micro.
Miraclebox premium micro won't work with dvbsnoop.
There is a nice discussion on PLi over the Mutant issue. Everyone is wrong apart from Mutant!
Oh yes, Mutant's cannot show tuner information because of E2 fault too! All other receivers have faulty drivers. Engma2 is at fault too.
Oh yes, screenshot on miraclebox premium does not work properly too. Another instance of bad coding in engima2. Same bad coding works without problem on other images.
The real problem is that there is no documentation about what the drivers must do/should respond.
RustySpoons (03-04-18)
There are different issues, the one I reported about not locking after the motor moving etc was resolved with this "Commit"
From my testing it's an E2 issue and I came up with a work around that I posted elsewhere, I would have posted it here but no one replied to my PM.
This was then resolved with the latest commit.
Everyone seemed to point their finger at Mutant saying the motor issue is down to the driver but it's not, I can get any E2 box to do it.
However there is an issue with a driver to do with signal readings etc but that's another discussion.
Another instance of bad enigma2 coding....
Flashing an image using ofgwrite on MB micro always resulted in non-booting receivers.
The wonderful people at Mircalebox/INI had to provide a new bootloader because of the bad coding.
Gigablue gives false positives on AV output in drivers.
We stopped adding hacks for them, other teasm still do. They won't fix drivers as a result
There is along thread on Linuxsat about the not-supported-here receivers not locking on motorised setups. They needed lo-power lnbs to work.
One of the "power users" stated something very telling, something to the effect, "it has to be drivers because all other 7362 receivers work fine"
This "Bug" was introduced at some point in 2017, it's only on OA-E Images, it affects ANY box that has that software on there.
The factors here are, have they all updated/installed an image with this bug?, do they move their motor much?, do they notice?
Reports on lots of different boxes, they said that the SF4008 is not affected, well it is.
I've tested it on numerous boxes, its an E2 issue not a Driver issue.
Doesn't happen on Non OA-E E2 sources, I have dreamboxes as well, doesn't happen with images from other sources on those.
Put a PLI based image on them and the bug is there.
Yes it certainly does effect the sf4008 , I have sf4008 & mutant hd51 and effects both but I did not realise it was a bug until I read this thread - now I know why it takes so long for channels to appear after switching to a different satellite, hopefully a remedy sorted out soon , thanks for the info lads.
This thread is bordering ridiculous now imo. Bug is fixed, thread closed.
D I S C L A I M E R
My right to post information is protected under the rights for freedom act. In all instances, information discussed here on my posts are either hypothetical in nature, out of general curiosity, common knowledge, public knowledge, or role-play. Any use of the collective descriptions and shared knowledge from any of my posts are at the sole discretion of the reader. I am not responsible for what you do with it!
Please help keep OpenViX online, donate HERE.
Rules can be found HERE
Support our sponsor World-Of-Satellite HERE
GIGABLUE UHD QUAD 4K, VU+ DUO 4K SE, ZGEMMA H7S, VU+ UNO 4K SE
Triax 1.1m Powered by TM2600, Fixed 28.2 Zone 2 dish with GT-SAT Unicable
aadham (06-04-18),el bandido (05-04-18),Huevos (06-04-18)