OverlayHD BER indicator problems 19.3.20210726

[unilaw]

Hi,

Great that worked, now I have a theme ???.xml which will not work or show after being copied to etc\enigma2.

I read in another feed there may be some issues.

[prl]

What issues? You might be in a region I dont hsve upadted scan data fior.

More ipdates will be needes after the chang re s on 1 Aug.

[MrQuade]

What issues? You might be in a region I dont hsve upadted scan data fior.

Is he referring to the themes issues perhaps?
Never used em myself.

[unilaw]

What issues? You might be in a region I dont hsve upadted scan data fior.

Is he referring to the themes issues perhaps?
Never used em myself.

Hi Peter,

I mean on the V2, I am having problems changing the OverlayHD to my theme i created years ago on the DPP2 then used on the T4 now won't load on the V2 unless I force the change to the settings file. I then get Bit Errors detected. Sorry, There was a previous feed from a while ago about changing themes on the V2.

I have updated using the Beta Feed to get the channel picons correct. I have Wollongong, I sent to you.

[prl]

OverlayHD IS normally callled a skin.

I'm still unclear what the promlem is. The DP-P2 isn't skinnable, so there isn't a way you could have a skin that yoiu used on a DP-P1.

Do you mean that you have modified one of your V2 skins to have a Bit Errors display like the one in OverlayHD?

Or do you want to use the OverlayHD on your V2 but can't?

Or something else entirely?

[unilaw]

OverlayHD IS normally callled a skin.

I know but they are named themes when saving or loading.

I'm still unclear what the promlem is. The DP-P2 isn't skinnable, so there isn't a way you could have a skin that yoiu used on a DP-P1.

Sorry I meant I started the skin on the T4 not my DP-P2. I thought it was longer than that.

Do you mean that you have modified one of your V2 skins to have a Bit Errors display like the one in OverlayHD?

I created a skin from the default and saved as mine into a XML file. that wasn't showing so I tried updating the settings file and managed including my colours and that's when the Flashing red "Bit Errors Detected" occurred. I don't have a 100% signal strength or quality with or without the USB tuner attached.

Or do you want to use the OverlayHD on your V2 but can't?

I want to use it but it's been problematic. To recreate will take hours.

Or something else entirely?

[Paul_oz53]

The flashing bit errors display is a feature of Overlay HD.

The "OverlayHD_themes.xml" is saved in an ordinary backup but will be lost in a USB update. I save a copy on my computer to restore later when I occasionally do a USB update.

Edit: The "OverlayHD_themes.xml" file is in /etc/enigma2 where "settings" also resides. The entries in "settings" activate the skin but don't exist in a USB update and are reverted to the OverlayHD defaults on a USB update unless the settings are backed up and restored. The easiest way to restore the settings manually is to use the OverlayHD manager from the Plugins menu.

[unilaw]

The flashing bit errors display is a feature of Overlay HD.

Why are there Bit errors? What is the actual problem? This did not happen in the T4. Why the V2?

[MrQuade]

Why are there Bit errors? What is the actual problem? This did not happen in the T4. Why the V2?

Because the V2's tuners are receiving data with errors.
Your reception must be marginal for the V2's tuners. Tuner performance is black art, and all the different models behave a bit differently.

When I tried OverlayHD, my connection showed bit errors as well. The flashing was quite distracting, and I think is a pretty pointless indication to show in the infobar.

[unilaw]

Why are there Bit errors? What is the actual problem? This did not happen in the T4. Why the V2?

Because the V2's tuners are receiving data with errors.
Your reception must be marginal for the V2's tuners. Tuner performance is black art, and all the different models behave a bit differently.

When I tried OverlayHD, my connection showed bit errors as well. The flashing was quite distracting, and I think is a pretty pointless indication to show in the infobar.

So I shouldn't be concerned with any actual fault? Bit Errors only being data loss, not a fault in the system? Just Signal Degradation causing the error which is only visible using the OverlayHD, Right? the only way around it is to change the colour to blank out the text and the background.

[MrQuade]

So I shouldn't be concerned with any actual fault? Bit Errors only being data loss, not a fault in the system? Just Signal Degradation causing the error which is only visible using the OverlayHD, Right? the only way around it is to change the colour to blank out the text and the background.

