View Full Version : [VU+ Solo2] Constant Crashing when switching between Sly and VM Channels
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
yes mate will do , its enigma2 crashing
abu baniaz
11-01-16, 00:43
How long a delay have you got before timeshift starts automatically?
< 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
DaMacFunkin
12-01-16, 09:19
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:
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:
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:
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:
<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.
abu baniaz
13-01-16, 06:48
Using onboard tuner, automatic timeshift starting at two seconds does not crash when swapping between sat and cable.
I have my time shift setting set to 5 seconds on my et10000 which both cable and sat tuners and have never had a problem.
DaMacFunkin
13-01-16, 10:32
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?
That's a different thread. Let's not mix them up.I was equating the logic, not the thread.
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?Well, it depends on what happens when it goes wrong. If it throws an exception than a try X/except AddTimerRedoIn10secs() might do it. Essentially, detect that it has failed, set a timer to try again in 10s and gracefully unwind.
OK.
So you don't mind setting Image Backups to be backgroundable by users who know that they will run that way without crashing?
No idea what that has to do with this thread? :confused:
Any BSOD should & can be fixed, with the proper logs provided...
outrage_uk
15-01-16, 05:51
Timeshift set to 2 seconds on GigaBlue Quad Plus never crashed when changing between Sat and Cable - using on board "GigaBlue DVB-C/T2 NIM (SI4768)" tuners.
Powered by vBulletin® Version 4.2.5 Copyright © 2024 vBulletin Solutions Inc. All rights reserved.