Superb quality and spec AB-Com PULSe 4K SE. Crazy offer! Only £99! FREE UK DELIVERY! 4K UHD, Enigma 2, Multiboot 4 images & more!...
Superb quality and spec AB-Com PULSe 4K Rev II Twin Satellite tuner only £149! FREE UK DELIVERY! 4K UHD, Enigma 2, SATA HDD facility, Multiboot 4 images & more!...

[VU+ Duo4K SE] Annoying Pop-up

sandiego69

Forum Supporter
Donated Member
Joined
Jan 26, 2013
Messages
218
Reaction score
0
Points
16
Since the previous and the latest build I have been getting the Pop-up at random times. The only way to clear it is by pressing the OK button.

I am not scanning or any other background function at the time.

Can anybody throw any light on how to get rid of this?

Please see attached jpg.
 

Attachments

  • screenshot_2024-10-22_21-41-58.webp
    screenshot_2024-10-22_21-41-58.webp
    49.6 KB · Views: 46
Since the previous and the latest build I have been getting the Pop-up at random times. The only way to clear it is by pressing the OK button.

I am not scanning or any other background function at the time.

Can anybody throw any light on how to get rid of this?

Please see attached jpg.

how are you connected to the Internet?? Looks like the software update check is happening before the network is ready.
To short term fix, try setting background check to off...> Menu/Setup/System/Software Update/Settings
 
Thank you for the suggestion, however, does that not defeat the object of not being informed of a software update?
 
Thank you for the suggestion, however, does that not defeat the object of not being informed of a software update?
Quote….“ To short term fix,“
Q. How are you connected to the network??

You have a Multiboot capable box….easier, as fast and safer than software update
 
Multiboot not used. RJ45 direct to Router. So, as a short term fix, is this something that will be fixed in an upcoming build?
 
Do you use DHCP in your home network? Keep in mind that DHCP is a little bit slower than static option to get new IP every time you switch your receiver on. I don't know if this could be a problem in the Openvix, but surely the process is faster using static IPs.
Also, I think that being informed of new software updates is not a major problem. You can always visit this web site and you are immediately informed, then you can launch the update process manually.
 
Multiboot not used. RJ45 direct to Router. So, as a short term fix, is this something that will be fixed in an upcoming build?

So need the full debug log from you….. as probably something to do with your connection. Until recently we checked connection was viable via google, but users said was not necessary.
So turn off my suggestion.
Enable debug logs… menu/setup/system/logs/settings….> enable, save to hdd/usb, local time…… attach & post.
will have a look at the debug.
 
Some observations...

The box seems to be "permanently" on, so it's not an issue with timing bringing up the network initially.