No, the bit errors are generally correctable and/or ignorable. Only when they reach higher levels will you see visible reception issues.

One of these days I will have someone out to install a better antenna at my place .

[unilaw]

So I shouldn't be concerned with any actual fault? Bit Errors only being data loss, not a fault in the system? Just Signal Degradation causing the error which is only visible using the OverlayHD, Right? the only way around it is to change the colour to blank out the text and the background.

No, the bit errors are generally correctable and/or ignorable. Only when they reach higher levels will you see visible reception issues.

One of these days I will have someone out to install a better antenna at my place .

I'm sure when the T4 worked before the failure that the reception - Signal and Quality was much better than I am getting on the V2. There doesn't seem to be an actual reception problem except for a bit of lag in the stream.

[MrQuade]

I'm sure when the T4 worked before the failure that the reception - Signal and Quality was much better than I am getting on the V2. There doesn't seem to be an actual reception problem except for a bit of lag in the stream.

As I mentioned earlier, all tuners are completely different so any results you see on one box will not directly correlate to results you see on another.

Some will report different signal and quality, and perform just as well, while other tuners may perform significantly worse.

If you don't see any problems in your video and audio, then don't worry about it.

[Paul_oz53]

I'm sure when the T4 worked before the failure that the reception - Signal and Quality was much better than I am getting on the V2. There doesn't seem to be an actual reception problem except for a bit of lag in the stream.

As I mentioned earlier, all tuners are completely different so any results you see on one box will not directly correlate to results you see on another.

Some will report different signal and quality, and perform just as well, while other tuners may perform significantly worse.

If you don't see any problems in your video and audio, then don't worry about it.

Agree completely. I often get bit errors but only occasionally get picture breakup. I record everything twice on different machines and usually that is sufficient but there's always the catchup services to save the day.

[prl]

Agree completely. I often get bit errors but only occasionally get picture breakup. I record everything twice on different machines and usually that is sufficient but there's always the catchup services to save the day.

There are three levels of error detection/correction in a DVB-T digital broadcast receiver.

The first is a convolution code. This is a bitstream error corrector, but its error correction is probabilistic: there's a good probability that it will correct a bit error, but there's no guarantee that the correction actually restores the right value, and no way to detect whether it did.

The other two are products of a Reed-Solomon error correcting code. It is a correction code over a bit packet.

It can both
1. correct bursts of bit errors in the packet, and
2. detect a larger number of uncorrected bit errors in a packet.

The Reed-Solomon code used for the error correction is a (208, 188) code which means that for every 188-byte data packet, 208-188 = 20 bytes of error correction are added, and the code can correct up to 8 incorrect bytes in the packet (DVB-T, External encoder).

There are also wrinkles in how the logical packets are put into the physically broadcast packets to allow the Reed-Solomon error correction to make the correction more robust against noise bursts that are "longer" than the number of bits that can be corrected in a burst.

I'm pretty sure (but not certain) that the reported BER is the number of uncorrected bits, but I don't know what interval it's reported for.

