View Full Version : Xtrend Et10k-Timer Recording Didn’t Records Properly
Hi, since the day before yesterday many of the recording (Stb in standby mode) were bad and incomplete.
The timers I have program are on every weekdays and the resulting fault are listed as per below,
On Monday
Channels Days Timing Correct Size (Kb) Recorded Size (Kb)
1 Weekdays 18.55-20.05 2,340,000 101,515
2 Weekdays 19.25-20.05 1,400,000 0
1 Weekdays 19.55-21.05 2,340,000 0
2 Weekdays 20.55-22.05 2,340,000 Never Start
1 Weekdays 21.55-00.05 2,340,000 1,264,449
On Tuesday
Channels Days Timing Correct Size (Kb) Recorded Size (Kb)
1 Weekdays 18.55-20.05 2,340,000 79,692
2 Weekdays 19.25-20.05 1,400,000 1
1 Weekdays 19.55-21.05 2,340,000 1
2 Weekdays 20.55-22.05 2,340,000 779,150
1 Weekdays 21.55-00.05 2,340,000 68,769
The image is Vix v5.0.026 and didn't use any cam.
Please Help
Thanks very much
This problem seems to be solved in 028 version.
Hi Tappari, thanks for your quick reply. I had already upgraded to the latest update, hope it wont happen again.
Best Regards
I had a timer problem after upgrading to 5.0.028 yesterday. First time I've ever see this one.
Two timers were marked as disabled, despite them being created (autotimers) and running fine for the last 8 weekdays.
I didn't see any clash messages, and the bit about creating disabled timers is disabled. (I can't remember the exact wording).
One programme was half way thru', but the other was yet to start, so enabling it worked.
I'm wondering whether a long press green slipped into a green + long press yellow, which can seriously disable your timers!!!
I know it's an old-ish thread, but I'm still noticing timers getting disabled after couch flashing a new release and restoring settings and plugins.
It's always the same timer, created by autotimer, and just happens to be the first timer of the day requiring a second tuner to be available, so a clash of sorts.
The timers set for the same time for rest of the week aren't disabled.
When the settings/plugins restore has completed, 4 T2 tuners are available.
The timer can always be enabled and works fine.
that what worries me in using settings restore,i never use settings restore in case some unknown factor creeps in.
that what worries me in using settings restore,i never use settings restore in case some unknown factor creeps in.It would never put me off doing settings restores, I only reported it because the clash mechanism could be suspect during/straight after a settings restore.
I reckon you're more likely to have problems manually setting up a box every time after an image update.
I know it's an old-ish thread, but I'm still noticing timers getting disabled after couch flashing a new release and restoring settings and plugins.
It's always the same timer, created by autotimer, and just happens to be the first timer of the day requiring a second tuner to be available, so a clash of sorts.
The timers set for the same time for rest of the week aren't disabled.
When the settings/plugins restore has completed, 4 T2 tuners are available.
The timer can always be enabled and works fine.Still happens after every couch flash and setting+plugins restore.
I checked again today (->5.1.019), as soon as I could after the settings restore reboot, and the timer had already been disabled.
The box boots up to bbc1 hd (Tuner A), and the disabled timer is on the same mux.
Tuner B will already be in use by another timer when the disabled timer is due to start.
Edit: Maybe switching on debug logs before creating a settings backup might shown something?
Still happens after every couch flash and setting+plugins restore.Could you post your timers.xml and autotimer.xml files when things are in this state (ie. before you fix it)?
Also, after a couch flash there is no "setting+plugins restore", as neither has been removed.
Edit: Maybe switching on debug logs before creating a settings backup might shown something?You could leave them on permanently, set to auto-delete after ~7 days.
abu baniaz
27-02-18, 03:33
Also, after a couch flash there is no "setting+plugins restore", as neither has been removed.
Please explain further. If you flash a new image using image manager or usb for that matter, how do you retain old timer files?
Also, after a couch flash there is no "setting+plugins restore", as neither has been removed.
Do you mean software update or a couch flash.
A couch flash has a settings and plugin restore and if you say no to this option the previously downloaded plugins are not seen in the pluin browser, the wizard(s) kick in for you to configure certain aspects of the box, there are no timers or auto-timers etc. A couch flash behaves the same as a USB flash.
Please explain further. If you flash a new image using image manager or usb for that matter, how do you retain old timer files?Sorry, mea culpa. Brain fail on what a "couch flash" was. I was thinking of an update. (I rarely do couch flashes - little need to).
But the "please post xml files" is still true.
I've reduced the autotimers and timers down to the absolute minimum, and it still happens.
Look North today 18:25-19:06 should use tunerB
Emmerdale today 18:58-19:36 should use tunerA - gets disabled.
timers_on_backup.xml and autotimer_on_backup.xml are the versions on the backup which were restored.
timers.xml and autotimer.xml are the versions after the restore with the timer disabled.
Debug log shows some significant references to the timer.
autotimer.xml refuses to attach for some reason.
Attached ok this time....
If the logs don't come up with anything, I'll maybe try a couch flash without a settings restore, switch on debug logs, reboot, restore settings and see what happens??
Are all timers disabled during a settings restore to prevent them starting up prematurely before rebooting, and then enabled again?
Are all timers disabled during a settings restore to prevent them starting up prematurely before rebooting, and then enabled again?Even if a timer started up before a reboot it would start again after the reboot as it is still an active timer (after the start and before the end time).
I've reduced the autotimers and timers down to the absolute minimum, and it still happens.The debug log indicates that the timer was already disabled when enigma2 started up.
Do you have the previous debug log?
The debug log indicates that the timer was already disabled when enigma2 started up.
Do you have the previous debug log?
No, I switched on debug logs and took a settings backup with the minimal timers and all enabled.
(Couch) flashed the original 5.1.019.usb, and used the wizard to restore settings. No logs, but I guess at that point the logs were being stored in the default location? (Not sure where that is anymore).
Maybe post #16 will create the necessary logs?
No, I switched on debug logs and took a settings backup with the minimal timers and all enabled.
(Couch) flashed the original 5.1.019.usb, and used the wizard to restore settings. No logs, but I guess at that point the logs were being stored in the default location? (Not sure where that is anymore).Under /home root/logs, IIRC, which means they get destroyed in a couch flash.
Mine are under /media/usb/logs/, so I've always got them./
Maybe post #16 will create the necessary logs?Not sure. Could you post the back-up that was taken before the couch flash (i.e. the one which got restored). Then I can check whether the timer was disabled when it was backed up.
It's in #14 - timers_on_backup.xml
I took it from the settings backup tar file to be sure.
The only difference in the timer before and after the restore is disabled="1"
I'll have another go tomorrow.
It's in #14 - timers_on_backup.xml
I took it from the settings backup tar file to be sure.OK.
The odd thing is that if it's complaining about a conflict for that timer, it should also be complaining about a conflict for all of the other Emmerdale ones.
i still find usb or couch flashing i never use settings restore and setup boxes from scratch as things differ maybe slightly.
I've set-up a timer for Look East on BBC One East W and Emmerdale on ITV HD (so they overlap and use different tuners). These were the first two timers in the list.
I then couch-flashed and restored settings and plugins.
No timer ended up disabled.
The timers.xml file was re-written (same data, different ordering) as enigma2 shutdown for the reboot, but that's normal.
root@mbtwin:/etc/enigma2# ls -l timers.xml
-rw-r--r-- 1 root root 17427 Feb 27 21:59 timers.xml
root@mbtwin:/etc/enigma2# ls -l timers.xml
-rw-r--r-- 1 root root 17427 Feb 27 21:59 timers.xml
root@mbtwin:/etc/enigma2# ls -l timers.xml
-rw-r--r-- 1 root root 17427 Feb 27 22:20 timers.xml
Broadcast message from root@mbtwin (console) (Tue Feb 27 22:20:47 2018):
The system is going down for reboot NOW!
I've set-up a timer for Look East on BBC One East W and Emmerdale on ITV HD (so they overlap and use different tuners). These were the first two timers in the list.
I then couch-flashed and restored settings and plugins.
No timer ended up disabled.
The timers.xml file was re-written (same data, different ordering) as enigma2 shutdown for the reboot, but that's normal.Just repeated this using AutoTimers to set the timers with the same result - nothing got disabled.
What plugins do you use?
i still find usb or couch flashing i never use settings restore and setup boxes from scratch as things differ maybe slightly.
I know, you've mentioned this before.
Settings+plugin restores are 100% fine as far as I'm concerned - just one little gremlin that no one else has (yet) come across.:)
Just repeated this using AutoTimers to set the timers with the same result - nothing got disabled.
What plugins do you use?
The only plugin I use is the Sundtek control centre for a dvb-t2 usb tuner.
One thing that does happen after a restore is that tuner E (the usb tuner) gets restored as dvb-c for some reason and needs to be changed.
I'll try a settings restore only, using a couch flash from scratch, and also straight on to a working image.
abu baniaz
28-02-18, 00:23
are the timers for tertestrial services?
are the timers for tertestrial services?
Yes, 4 dvb-t2 plug and play tuners (tuner D disabled) and 1 usb t2 tuner.
One thing that does happen after a restore is that tuner E (the usb tuner) gets restored as dvb-c for some reason and needs to be changed.I have a USB tuner on my et8000 and it often(always?) ends up as DVB-C after a reflash.
But I rarely reflash - an update is so much simpler and quicker.
abu baniaz
28-02-18, 00:47
Yes, 4 dvb-t2 plug and play tuners (tuner D disabled) and 1 usb t2 tuner.
What I found is that if there are no valid services/tuners, timers get disabled. As you have more than one tuner, that throws that theory out of the window.
Yes, 4 dvb-t2 plug and play tuners (tuner D disabled) and 1 usb t2 tuner.I'd just noticed that in the log. Is there any reason why D is disabled? (Not that it should affect things here).
What I found is that if there are no valid services/tuners, timers get disabled. As you have more than one tuner, that throws that theory out of the window.It's also the case that if it were missing tuners then all Emmerdale recordings for 19:00 should get disabled, but only the first one does.
I'd just noticed that in the log. Is there any reason why D is disabled? (Not that it should affect things here).Long story, well documented :), basically when all 4 tuners are needed for recording, tuner C stops working.
It freezes until one of the other tuners is no longer needed.
And although tuner D is disabled, it still needs an aerial feed, otherwise tuner C doesn't work at all.
Independently, the tuners all work fine.
Long story, well documented :).I vaguely recall it.
Anyway, what we know is that the timer is OK in the backup, but disabled before the final reboot. So the restore wizard must be changing it.
But it shouldn't be, as it has no reason at all to ever see it. However, it's possible that it reads it in to cover the fact that enigma2 will write out the timers when it closes down. I'll need to track down the code and follow it through by eye...
I could also try the couch flash on my et8000, which also (currently) has a disabled tuner, and a USB tuner. It also (IIRC) has a "feature" whereby after a couch flash and restore the final reboot doesn't actually happen (it fails to spot that a sub-process has finished - there's s zombie left around...) - I have to login and reboot it. At least if I'm correct about that it would mean I can have a look around...
I'll need to track down the code and follow it through by eye...I can see a possible issue...
The restore is done by vix-core/src/RestoreWizard.py, which contains this code:
def settingRestore_Finished(self, result, retval, extra_args=None):
self.didSettingsRestore = True
eDVBDB.getInstance().reloadServicelist()
eDVBDB.getInstance().reloadBouquets()
self.session.nav.PowerTimer.loadTimer()
self.session.nav.RecordTimer.loadTimer()
configfile.load()
# self.NextStep = 'plugindetection'
self.pleaseWait.close()
self.doRestorePlugins1()So it's loading PowerTimers and RecordingTimers before it loads the config file - i.e. before it knows what types of tuners you have set.
Now, if we knew we were about to reboot (which we will do if any plugins get restored) and we could switch of writing out the config files as enigma2 exits we wouldn't need to read them in her at all. But that's not the case.
So the first thing to do is to see what happens if we move the configfile.load() line to be two lines earlier. Not so easy to test, as this has to be in the image file you flash....but I have an idea....
A backup restore onto a live system with empty timers and autotimers works fine.
If I flash 5.1.019 image release, and don't invoke the wizard, but do a backup restore by hand, I see this image.
Trying out something else now.
If I flash 5.1.019 image release, ignore wizard, switch on debug logs, reboot, restore settings, I get the same error as the previous post:).
Logs not making sense at the moment, I'll try again.
A backup restore onto a live system with empty timers and autotimers works fine.
If I flash 5.1.019 image release, and don't invoke the wizard, but do a backup restore by hand, I see this image.
Trying out something else now.OK. That will simplify things (I think....I reckon I can get my idea to work, but it may take same time...).
I presume that between the "don't invoke the wizard" and "do a backup restore by hand" you can access the system so could copy in an updated RestoreWizard.py and restart the GUI?
I'm not seeing that error message anymore, but the timer still get disabled.
Despite switching on debug logs and setting the location and rebooting, the log for the session which does a backup restore always goes missing.
OK. That will simplify things (I think....I reckon I can get my idea to work, but it may take same time...).
I presume that between the "don't invoke the wizard" and "do a backup restore by hand" you can access the system so could copy in an updated RestoreWizard.py and restart the GUI?
Should be ok - maybe I should try a GUI restart first (before your changes) to see if it still fails.
If I flash 5.1.019 image release, ignore wizard, switch on debug logs, reboot, restore settings, I get the same error as the previous post:).
Logs not making sense at the moment, I'll try again.Could you copy the file from this zip:
56239
into /usr/lib/enigma2/python/Plugins/SystemPlugins/ViX/ and restart the GUI before restoring settings?
Could you copy the file from this zip:
56239
into /usr/lib/enigma2/python/Plugins/SystemPlugins/ViX/ and restart the GUI before restoring settings?
Ok, done that, but timer still disabled.
I renamed RestoreWizard.pyo to RestoreWizard.pyo.ok before copying RestoreWizard.py - was that wrong?
No pyo file was created after GUI restart. (init 4, copy, init 3)
root@et10000:/usr/lib/enigma2/python/Plugins/SystemPlugins/ViX# ls -l R*
-rw-r--r-- 1 root root 16676 Feb 28 12:34 RestoreWizard.py
-rw-r--r-- 1 root root 18603 Feb 24 13:40 RestoreWizard.pyo.ok
root@et10000:/usr/lib/enigma2/python/Plugins/SystemPlugins/ViX#
Ok, done that, but timer still disabled.Hmmmm....thanks. More thinking needed....
I renamed RestoreWizard.pyo to RestoreWizard.pyo.ok before copying RestoreWizard.py - was that wrong?No. In fact it was a Good Idea, as it means you have something to go back to if my change had screwed things up.
If a new pyo file wasn't created, doesn't it also mean that it doesn't get used after the GUI restart ?
If a new pyo file wasn't created, doesn't it also mean that it doesn't get used after the GUI restart ?No. It should have been created when it was needed, which is not until you start doing the restore rather then just when you restart the GUI.
No. It should have been created when it was needed, which is not until you start doing the restore rather then just when you restart the GUI.
But it wasn't there after the restore. Post #43
But it wasn't there after the restore. Post #43Post #43 refers to after the restart of the GUI. What matters is whether it was there after the restore.
Post #43 refers to after the restart of the GUI. What matters is whether it was there after the restore.Ok, I can't remember now when I checked.
I know I said after the restart of the GUI, and I guess it must have been created during the restore, but I can check again tomorrow if needs be.
If I flash 5.1.019 image release, and don't invoke the wizard, but do a backup restore by hand, I see this image.Whoopy do!
Just remembered that this is a Backup restore, not a RestoreWizard one. Different code. Same (suspect) code ordering bug....
Whoopy do!
Just remembered that this is a Backup restore, not a RestoreWizard one. Different code. Same (suspect) code ordering bug....So, here's another file to put into /usr/lib/enigma2/python/Plugins/SystemPlugins/ViX/ and restart the GUI before restoring settings.
56241
One other thing you could do after not invoking the Restore Wizard but before the manual restore is to look at (but not change) the tuner configuration. How many are active, and how many are DVB-T(2)?
One other thing you could do after not invoking the Restore Wizard but before the manual restore is to look at (but not change) the tuner configuration. How many are active, and how many are DVB-T(2)?All 4 tuners are enabled as dvb-c, (but they will be restored as dvb-t2).
Got the failed condition as in post #37
pyo file created ok.
All 4 tuners are enabled as dvb-c, (but they will be restored as dvb-t2).But they will still be DVB-C when the Timers are loaded.....which is a bug.
Got the failed condition as in post #37
pyo file created ok.So even with the modified BackupManager.py it still fails? Perhaps some other initialization is missing....
So even with the modified BackupManager.py it still fails? Perhaps some other initialization is missing....
I'm afraid so, it's a wonder only 1 timer is disabled.
OK. So it appears we need to get the tuners re-evaluated after config load (I can't think of any other hardware info that would change...).
The only way this can be done (that I can see) is to re-initialize the nimmanger. Possibly a bit of a hack, but I dropped the code into setting up a Timer Edit list and it seems to run (i.e. enigma2 continues to run...).
So, here are copies of BackupManager.py and RestoreWizard.py with the re-init code added after loading the actual config.
56242
Could you drop these into place and see how things go?
.... Got the failed condition again as in post #37
BackupManager.pyo created ok.
Managed to get debug log of restore.
... annoyingly, a large number of completed timers are in the restored timers.xml file.
I don't know why, as I deleted them all, and double checked the timers list before taking a backup.
Is the completed timers delete a background process which may not have started?
.... Got the failed condition again as in post #37
BackupManager.pyo created ok.Hmmmm......:confused:
Managed to get debug log of restore.Well, at least that's good news. If you look at ~533.192 you'll see what is probably the original issue:
< 533.192> [InitNimManager] tunerTypeChanged error: global name 'self' is not definedOh, there's also this:
< 533.183> [eDVBFrontend] opening frontend 0
< 533.184> [eDVBFrontend] setDeliverySystem setting type to 1 from 0
< 533.184> [eDVBFrontend] setDeliverySystem succefully changed delivery system to DVB-CWhich probably means you're left with only your USB tuner as DVB-T2 at that point.
... annoyingly, a large number of completed timers are in the restored timers.xml file.
I don't know why, as I deleted them all, and double checked the timers list before taking a backup.
Is the completed timers delete a background process which may not have started?Deleting a timer puts it into the deleted state. It gets removed from the file after a configurable time (allowing you to see timers which have run recently - since a timer gets deleted on completion).
It's also configurable whether they are visible in the Timer List.
OK. There's another potential issue here.
Your USB tuner isn't actually visible until after the plugins are restored, so if it were your only DVB-T2 tuner you wouldn't have one at all when the timers were loaded and hence any timers needing it would be disabled.
So I need to scrap that idea and instead add an option to loading timers which tells it to skip the TimerSanityCheck completely.
This will be an issue if someone restores a backup to a system where the tuner config differs from when the backup was made - but I doubt that's a common occurrence, and the next timer change will run the test anyway.
Hmmmm......:confused:
Which probably means you're left with only your USB tuner as DVB-T2 at that point.
There's no sign of the usb tuner at all until the restore reboot picks up the drivers.
In the log there's... 600.317> [TimerSanityCheck] possible bug: unknown conflict!
So I need to scrap that idea and instead add an option to loading timers which tells it to skip the TimerSanityCheck completely.I seem to have done that, but its causing an odd message to get reported, so I'm trying to figure out why that happens.
As for the:
Well, at least that's good news. If you look at ~533.192 you'll see what is probably the original issue:
< 533.192> [InitNimManager] tunerTypeChanged error: global name 'self' is not defined
well that always happens, even with the correct tuner config in place....
I seem to have done that, but its causing an odd message to get reported, so I'm trying to figure out why that happens.Well, I've changed the code a bit and it no longer happens.
What is done is that the timer loading in BackupManager and RestoreWizard now sets a flag to justLoad timers. If this is set the code temporarily changes the conflict_detection flag on each timer to False as it runs it through the conflict detection (and restores it to the original value immediately afterwards). This means that any other code at timer-load still gets run...
This works for me.
Since I was testing this on a fresh flash image with no backup restore done I thought that I might as well see what happened if I restored a backup without these fixes. And yes, I see just what you are seeing - the second timer gets disabled. I can only assume that it's because there appear to be no suitable tuners at all (all of the visible ones have been set to DVB-C). It disables the second one (as the first one "can't" have a clash...) and then it's totally confused.
I suspect many (most) people have DVB-S(2) or DVB-C tuners, which default to the required mode.
Here are the files.
56244
BackupManager.py and RestoreWizard.py => /usr/lib/enigma2/python/Plugins/SystemPlugins/ViX/
RecordTimer.py => /usr/lib/enigma2/python/
.... I was wondering if T2 only tuners was the issue, but was surprised no else had noticed timers being disabled - not obvious unless you check them carefully after a restore.
I'll give it a try now - many thanks.
A package arrive today, so I no longer have any disabled tuners....:)
Checked and looks fine now. Many thanks again.
Debug log of restore if it's of any use.....
A package arrive today, so I no longer have any disabled tuners....:)
I'm just in time, by the sound of it.
Surely not satellite? :)
Surely not satellite? :)No. A replacement for one that could no longer properly receive the two weaker DVB-T2 muxes (COM7 and COM8). Given that here seems to be no way to say that a tuner can only receive a sub-set of the frequencies (it was fine on all of the stronger signals) I had to disable it.
Checked and looks fine now. Many thanks again.Great. I'll submit a PR to get it into the standard image. Oddly it needs things to go into two different repositories.
I also have a fix for the (unrelated):
< 533.192> [InitNimManager] tunerTypeChanged error: global name 'self' is not defined although this will result in a different error instead
< 2208.235> [InitNimManager] 1: tunerTypeChanged to 'DVB-T2' failed (BUSY)but that is just a result of the preceding message:
< 2208.235> [eDVBResourceManager] another linked frontend is in use.. so allocateFrontendByIndex not possible!I have no idea what it is trying to do here, nor how (as in "what way") my USB tuner is linked to the three internal tuners. It does make more sense if you ever change a tuner setting, though.
On thing I've just noticed while experimenting is that if I set tuner A to be DVB-C then it tries to use tunerB, but doesn't get anything. If I change any other tuner to DVB-C then the remaining ones continue to work, but I can't use the one I've changed.
It's almost as if they all actually run in the mode of TunerA, but I can only use those flagged as DVB-T2. Odd...
Great. I'll submit a PR to get it into the standard image. Oddly it needs things to go into two different repositories.
https://github.com/OpenViX/enigma2/pull/222
https://github.com/OpenViX/vix-core/pull/16
I also have a fix for the (unrelated):...although this will result in a different error instead...but that is just a result of the preceding message:
https://github.com/OpenViX/enigma2/pull/221
I also have a fix for the (unrelated):...although this will result in a different error instead...but that is just a result of the preceding message:
https://github.com/OpenViX/enigma2/pull/221
There has been a reference to a commit dated Sep 22 2016 ....
https://github.com/OpenPLi/enigma2/commit/c9fbd6ec884ee8c9225b314dad87e16c436c06a3
I'm attaching a debug log which pre-dates this commit in case it's of any use.
There has been a reference to a commit dated Sep 22 2016 ....
I'm attaching a debug log which pre-dates this commit in case it's of any use.Thanks. That one's not too much of an issue since, despite the reported error/warning, everything still appears to work as expected.
I hadn't thought of looking back at old logs - I must have some somewhere.
.... I'm still clutching at straws - hoping that my problem with the 4th tuner might be caused by some subtle problem like this one.:)
Maybe an image mod which defaults to T2 rather than C might prove something?
.... I'm still clutching at straws - hoping that my problem with the 4th tuner might be caused by some subtle problem like this one.:)All that change did is to produce the error message. Before that it just trapped the error and silently returned.
All that change did is to produce the error message. Before that it just trapped the error and silently returned.Yes, but is it likely that there will be a fix for the "error" when it is detected?
@CCS can I have a step by step list to create the error. Exact steps please.
Also please try the attached file and see if the same error occurs.
@CCS can I have a step by step list to create the error. Exact steps please.
Also please try the attached file and see if the same error occurs.
Hi, is this the "InitNimManager] tunerTypeChanged error: global name 'self' is not defined" problem you're referring to, or the issue with 4 T2 tuners being used at the same time?
A simple reboot from deep standby causes InitNimManager] tunerTypeChanged error: global name 'self' is not defined - first debug log.
2nd debug log includes your NimManager.py
A simple reboot from deep standby causes InitNimManager] tunerTypeChanged error: global name 'self' is not defined - first debug log.But only if you have more than one dual DVB-C/DVB-T2 tuner and want to run them as DVB-T2.
I reproduced this on my Xtrend et8000. It had actually been reporting it for ages.
It is an error, but it doesn't actually stop anything being done (probably) as the previous code also produced an error (a different one) but that was inside a try/except clause and just returned.
Maybe I should also have pointed out that in the 2 debug logs in #79, tuner D is configured as disabled.
Maybe I should also have pointed out that in the 2 debug logs in #79, tuner D is configured as disabled.Doesn't matter. If it is set to DVB-T2 then, even if it is disabled, the code to set it to DVB-T2 will still run (and do nothing beyond produce an error message, as all of the tuners seem to be linked in some way and only the first one can pick up a raw channel).
No step by step yet then? One for each problem.
No step by step yet then? One for each problem.Isn't post #79 enough detail?
And can I ask again, is the issue using 4 t2 tuners simultaneously on an et10K the other one?
No step by step yet then? One for each problem.
Install DVB-C/DVB-T2 tuners on your system (at least two of them)
Configure them as DVB-T2
Boot the system
Look at the log
Thanks Birdman.
@CCS, so your second log in post #79 shows the NimManager.py I supplied sets the tuners correctly, right?
:confused:
Thanks Birdman.
@CCS, so your second log in post #79 shows the NimManager.py I supplied sets the tuners correctly, right?
The 'self' is not defined error has gone, and there are no other obvious NimManager errors, but 4 simultaneous T2 tuners still don't work.
I only mentioned that problem earlier because I felt that there was a slight chance that NinManager wasn't setting them all up correctly, and the 'self' error may have been part of the reason.
I can try others things out, but at the moment my ET10K is struggling, I suspect RAM problems, but only time will tell.
It hangs sometimes while booting, I can init 4, init 3 and then it always continues to work fine.:confused:
Nothing to do with your NimManager.py - it isn't installed.
Could be a hardware thing. There might be a limitation on the max number of DVB-T2 tuners possible, or their order.
Could be a hardware thing. There might be a limitation on the max number of DVB-T2 tuners possible, or their order.
Yes - the manual mentions DVB-C to be avoided in slot D, that's why I thought there was a slight chance that defaulting to C could be the reason.
I'll post the Nim slots allocated before and after your patch to see what's changed.
Before patch (ie current 5.1.019)....
cat /proc/bus/nim_sockets
NIM Socket 0:
Type: DVB-T2
Name: Si2169
Has_Outputs: yes
Frontend_Device: 0
I2C_Device: 2
NIM Socket 1:
Type: DVB-T2
Name: Si2169
Has_Outputs: yes
Frontend_Device: 1
I2C_Device: 3
NIM Socket 2:
Type: DVB-T2
Name: Si2169
Has_Outputs: yes
Frontend_Device: 2
I2C_Device: 4
NIM Socket 3:
Type: DVB-T2
Name: Si2169
Has_Outputs: yes
Frontend_Device: 3
I2C_Device: 4
NIM Socket 4:
Type: DVB-C
Name: Sundtek DVB-C (III) (1/0) (USB)
Has_Outputs: no
Frontend_Device: 4
I2C_Device: -1
root@et10000:~#NIM sockets 3 and 4 both have the same I2C_Device: 4 for some reason.
Debug log...
< 33.558> [NimManager][enumerateNIMs] slot: 0 - entry: {'name': 'Si2169', 'frontend_device': 0, 'has_outputs': True, 'isempty': False, 'i2c': 2, 'type': 'DVB-T2'}
< 33.560> [NimManager][enumerateNIMs] slot: 1 - entry: {'name': 'Si2169', 'frontend_device': 1, 'has_outputs': True, 'isempty': False, 'i2c': 3, 'type': 'DVB-T2'}
< 33.562> [NimManager][enumerateNIMs] slot: 2 - entry: {'name': 'Si2169', 'frontend_device': 2, 'has_outputs': True, 'isempty': False, 'i2c': 4, 'type': 'DVB-T2'}
< 33.563> [NimManager][enumerateNIMs] slot: 3 - entry: {'name': 'Si2169', 'frontend_device': 3, 'has_outputs': True, 'isempty': False, 'i2c': 4, 'type': 'DVB-T2'}
@CCS can I have a step by step list to create the error. Exact steps please.
Also please try the attached file and see if the same error occurs.Isn't that just reverting to the early code (once the DOS line ending are stripped off)?
So yes, the "self" error message will go away, as "self" is no longer mentioned.
But it won't change how any tuner is setup.
More possible changes........
https://github.com/OpenPLi/enigma2/pull/1335
Tried it (busy failures)....................
More possible changes........
https://github.com/OpenPLi/enigma2/pull/1335Not really. that just adds back the rawchannel code which Heuvos removed in the one he got you to test earlier. (Plus some other bits further on, but you'll never get there as you fail and return at the raw_channel part).
Although, interestingly, it does add the code back by using NavigationInstance.instance rather than self, which is precisely the change I made to this bit of code.
And that's the code that was reverted ~1 day ago as a result of me pointing out that the code was using an undefined self.
So we're going round in circles here.
I've pointed out a bug, and given a fix.
Heuvos queries this with OpenPli, which is where the ViX code came from.
OpenPLi revet the original fix then apply my new one.
We're still discussing my fix and referring to varying PLi versions of the code.
PS: None of this is anything to do with the original issue of a recording becoming marked as disabled. There are two separate PRs in place to fix that - also not yet applied.
Gordon, no one is questioning your fix. The purpose of the PLi thread is that we don't go off in different directions due to this bug. i.e. there is more than this one bug in this def.
Gordon, no one is questioning your fix. The purpose of the PLi thread is that we don't go off in different directions due to this bug. i.e. there is more than this one bug in this def.The fix for a non-existent self is now in PLi anyway.
The two fixes (in different repositories) for loading timers on a restore are needed, unless someone wants to rewrite the BackupManager and RestoreWizard to completely re-order how things are done. And you are questioning whether that is needed.
I also have a fix for the (unrelated):...although this will result in a different error instead...but that is just a result of the preceding message:
https://github.com/OpenViX/enigma2/pull/221 That has ended up in Vix indirectly. It was incorporated into the PLi code, then Vix picked up their (larger) change.
Powered by vBulletin® Version 4.2.5 Copyright © 2024 vBulletin Solutions Inc. All rights reserved.