That is your service hacks crashing, not ABM. The error means you are writing to a dictionary while iterating.Originally Posted by BefuddledBrian
For JediMakerXtreme I have sent a pull request to fix the AssertionError. https://github.com/kiddac/Jedi_Maker_Xtream/pull/5
Please test with our original List.py from our git. https://github.com/OpenViX/enigma2/b...ources/List.py
And obviously the AssertionError doesn't happen in OpenATV because someone has deleted the "assert".
Last edited by Huevos; 21-06-21 at 20:19.
Willo3092 (21-06-21)
That works. ThanksFor JediMakerXtreme I have sent a pull request to fix the AssertionError. https://github.com/kiddac/Jedi_Maker_Xtream/pull/5
Please test with our original List.py from our git. https://github.com/OpenViX/enigma2/b...ources/List.py
And obviously the AssertionError doesn't happen in OpenATV because someone has deleted the "assert".
Huevos (21-06-21)
One of my CusomMix files needs changing to be compatible with python3?
sat_282_sky_uk_CustomMix.xml
terrestrial_uk_freeview_CustomMix.xml
Probably this:
Maybe needs to be this:Code:for number in customised["video"].keys():
Code:for number in list(customised["video"].keys()):
I've just gone back to 5.4.012 (Release) on 2 different boxes, they both pick up 506 using frequency finder, as they always have done.
So 5.5.013.015.P3 does something different.
Is signal quality actually used? My Ultimo4K and ET10K both show 0xFFFF in the xml file for all mux's (except 562 on my ET10K which is a bit lower at 0xEB88).
Maybe a rounding error has crept into P3 ?
SNR's on both boxes show differences between mux's 506 and 562, much bigger on the ET10K, but none reach anything like 100%.
First it reads the NIT, which takes time so the SNR reading has a chance to stabilize.
https://github.com/oe-alliance/AutoB...finder.py#L394
SNR is a 16-bit int. Max value is 65535. If all the values are maxed out the end result is in the hands of the sort algorithm.
https://github.com/oe-alliance/AutoB...finder.py#L553
Sort is done here:
https://github.com/oe-alliance/AutoB...r.py#L619-L622
ccs (22-06-21)
In P3 it looks like a list is created in signal quality (low to high) and frequency (low to high) order.
The last system=0 entry in the list is then selected and as the qualities are always(?) the same, 562 gets the nod as it's the highest frequency.
In P2 (exactly the same code) 506 gets selected, neither the highest nor the lowest frequency, so the qualities must come into play, or P2/P3 gets it wrong.
the vu zero 4k image is corrupt and not usable.
initrd_auto.bin
building off my server at the moment - maybe available later tonight
Gigablue Quad 4K & UE 4K
.........FBC Tuners:
------------------> GT-Sat unicable LNB to 1.5M dish(28.2E)
------------------> Gigablue unicable LNB to 80 cm dish(19.2E)
.......................> FBC & DVB-S2X into 90cm dish (27.5W) Opticum robust Unicable LNB
AX HD61, Edision Osmio 4K+, Zgemma H9Combo, Octagon SF8008 , gbtrio4k, h9se using unicable ports
Zgemma H9 C/S into Giga4K
This is available for download now.
Yes, that's it.
Thank you.
And the result seems to be Python 2 compatible as well.
Huevos (22-06-21)
Not sure where this is going to be honest.
If my limited understanding is correct, P2 works (for me) because the mux selected happens to "work" but there doesn't appear to be any logic in the choice.
P3 doesn't work because the mux selected appears to follow the logic, but doesn't provide all the necessary data.
Maybe the lowest frequency with the best signal quality could be consider instead? That happens to work (for me), and is no less logical.
2 choices:
- Edit the created xml file by hand to suit your needs (after all it does contain all the data).
- Find the mux with BBC ONE. If there are multiple instances choose the strongest. Means fiddling with a lot of code for little return.
Posting Permissions