This:
<308336.734796> [opentv_zapper]download completed... Next download scheduled for Wed 20 Nov 2024 10:26:22 GMT
would indicate that the network is working, but there is then and error ~16mins later:
<309366.985352> OnlineVersionCheck
Error: [Failure instance: Traceback: <class 'TypeError'>: 'TimeoutError' object is not subscriptable

This is also reported:
<310366.689603> [EPGImport][threadGetPage] error: HTTPConnectionPool(host='rytecepg.wanwizard.eu', port=80): Read timed out. (read timeout=15)
<310366.689662> [EPGImport][downloadFail] download failed: HTTPConnectionPool(host='rytecepg.wanwizard.eu', port=80): Read timed out. (read timeout=15)
but it is followed by a successful download:
<310396.751692> [EPGImport][downloadFail] Attempting alternative URL for Basic
<310396.751744> [EPGImport][downloadFail] try alternative download url http://epgspot.com/rytec_epg/rytecMisc.xz
<310396.752364> [EPGImport][urlDownload] Downloading: http://epgspot.com/rytec_epg/rytecMisc.xz to local path: /media/hdd/zfbwe.xz
<310396.912431> [EPGImport][afterDownload] unlink /media/hdd/zfbwe.xz
so the network is working.

The actual pop-up message seems to be complaining about this:
Error: [Failure instance: Traceback: <class 'TypeError'>: 'TimeoutError' object is not subscriptable
rather then the fact that it has actually timed out. It's supposed to only print a message to the debug log about this.


PS: I also see that the broadcast address is set to 0.0.0.0 (as is my box). Not a problem, but that is not the correct setting.
 
Sorry for delay. On extended holiday.

Attached debug log.

so can you try this?
using for example putty and filezilla.

telnet into box with putty and stop receiver with init 4 ( space between)
with filezilla or similar copy attachment to /usr/lib/enigma2/python/Components (probably worth renaming OnlineUpdateCheck.pyc to something)
Then in putty type init 3 (space between)

and see how it goes!
 

Attachments

Last edited:
so can you try this?
using for example putty and filezilla.

telnet into box with putty and stop receiver with init 4 ( space between)
with filezilla or similar copy attachment to /usr/lib/enigma2/python/Components (probably worth renaming OnlineUpdateCheck.pyc to something)
Then in putty type init 3 (space between)

and see how it goes!

assuming it works, would be interested in seeing debug log
 
so can you try this?
using for example putty and filezilla.....
and see how it goes!
As I noted. The error is not (just) that the connexion times out.
The error is in the code that is trying to log the timeout to the debug log.

EDIT:
A quick test script reveals that although a timeout on the urlopen() line results in a TimeoutError that Exception is being handled by the URLError except branch!!! And teh code there can't handle a TimeoutError correctly.
 
Last edited:
A quick test script reveals that although a timeout on the urlopen() line results in a TimeoutError that Exception is being handled by the URLError except branch!!! And the code there can't handle a TimeoutError correctly.
And the reason for this is that a timeout on urlopen() does NOT signal a TimeoutError. It signals a URLError with a reason of "timed out".
And the URLError.reason is just a piece of text, so you can't index it.

So:
Code:
            except URLError as err:
                print("[OnlineUpdateCheck][getFeedStatus] ERROR:", err.reason[0])
should be:
Code:
            except URLError as err:
                print("[OnlineUpdateCheck][getFeedStatus] ERROR:", err.reason)
and the pop-up will go away.
The timeout will still be there.
 
And the reason for this is that a timeout on urlopen() does NOT signal a TimeoutError. It signals a URLError with a reason of "timed out".
And the URLError.reason is just a piece of text, so you can't index it.

So:
Code:
            except URLError as err:
                print("[OnlineUpdateCheck][getFeedStatus] ERROR:", err.reason[0])
should be:
Code:
            except URLError as err:
                print("[OnlineUpdateCheck][getFeedStatus] ERROR:", err.reason)
and the pop-up will go away.
The timeout will still be there.
Maybe look at the changed .py?
 
Last edited:
Maybe look at the changed .py?
OK. But according to the documentation:
exception urllib.error.URLError
The handlers raise this exception (or derived exceptions) when they run into a problem. It is a subclass of OSError.
reasonThe reason for this error. It can be a message string or another exception instance.
​
So just check for reason being a str. If it is, print it. If it isn't print [0]. Will handle any other oddity too.
 
OK. But according to the documentation:
So just check for reason being a str. If it is, print it. If it isn't print [0]. Will handle any other oddity too.

since python 3.10, timeouts are handled in URLerror, but may not be a timeout that is handled here, which is why its using standard code to check for a timeout (I didn't invent this its an accepted way of checking) and if not see if that can be handled
I need the user to test as I have not been able to recreate the exception.
 
IMO, the easiest fix is this:

Code:
					except URLError as err:
						print("[OnlineUpdateCheck][getFeedStatus] ERROR:", str(err.reason))
						trafficLight = str(err.reason)
 
BTW, this code is horrible. For what reason all those exceptions.

I'd much rather be using the requests module and response.raise_for_status().
 
I need the user to test as I have not been able to recreate the exception.

This script can do it, but you'll have to put in a name that resolves to a system that is not up....

Code:
[FONT=monospace][COLOR=#000000]#!/usr/bin/python3 [/COLOR]
# 

import socket 
import sys 
from urllib.request import urlopen, Request 
from urllib.error import HTTPError, URLError 

socket.setdefaulttimeout(2) 

sd = None 
try: 
    req = Request("http://samsungtv.lacknet/TrafficLightState.php") 
    d = urlopen(req, timeout=3) 
    print("[OnlineUpdateCheck][NetworkUp] PASSED") 
    result = True 
except HTTPError as err: 
    print("FAILED HTTPError:", err) 
    result = False 
except URLError as err: 
    print("FAILED URLError:", sys.exc_info()[0]) 
    if type(err.reason) == TimeoutError: 
        print("err.reason:", err.reason) 
    else: 
        print("err.reason[0]:", err.reason[0]) 
    result = False 
except: 
    print("FAILED unknown:", sys.exc_info()[0]) 
    result = False 
finally: 
    if sd is not None: 
        try: 
            sd.shutdown(socket.SHUT_RDWR) 
        except: 
            pass 
        sd.close()
[/FONT]
 
This script can do it, but you'll have to put in a name that resolves to a system that is not up....

Code:
[FONT=monospace][COLOR=#000000]#!/usr/bin/python3 [/COLOR]
# 

import socket 
import sys 
from urllib.request import urlopen, Request 
from urllib.error import HTTPError, URLError 

socket.setdefaulttimeout(2) 

sd = None 
try: 
    req = Request("http://samsungtv.lacknet/TrafficLightState.php") 
    d = urlopen(req, timeout=3) 
    print("[OnlineUpdateCheck][NetworkUp] PASSED") 
    result = True 
except HTTPError as err: 
    print("FAILED HTTPError:", err) 
    result = False 
except URLError as err: 
    print("FAILED URLError:", sys.exc_info()[0]) 
    if type(err.reason) == TimeoutError: 
        print("err.reason:", err.reason) 
    else: 
        print("err.reason[0]:", err.reason[0]) 
    result = False 
except: 
    print("FAILED unknown:", sys.exc_info()[0]) 
    result = False 
finally: 
    if sd is not None: 
        try: 
            sd.shutdown(socket.SHUT_RDWR) 
        except: 
            pass 
        sd.close()
[/FONT]

Gordon, how is that supposed to work? You have a variable "sd" set to None, and will always be None.

But anyway, this code is fragile and exception code should not be. We should be using the simplest solution that gets the job done.
 

OpenViX Feeds Status

Back
Top