Superb quality and spec AB-Com PULSe 4K SE. Crazy offer! Only £129! 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 £179! FREE UK DELIVERY! 4K UHD, Enigma 2, SATA HDD facility, Multiboot 4 images & more!...

[VU+ Solo2] Constant Crashing when switching between Sly and VM Channels

  • Thread starter Thread starter rborhara
  • Start date Start date
R

rborhara

Guest
Hi im running Openvix, and only this week installed the Sundtek DVB-C tuner,
I do notice when im watching a sat channel and press record or not and then flick to a Cable channel ive had several crashes - i then have to resort to power on/off on the vu solo2

ANyone else experience this bug?
 
Can you not post a crash log so others can see what is causing the crash
 
How long a delay have you got before timeshift starts automatically?

Code:
< 16917.350555> [eDVBChannel] getDemux cap=00
< 16917.350583> [eDVBResourceManager] allocate demux cap=00
< 16917.350609> [eDVBResourceManager] allocating demux adapter=0, demux=0, source=0 fesource=2
< 16917.350639> [eDVBDemux] open demux /dev/dvb/adapter0/demux0
< 16917.360562> [eInputDeviceInit] 0 160 1
KEY: 352 OK
< 16917.368742> [DVBCAHandler] no more services
< 16917.369190> [eDVBServicePlay] timeshift
< 16917.371541> [eDVBServicePlay] timeshift
< 16917.372336> [eDVBServicePlay] timeshift
< 16917.375125> [eDVBServicePlay] timeshift
< 16917.375627> [eDVBServicePlay] timeshift
< 16917.375999> [eDVBServicePlay] Start timeshift!
Traceback (most recent call last):
  File "/usr/lib/enigma2/python/Components/Timeshift.py", line 481, in autostartPermanentTimeshift
  File "/usr/lib/enigma2/python/Components/Timeshift.py", line 521, in activatePermanentTimeshift
  File "/usr/lib/enigma2/python/mytest.py", line 310, in open
    raise RuntimeError("modal open are allowed only from a screen which is modal!")
RuntimeError: modal open are allowed only from a screen which is modal!
< 16917.387776> [ePyObject] (CallObject(<bound method InfoBar.autostartPermanentTimeshift of <class 'Screens.InfoBar.InfoBar'>>,()) failed)
 
If it's a modal open, doesn't that mean it's going to wait for user input? So why would automatic timeshifting be involved?

And, of there should be a delay before starting it, then OpenVix should do that by default, not rely on user configuration.
 
Hi it was set to 2 seconds , ive changed it to 10 secs. it never had issues when i was flicking between sat tuners , but you never know . let me test it for a while
 
10 seconds is the recommended time for Timeshift when cable zapping, it has been stated many times.
 
10 seconds is the recommended time for Timeshift when cable zapping, it has been stated many times.
So it should be enforced by OpenVix itself. Currently the code (Components/UsageConfig.py) has:
Code:
        for i in (2, 3, 4, 5, 10, 20, 30):
                choicelist.append(("%d" % i, ngettext("%d second", "%d seconds"...
        for i in (60, 120, 300):
                m = i / 60
                choicelist.append(("%d" % i, ngettext("%d minute", "%d minutes"...
so remove the 2,3,4,5 options.
 
@ abu thanks. changing the time shift to 10secs not crashed since
 
So it should be enforced by OpenVix itself. Currently the code (Components/UsageConfig.py) has:
Code:
        for i in (2, 3, 4, 5, 10, 20, 30):
                choicelist.append(("%d" % i, ngettext("%d second", "%d seconds"...
        for i in (60, 120, 300):
                m = i / 60
                choicelist.append(("%d" % i, ngettext("%d minute", "%d minutes"...
so remove the 2,3,4,5 options.

But then that means those with Sky that can get away with only 3/4 seconds are forced to have minimum 10 sec delay.

Two options. Option 1 - change default to 10 secs:
Code:
config.timeshift.startdelay = ConfigSelection(default = "0", choices = choicelist)

But I would say, Option 2, change "/usr/share/enigma2/setup.xml" - description text to recommend to have 10sec delay for those with dvb-c tuners:
Code:
<setup key="timeshift" title="Timeshift settings">
	<item level="1" text="Automatically start timeshift after" description="When enabled, timeshift starts automatically in background after the specified time.">config.timeshift.startdelay</item>
 
my tuner is an external sundtek usb c tuner, rather than one built in if that makes a difference
 
But then that means those with Sky that can get away with only 3/4 seconds are forced to have minimum 10 sec delay.
Terrestrial users are forced to have 2s when they could probably get away with 0? (Not that I know, as I don't use timeshift).

But I would say, Option 2, change "/usr/share/enigma2/setup.xml" - description text to recommend to have 10sec delay for those with dvb-c tuners:
Whereas I would go with option 3, and set the minimum based on the tuner types currently in the box. Why get the user to do something (and hence possibly get it wrong) when the box can do it automatically?
 
TimeShift is off by default, only the user enables it & has the option then to configure when it kicks in.
 
TimeShift is off by default, only the user enables it & has the option then to configure when it kicks in.
And I'm suggesting that the options given to the user make sense for the type of tuners in the box.
Do you like having users suffering and needing to report crashes which could be avoided?
 
Do you like having users suffering and needing to report crashes which could be avoided?

Nope, original coding was done for Sat boxes, current coding gives the user options to set what they want to use.
IMO, the crash should & will be fixed when re-produced regularly, rather than limiting TS options that currently work.
 
Using onboard tuner, automatic timeshift starting at two seconds does not crash when swapping between sat and cable.
 
I think the problem may be limited to usb tuners, because I use a mix of both on most of my boxes I set it to 10 seconds by default.
 
Nope, original coding was done for Sat boxes, current coding gives the user options to set what they want to use.
OK.
So you don't mind setting Image Backups to be backgroundable by users who know that they will run that way without crashing?
 
OK.
So you don't mind setting Image Backups to be backgroundable by users who know that they will run that way without crashing?
That's a different thread. Let's not mix them up.

Problem is not tuner type. It is that some tuners initialize faster than others. This varies across brands, and across tuners within the same brand.

Can you suggest an automatic logic that could deal with that?
 

OpenViX Feeds Status

Back
Top