new drivers for gigablue UHD 4K in BSP ?
jeanclaude 4 feb 2019
a question : I have learned today from Dimitrij that there are new drivers available for the gigablue UHD 4K (link : https://forums.openp...dpost&p=1012345 ).
this seems to be pointing to the BSP hardware layer.
have these new drivers been implemented in the PLi software, and which one (I'm still using version 6.2).
if not, can these be integrated in the upcoming builds ?
it would seem to solve a timer sanity issue discussed in the thread I've been pointing to.
thanks.
WanWizard 4 feb 2019
The lastest BSP update for 6.2 was on April 23rd 2018. For 7.0 the last update was on November 7th 2018.
In general, without a very good reason, we don't update BSP's in a release image, because often they will have dependencies to other things not in the release image, so building fails and fixing is a nightmare.
As I understand the timer sanity issue reported is not only a Gigablue issue, making it very unlikely a BSP update will fix it.
jeanclaude 4 feb 2019
well, I do read a lot of fixes in the github link. Not sure if any of them influence the timer sanity issue, that's Dimitrij's suggestion. But this also interrests me :
Date: 3 months ago
[GigaBlue | gb7252] (changes in conf pending) update build
* Update drivers to new BCM SDK
* add Support for new Gigablue DVB-S2X Single and Dualtuner with Multistream
this could fix the issue I also have on the multistream channels on 5W, using my single DVB-S2X multistream tuner .......
3 months ago so this would already be integrated in the newer 7.0 version (nov 7 2018) ?
I suppose most bugs will now have been corrected so I might give that a try when I'm back from my holidays !
jeanclaude 4 feb 2019
good - I'll report back on this issue next week when I'm back at home.
jeanclaude 10 feb 2019
back home - just reflashed the gigablue ultra 4K to version 7.0
I have been testing the multistream channels of 5W, but the situation is even worse : with version 6.2 I could get 'partial' reception of those transponders (the signal went on/off) and now with 7.0 the signal stays at 0 all the time.
I did not get the 'timmers in error' popup when rebooring the 4K, however, when trying to resolve a timer conflict I got the following crash :
enigma2_crash_1549792839.log 23,16K 2 Aantal bijlagen
after the reboot I tried again, same result :
enigma2_crash_1549793551.log 967bytes 4 Aantal bijlagen
if there's one thing that needs to work on this receiver it's the timers list so it's back to 6.2
which - by the way - had no problem whatsoever for resolving that timer conflict.
WanWizard 10 feb 2019
Never seen that before:
Traceback (most recent call last): File "/usr/lib/enigma2/python/mytest.py", line 210, in processDelay callback(*retval) File "/usr/lib/enigma2/python/Screens/TimerEdit.py", line 313, in finishedEdit AttributeError: 'RecordTimerEntry' object has no attribute 'external_prev'
It is part of the fallback tuner code, which has been there for over 9 months.
Do you have a fallback tuner configuration on that box? With remote timers? Installed anything else that does something with timers apart from Autotimer? It is set in TimerEntry, this error suggests something has hijacked that....
jeanclaude 10 feb 2019
nope - no fallbacktuner, never used it.
and nothing installed apart from the autotimer plugin which might influence any timers.
look, the box is recording again, but I see a free slot between 12:30 and 13:41 so I'll flash 7.0 again and I'll check the fallbacktuner settings again...
aha - come to think of it - I DO use the partnerbox plugin ......... could this be the culprit ?
WanWizard 10 feb 2019
Quite possible, that is a nasty piece of work. From the feed of installed manually (and if so, from where)?
jeanclaude 10 feb 2019
from the feed - everything's coming from the feed (automatically re-installed after I flashed)
jeanclaude 10 feb 2019
OK - reflashed to 7.0 with restore backup.
first let's check the fallbacktuner setup :
giga fallback 7_0 01.jpg 74,09K 4 Aantal bijlagen
partnerbox is installed with the following settings activated :
giga partnetbox 7_0 01.jpg 110,41K 4 Aantal bijlagen
first did a check on partnerbox to see if it's working correctly, and all is working well, I did not get any problems during my tests.
jeanclaude 10 feb 2019
let's now start by checking the timers list - here we have a conflict :
giga conflict 7_0 11.jpg 65,86K 3 Aantal bijlagen
if I press OK on the timer which has a conflict, I can see the timer details and divert the timer to another receiver, using the remote entry line of the partnerbox tool :
giga conflict 7_0 12.jpg 72,07K 3 Aantal bijlagen
setting the timer on the other receiver is working, but that's not what we want to test. I return to the timer conflict screen and select the 3rd recording :
giga conflict 7_0 13.jpg 95,69K 3 Aantal bijlagen
now I press yellow : disable
the box crashes a few seconds later .......
jeanclaude 10 feb 2019
next try - I'm setting a timer conflict from the EPG. I know sunday evening always has a lot of recordings, so I try to add the following :
giga conflict 7_0 21.jpg 198,13K 3 Aantal bijlagen
sure enough, a timer conflict window appears :
giga conflict 7_0 22.jpg 124,01K 3 Aantal bijlagen
now I can disable other recordings using the yellow "disable" button - of course as long as the conflict is not resolves I stay in the timer conflict screen :
giga conflict 7_0 23.jpg 119,17K 3 Aantal bijlagen
but by de-activating enough other timers, the recording is finally set :
giga conflict 7_0 24.jpg 190,13K 3 Aantal bijlagen
so it would seem that from this setting all is working normally.
jeanclaude 10 feb 2019
now let's do something else - I disable the new recording and enable all the other recordings again. I go to the timers list and here is my disabled recording :
giga conflict 7_0 25.jpg 191,83K 3 Aantal bijlagen
now let's activate again, and sure the timer conflict screen is there again :
giga conflict 7_0 26.jpg 167,4K 3 Aantal bijlagen
if I deactivate a recording in this list again using the yellow 'disable' button, the gigabox crashes again. So the problem arises only with a timer conflict screen when activated from within the timers list.
now new crashfiles I received during these tests :
enigma2_crash_1549799859.log 23,09K 3 Aantal bijlagen
enigma2_crash_1549800432.log 967bytes 1 Aantal bijlagen
enigma2_crash_1549801937.log 22,9K 4 Aantal bijlagen
so for me it's back to 6.2 for now .......
ims 10 feb 2019
I am using partnerbox plugin for create timers between 6 boxes almost each day (and between next 4 boxes time to time) and have no problem with creating timers via Partnerbox.
When You are trying create timer, which is in conflictt with timer on remote box, You get warning message about it always and timer is not created.
This problem has nothing to do with partnerbox - when is timer created via Partnerbox, is created on remote box as standard timer.
Problem is in E2. You can simulate it (tried with disabled Partnerbox + restart GUI):
1 ) create timer on local box, then disable it with yellow in Timer
2 ) create new timer on same box, which will be potencialy in conflict with disabled timer
3) go to Timer, set selector to disabled timer, use Yellow and Blue. Blue = "Ignore conflict" and voila ... GSOD with 'object has no attribute 'external_prev'
jeanclaude 10 feb 2019
I normally never use "ignore conflict" but at least now I'm not the only one which seems to get a GSOD when (de)activating timers.
having said that, I only have this problem with the new 7.0 - it is working perfect in version 6.2
If this is an enigma2 problem then I cannot understand why not more people are reporting this error - it's not limited to the gigablue ultra 4K alone is it ?
right now I cannot solve any timer conflicts any more which have been created by the autotimer plugin. As I have a lot of autotimer definitions, there are always timer conflicts so autotimer will create a disabled timer for this.
I frequently look at these disabled timers and activate some of them using the timer conflict screen where I can de-activate the less important timers.
in PLI 7.0 this is now become impossible so for now I'm stuck on 6.2 where it is working correctly
any chance of a solution in 7.0 or do we have to wait for a new version 7.1 ?