Xtrend Et10k-Timer Recording Didn’t Records Properly

[birdman]

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.

[ccs]

Hmmmm......
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!

[birdman]

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....

[birdman]

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.

TimerJustLoad.zip

BackupManager.py and RestoreWizard.py => /usr/lib/enigma2/python/Plugins/SystemPlugins/ViX/
RecordTimer.py => /usr/lib/enigma2/python/

[ccs]

.... 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.

[birdman]

A package arrive today, so I no longer have any disabled tuners....

[ccs]

Checked and looks fine now. Many thanks again.

Debug log of restore if it's of any use.....

[ccs]

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?

[birdman]

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.

[birdman]

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...

[birdman]

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

[ccs]

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.

[birdman]

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.

[ccs]

.... 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?

[birdman]

.... 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.