An uncorrected error is most likely to affect the video stream, and next most likely to affect the audio stream you're listening to, because they're the highest data flow streams. Its actual visibility or audibility depends enormously on exactly where it falls in the packetised streams. A small bit error that is in a quickly-changing part of the video is much less likely to be noticed that a similar error in a slowly changing part of the image. Because of the way MPEG is encoded, quickly-changing parts of the image are updated more often on the screen than slowly-changing or static parts of the image (and yes, it's a bit more complicated than that ).

It's the job of the frequently-mentioned demuxes (demultiplexers) to split the broadcast packets into the packetised data streams that are needed to view the selected digital channel from the data in the broadcast channel.

[unilaw]

Agree completely. I often get bit errors but only occasionally get picture breakup. I record everything twice on different machines and usually that is sufficient but there's always the catchup services to save the day.

There are three levels of error detection/correction in a DVB-T digital broadcast receiver.

The first is a convolution code. This is a bitstream error corrector, but its error correction is probabilistic: there's a good probability that it will correct a bit error, but there's no guarantee that the correction actually restores the right value, and no way to detect whether it did.

The other two are products of a Reed-Solomon error correcting code. It is a correction code over a bit packet.

It can both
1. correct bursts of bit errors in the packet, and
2. detect a larger number of uncorrected bit errors in a packet.

The Reed-Solomon code used for the error correction is a (208, 188) code which means that for every 188-byte data packet, 208-188 = 20 bytes of error correction are added, and the code can correct up to 8 incorrect bytes in the packet (DVB-T, External encoder).

There are also wrinkles in how the logical packets are put into the physically broadcast packets to allow the Reed-Solomon error correction to make the correction more robust against noise bursts that are "longer" than the number of bits that can be corrected in a burst.

I'm pretty sure (but not certain) that the reported BER is the number of uncorrected bits, but I don't know what interval it's reported for.

An uncorrected error is most likely to affect the video stream, and next most likely to affect the audio stream you're listening to, because they're the highest data flow streams. Its actual visibility or audibility depends enormously on exactly where it falls in the packetised streams. A small bit error that is in a quickly-changing part of the video is much less likely to be noticed that a similar error in a slowly changing part of the image. Because of the way MPEG is encoded, quickly-changing parts of the image are updated more often on the screen than slowly-changing or static parts of the image (and yes, it's a bit more complicated than that ).

It's the job of the frequently-mentioned demuxes (demultiplexers) to split the broadcast packets into the packetised data streams that are needed to view the selected digital channel from the data in the broadcast channel.

Okay. Are you saying this error could be any 3 of the ones mentioned or just one for this one due to the OverlayHD.

I've now covered most of the flashing with the same colours but can't it be diverted to a report or log. Why must it flash?

[MrQuade]

I've now covered most of the flashing with the same colours but can't it be diverted to a report or log. Why must it flash?

There is no need to log it since a certain number of correctable errors are just an expected result of wireless communications. As I said, they are simply routine an nothing to worry abut.

As to why it should flash, you'd need to ask IanSav why he felt that they were.
This is not an indication that is shown on the default skins, and is really quite pointless and distracting when seen in OverlayHD. I recall providing similar feedback to IanSav a few years ago.

[Paul_oz53]

To clarify: OverlayHD doesn't create bit errors. Rather, OverlayHD displays the bit error information above a certain threshold as a flashing fill in the S/Q screen boxes whereas the standard skin does not. Like MrQuade, it's a feature that I would turn off if I could but I much prefer OverlayHD despite that - for reasons I no longer recall.

Therefore, the errors that are reported are as prl described - due to any of a number of inbuilt error correction mechanisms that the ordinary user is blissfully unaware off.

When I installed a V2 for another member we found her aerial signal was only 50 dB. The preferred level for good reception is 70 dB. After fitting a masthead amplifier to her "digital" aerial, the problem with reception was fixed. YMMV.

[Altimes]

Recently updated U4 with online update to beyonwiz 19.3.20210726 (20200822-138-gb9ea638). I then noticed the flashing bitError indicator in OverlayHD that I had never noticed before. Anything that is likely to have triggered this, or has it always been there ?

Having read some of the recent message from others also, noticing the annoying flashing bit-error, I was browsing through the OverlayHD settings to see if there was some color setting to, at least, diminish it. Nothing found, so I pressed Red to cancel out and the box crashed.

The crashing bit of the log file is

{1356}< 661.696> KEY: 398 make KEY_RED ('RED',)
{1356}< 661.697> [ActionMap] calling cancel (SetupActions)
consoleFd 10
[MAIN] executing main
TuxTxt service started 912
TuxTxt running thread...(912)
{1356}< 661.698> Traceback (most recent call last):
{1356}< 661.698> File "/usr/lib/enigma2/python/Components/ActionMap.py", line 79, in action
{1356}< 661.698> File "/usr/lib/enigma2/python/Components/ActionMap.py", line 60, in action
{1356}< 661.698> File "/usr/lib/enigma2/python/Plugins/Extensions/OverlayHD/plugin.py", line 569, in keyCancel
{1356}< 661.698> File "/usr/lib/enigma2/python/Plugins/Extensions/OverlayHD/plugin.py", line 577, in confirmCancel
{1356}< 661.698> AttributeError: 'OverlayHDSkinManager' object has no attribute 'cancelMsg'
{1356}< 661.698> [ePyObject] (CallObject(<bound method NumberActionMap.action of <Components.ActionMap.NumberActionMap instance at 0xad5b5eb8>>,('SetupActions', 'cancel')) failed)
{1357}< 665.553> [gRC] main thread is non-idle! display spinner!
{1356}< 671.705> KEY: 398 break KEY_RED ('RED',)
{1356}< 671.706> [ActionMap] skipping red (ColorActions)
{1356}< 671.707> KEY: 398 make KEY_RED ('RED',)
{1356}< 671.707> [ActionMap] calling cancel (SetupActions)
{1356}< 671.708> Traceback (most recent call last):
{1356}< 671.708> File "/usr/lib/enigma2/python/Components/ActionMap.py", line 79, in action
{1356}< 671.708> File "/usr/lib/enigma2/python/Components/ActionMap.py", line 60, in action
{1356}< 671.708> File "/usr/lib/enigma2/python/Plugins/Extensions/OverlayHD/plugin.py", line 569, in keyCancel
{1356}< 671.708> File "/usr/lib/enigma2/python/Plugins/Extensions/OverlayHD/plugin.py", line 577, in confirmCancel
{1356}< 671.709> AttributeError: 'OverlayHDSkinManager' object has no attribute 'cancelMsg'
{1356}< 671.709> [ePyObject] (CallObject(<bound method NumberActionMap.action of <Components.ActionMap.NumberActionMap instance at 0xad5b5eb8>>,('SetupActions', 'cancel')) failed)
{1356}< 671.709> KEY: 398 break KEY_RED ('RED',)
{1356}< 671.710> [ActionMap] skipping red (ColorActions)
{1356}< 671.711> [InputHotplug] connectionLost? [Failure instance: Traceback (failure with no frames): <class 'twisted.internet.error.ConnectionLost'>: Connection to the other side was lost in a non-clean fashion: Connection lost.
]{1356}< 671.711>
{1356}< 671.714> dvb time sync disabled... so set RTC now to current linux time! Wed 28 Jul 2021 17:03
{1356}< 671.715> set wakeup time to Wed 28 Jul 2021 18:00
{1356}< 671.723> PowerTimerWakeupAuto True
{1356}< 671.723> [eDVBServicePlay] [Timeshift] stopTimeshift
{1356}< 671.728> [eFilePushThreadRecorder] stopping thread.
{1415}< 671.728> [eDVBRecordFileThread] waiting for aio to complete
{1415}< 671.728> [eDVBRecordFileThread] buffer usage histogram (40 buffers of 188 kB)
{1415}< 671.728> [eDVBRecordFileThread] 0: 2
{1415}< 671.728> [eDVBRecordFileThread] 1: 130
{1415}< 671.741> [eFilePushThreadRecorder] THREAD STOP
{1356}< 671.742> [eDVBServicePlay] remove timeshift files
{1356}< 671.742> [eThread] old thread joined 0
{1504}< 671.742> [setIoPrio] best-effort level 7 ok
{1504}< 671.742> [eBackgroundFileEraser] deleting '/media/hdd/timeshift/timeshift.k63YS3.del'
{1504}< 671.742> [eBackgroundFileEraser] deleting '/media/hdd/timeshift/timeshift.k63YS3.sc.del'
{1356}< 671.743> [eDVBCAService] free slot 0 demux 0 for service 1:0:19:225:221EEEE0000:0:0:0:
{1356}< 671.743> [eDVBCAService] free service 1:0:19:225:221EEEE0000:0:0:0:
{1356}< 671.751> [eTSMPEGDecoder] decoder state: play, vpid=ffffffff, apid=ffffffff
{1356}< 671.751> [eDVBPCR0] DEMUX_STOP ok
{1356}< 671.754> [eDVBPCR0] destroy
{1356}< 671.754> [eDVBVideo0] DEMUX_STOP ok
{1356}< 671.755> [eDVBVideo0] VIDEO_STOP ok
{1356}< 671.755> [eDVBVideo0] VIDEO_CLEAR_BUFFER ok
{1356}< 671.755> [eDVBVideo0] destroy
{1356}< 671.755> [eDVBAudio0] AUDIO_STOP ok
{1356}< 671.755> [eDVBAudio0] DEMUX_STOP ok
{1356}< 671.756> [eDVBAudio0] AUDIO_CLEAR_BUFFER ok
{1356}< 671.756> [eDVBAudio0] AUDIO_CONTINUE ok
{1356}< 671.756> [eDVBAudio0] destroy
{1356}< 671.756> [eDVBText0] DEMUX_STOP ok
{1356}< 671.757> [eDVBText0] destroy
{1356}< 671.758> [eDVBResourceManager] start release channel timer
{1356}< 671.797> [MAIN] (exit code 5)
{1356}< 671.797> [eDVBDB] ---- saving lame channel db
{1356}< 671.798> [eDVBDB] saved 5 channels and 60 services!
{1356}< 671.809> [eDVBResourceManager] release cached channel (timer timeout)
{1356}< 671.809> [eDVBLocalTimerHandler] remove channel 0xc155c0
{1356}< 671.809> [EPGC] remove channel 0xc155c0
{1356}< 671.809> [eDVBResourceManager] stop release channel timer
{1356}< 671.902> [eDVBLocalTimeHandler] set RTC to previous valid time
{1356}< 671.902> [eDVBLocalTimerHandler] set RTC Time
{1356}< 671.902> [eInit] - (41) Stream server
{1356}< 671.902> [eInit] - (41) Encoders
{1356}< 671.902> [eInit] - (41) eServiceFactoryDVB
{1356}< 671.902> [eInit] - (41) eServiceFactoryFS
{1356}< 671.902> [eInit] - (41) eServiceFactoryMP3
{1356}< 671.902> [eInit] - (41) eServiceFactoryM2TS
{1356}< 671.902> [eInit] - (41) eServiceFactoryHDMI
{1356}< 671.902> [eInit] - (41) eServiceFactoryTS
{1356}< 671.902> [eInit] - (41) eServiceFactoryWebTS
{1356}< 671.902> [eInit] - (41) eServiceFactoryDVD
{1356}< 671.902> [eInit] - (40) eServiceCenter
{1356}< 671.902> [eInit] - (35) CA handler
{1356}< 671.902> [eInit] - (35) CI Slots
{1356}< 671.902> [eInit] - (30) eActionMap
{1356}< 671.902> [eInit] - (22) Hdmi CEC driver
{1356}< 671.902> [eInit] - (21) input device driver
{1356}< 671.960> [eInit] - (20) AVSwitch Driver
{1356}< 671.960> [eInit] - (20) misc options
{1356}< 671.960> [eInit] - (20) RC Input layer
{1356}< 671.960> [eInit] - (20) UHF Modulator
{1356}< 671.960> [eInit] - (20) DVB-CI UI
{1356}< 671.960> [eInit] - (15) eWindowStyleManager
{1356}< 671.960> [eInit] - (10) gRC
{1356}< 671.960> [gRC] waiting for gRC thread shutdown
{1356}< 671.960> [gRC] thread has finished
{1356}< 671.960> [eInit] - (9) Font Render Class
{1356}< 671.960> [eInit] - (9) gLCD
{1356}< 671.960> [eInit] - (9) GFBDC
{1356}< 671.964> [eInit] - (8) graphics acceleration manager
{1356}< 671.964> [eInit] - (5) Tuxtxt
{1356}< 671.964> [eInit] - (1) Background File Eraser
{1356}< 671.964> [eInit] reached rl -1
TuxTxt stopped service 912

Anyone else see something similar?

TIA Alan.

[MrQuade]

Recently updated U4 with online update to beyonwiz 19.3.20210726 (20200822-138-gb9ea638). I then noticed the flashing bitError indicator in OverlayHD that I had never noticed before. Anything that is likely to have triggered this, or has it always been there ?

Yes it has always been there on the OverlayHD skin.

I thought for a moment that this was a double post from this discussion today.

I don't know why two separate users suddenly discovered this on the same day . Maybe the bad weather this week has highlighted some antenna weaknesses.

There is also a discussion in the thread about the best way to hide the flashing by setting a custom colour.

As for the crash...not sure. Maybe the skin is missing a handler screen for cancelling that page.

[Altimes]

Thanks, I had seen that discussion. For me, it was coincidental with the update, and as we all know, "Correlation IS causation... ". I had simply never seen the bit-error stuff before. Maybe I should reseat the antenna connections and see it it "goes away". I am a little puzzled that it would be flashing when the S / Q were showing 91%/99% respectively.

Regards,

Alan.

[Grumpy_Geoff]

I had simply never seen the bit-error stuff before. Maybe I should reseat the antenna connections and see it it "goes away". I am a little puzzled that it would be flashing when the S / Q were showing 91%/99% respectively.

Perhaps you were tuned via a USB tuner?
According to peteru, the internal tuners don't/can't pass that info.

[sub3R]

Anyone else see something similar?

So are you saying when you press the MENU button from Live TV, open OverlayHD Skin Manager from the LHS list, scroll through the options in the skin manager, then press the RED button to cancel, it immediately crashed? Is that right?

My U4 is still on 19.3.20210709 & I couldn’t replicate that with the f/w I’m running, but I didn’t scroll through any options. I just opened OverlayHD as above then pressed the RED button to cancel, & it cancelled without crashing.

I can remember a long time ago I experienced a crash with an older f/w version after I scrolled through the OverlayHD Skin Manager options, including expanding all the options. I didn’t worry about it at the time because I couldn’t replicate it, but maybe I didn’t expand all the options.

Where is this flashing BER indicator in OverlayHD? I've never seen that.
Edit: Reading the post MrQuade linked to it appears to be in a theme that I probably don’t have.

[MrQuade]

Where is this flashing BER indicator in OverlayHD? I've never seen that.
Edit: Reading the post MrQuade linked to it appears to be in a theme that I probably don’t have.

In the infobar next to the signal indicators. Follow the link I provided earlier for a picture.

It's there in the default install of OverlayHD.

[sub3R]

In the infobar next to the signal indicators. Follow the link I provided earlier for a picture.

It's there in the default install of OverlayHD.

Thanks, I edited my post about when you posted.

I just updated to 19.3.20210726 & now I get that flashing BER indicator. The flashing is in your face isn’t it?

I’ll have a read of one of the topics you linked to see how to get rid of it. I wonder why it only appeared with this f/w update.

[sub3R]

My U4 is still on 19.3.20210709 & I couldn’t replicate that with the f/w I’m running, but I didn’t scroll through any options. I just opened OverlayHD as above then pressed the RED button to cancel, & it cancelled without crashing.

I just updated to 19.3.20210726 & I got the same results as when on 19.3.20210709, i.e. no crash. But I didn’t scroll through OverlayHD Skin Manager options.

I suspect if I scroll through OverlayHD Skin Manager & expand the options I could make it crash, but at this stage I don’t want to do that.

[sub3R]

Like MrQuade, it's a feature that I would turn off if I could but I much prefer OverlayHD despite that - for reasons I no longer recall.

How about; it can be configured so background Live TV doesn’t show through any menus. But there are many more that I also can’t recall.

I've never had the flashing BER on OverlayHD with any previous f/w versions. It has only become apparent with the latest 19.3.20210726 f/w. The flashing is very distracting.

[Paul_oz53]

Like MrQuade, it's a feature that I would turn off if I could but I much prefer OverlayHD despite that - for reasons I no longer recall.

How about; it can be configured so background Live TV doesn’t show through any menus. But there are many more that I also can’t recall.

I've never had the flashing BER on OverlayHD with any previous f/w versions. It has only become apparent with the latest 19.3.20210726 f/w. The flashing is very distracting.

You're right ! Goes back to trying to use it to view photos in the early days.

I mainly see the flashing in very bad weather or summer evening whispy clouds. I shortened the info-bar display time so I see less of it.

[sub3R]

I mainly see the flashing in very bad weather or summer evening whispy clouds. I shortened the info-bar display time so I see less of it.

I may have to do the same. Doing the latest 19.3.20210726 f/w update has definitely caused it to appear on our U4. Never seen it before & I took particular notice just prior to the update - it isn’t something one would miss. Signal strength & quality is excellent.

I wish there was some way I could blank it out. Maybe there is something in the OverlayHD Skin Manager options.

[sub3R]

I wish there was some way I could blank it out. Maybe there is something in the OverlayHD Skin Manager options.

Now fixed (blanked out anyway). In OverlayHD Skin Manager, I changed under; 'Show panel and plugin colour settings' group > 'Tuner signal error colour’ to the background colour (in my case ‘black'). I've never had to do this before.

Both U4s were set to ‘orange red’, yet it was only the U4 that I today updated to 19.3.20210726 that has the now flashing BER on every service. Prior to this I have never seen this & the U4 that hasn’t been updated doesn’t show any flashing BER even with ‘Tuner signal error colour’ still set at 'orange red'. Pretty much identical good signal strength & quality readings on both U4s.

[sub3R]

... noticing the annoying flashing bit-error, I was browsing through the OverlayHD settings to see if there was some color setting to, at least, diminish it. Nothing found, ...

See here.

[adoxa]

I think it's due to this change:

Code: Select all

-       else:
-           ber = self.source.ber
-           if ber is None:
-               ber = 0
-           return ber > 0
+       elif self.type == self.BER:
+           return self.source.ber is not None

Previously 0 was False, now it's True.

[Altimes]

Thanks foe extra pointer. I had been digging through the likely groupings without success. For anyone else, it is in the “Show panel and plugin colour settings” Group.

Additionally, the crash is readily reproducible, by me at least. Open overlay HD settings, turn on/off group settings, cancel => crash.

Regards, Alan.

[prl]

I think I know what's causing the always-on bit error indicator in OverlayHD. I'm currently working out a fix.

[prl]

Adoxa is correct. I'm working on a fix.

[unilaw]

Adoxa is correct. I'm working on a fix.

Hey Peter,

Great. I'm glad I brought it up. It was detailed by another poison when I looked up the error. That was some time ago. I'm okay if the Admins want to move this to another topic feed.

[prl]

As people may have noticed, I've brought together the two topics about the BER indicator problems in OverlayHD together in this topic.

Please post here about this issue.

[prl]

I'm working on a fix, but I'm not sure how best to apply it for Beyonwiz, because the current release of OverlayHD (1.82E) is a long way ahead of the most recent version for Beyonwiz (0.84, I think).

Catching up to the current OverlayHD requires changes to the Beyonwiz firmware, at least getting the new VirtualKeyboard implementation from one of the European enigma2 distributions. That may also need further changes to the Beyonwiz firmware to support it. It will need changes to the Beyonwiz pre-loaded skins to support it properly.

[sub3R]

For anyone else, it is in the “Show panel and plugin colour settings” Group.

I’ll add that part to my earlier post.

Additionally, the crash is readily reproducible, by me at least. Open overlay HD settings, turn on/off group settings, cancel => crash.

Assuming you meant ‘OverlayHD uses grouped settings’ I couldn’t replicate that with either 19.3.20210709 or 19.3.20210726 f/w. I tried every combination with that particular option.

There must be another option that is different between our Wizzes because I can remember making it crash by doing something in OverlayHD Skin Manager many moons ago. I leave all options enabled except for 'OverlayHD plugin always active' & I haven't had it crash since.

[Paul_oz53]

I'm working on a fix, but I'm not sure how best to apply it for Beyonwiz, because the current release of OverlayHD (1.82E) is a long way ahead of the most recent version for Beyonwiz (0.84, I think).

Catching up to the current OverlayHD requires changes to the Beyonwiz firmware, at least getting the new VirtualKeyboard implementation from one of the European enigma2 distributions. That may also need further changes to the Beyonwiz firmware to support it. It will need changes to the Beyonwiz pre-loaded skins to support it properly.

The skin version I use is OverlayHD 1.70.

[sub3R]

Catching up to the current OverlayHD requires changes to the Beyonwiz firmware, at least getting the new VirtualKeyboard implementation from one of the European enigma2 distributions. That may also need further changes to the Beyonwiz firmware to support it. It will need changes to the Beyonwiz pre-loaded skins to support it properly.

Do you think it would be worthwhile sending a PM to IanSav? The last time I had communication with Ian he mentioned that if something is broken in OverlayHD please bring it to his attention. While not broken this seems to be a compatibility issue with the latest f/w.

As Paul mentioned ver: 1.70 is the latest for our system.

I don’t need the flashing BER indicator in OverlayHD & blanking it out by changing the BER indicator to the same colour as the background colour is a workaround that I’m happy with. I’m not sure if the continuous flashing that I now can’t see will cause any issues though.

[adoxa]

Additionally, the crash is readily reproducible, by me at least. Open overlay HD settings, turn on/off group settings, cancel => crash.

Worked fine for me (1.66 and 1.70).

[Altimes]

Seeing the reference to OverlayHD 1.70, my instinctive response was that I had only 1.6x installed. I got a copy of Version 1.70 and upgraded the U4. And yes, I had 1.68 installed. After the upgrade, the crash problem been corrected. Red button after change now gives a message like "do you really want to exit without saving?".

So OverlayHD crash on Red Button problem resolved.

Alan.

[prl]

I'm working on a fix, but I'm not sure how best to apply it for Beyonwiz, because the current release of OverlayHD (1.82E) is a long way ahead of the most recent version for Beyonwiz (0.84, I think).

The skin version I use is OverlayHD 1.70.

Thanks for the clarification. So my test version of OverlayHD is way behind. I'll use something newer.

But even if the latest usable Beyonwiz version is 1.70, that's still a problem if a fix is applied over 1.82E. However, the the BER indicator problem is still in 1.82E.

In the meantime, sub3R's suggestion of changing the BER background is a good one. You could also even change the foreground colour for the BER to something completely transparent.

[prl]

Catching up to the current OverlayHD requires changes to the Beyonwiz firmware, at least getting the new VirtualKeyboard implementation from one of the European enigma2 distributions. That may also need further changes to the Beyonwiz firmware to support it. It will need changes to the Beyonwiz pre-loaded skins to support it properly.

Do you think it would be worthwhile sending a PM to IanSav? The last time I had communication with Ian he mentioned that if something is broken in OverlayHD please bring it to his attention. While not broken this seems to be a compatibility issue with the latest f/w.

I'll most likely send submit an update to Ian.

The way I intend to fix this will also allow the skin writer to set an upper threshold for displaying the BER warning. In the old (working) code, it would flash the BER indicator if the BER was non-zero. It probably can be a higher threshold for the indicator than 1.

[sub3R]

... changing the BER background is a good one. You could also even change the foreground colour for the BER to something completely transparent.

Actually that’s what I meant, but it doesn't read that way - I'll correct that. I changed the BER indicator to the same colour as the background colour. In my setup the background colour is black.

The way I intend to fix this will also allow the skin writer to set an upper threshold for displaying the BER warning. In the old (working) code, it would flash the BER indicator if the BER was non-zero. It probably can be a higher threshold for the indicator than 1.

That sounds like a good way to go.

[sub3R]

So OverlayHD crash on Red Button problem resolved.

So it appears that Ian fixed that issue some time after 1.68 which is why I couldn’t replicate it in 1.70. That’s good to know.

[prl]

Ian has got a fix ready for the BER indicator along the same lines as I was thinking. The problem is that it uses code that seems to be broken across all enigma2 distributions (including the Beyonwiz firmware).

It will also only appear in OverlayHD versions newer than 1.82E. The Beyonwiz code needs further work to be able to use that.

[Paul_oz53]

Ian has got a fix ready for the BER indicator along the same lines as I was thinking. The problem is that it uses code that seems to be broken across all enigma2 distributions (including the Beyonwiz firmware).

It will also only appear in OverlayHD versions newer than 1.82E. The Beyonwiz code needs further work to be able to use that.

Until there is a fix, Sub3R's tactic works perfectly! Set the "tuner error colour" parameter to match the background colour (black is the default).