94 replies to this topic

[Dimitrij]

The second attempt

 

Add option enable/disable conflict detection for each timer

[littlesat]

Nice!

[Rob van der Does]

The second attempt

 

Add option enable/disable conflict detection for each timer

Thanks Dimitrij; as far as I can see a fine solution.

[Erik Slagter]

Well, I must say I really don't understand all that fuss about this option...
There's a zylion of (sometimes strange) e2 settings I never touched, because I simply didn't need to.
Default value of it is 'safe' for all users, so I would just add a standard: 'don't change this unless you know exactly what you're doing' to the description, and call it a day...

(and btw. correct me if I'm wrong, but this option appears only in 'expert' settings mode, so the name obliges... )

Very good point.
 
We should have an overhaul over what options should be in "expert" mode. Now some very basic features cannot be controlled without going into expert mode. That can't be right. The expert mode is indeed for features like this.
 
I can add a text like mentioned to the help, don't touch this! "No serviceable parts inside, do not open"
 
If people go mess with stuff they don't understand, they may expect it to break.
 
So... Like I said before, dimitrij, I will not remove this option, and I will not allow a patch that removes it. I will allow a patch that changes the sense of the option from "disable" into "enable", because it's easier to understand.
 
Also dimitrij, your patch is not rejected, I just want to know exactly what Littlesat's objections are. I think you and he are not on the same track. We have to wait on Littlesat's comments. Just be patient.***EDIT*** irrelevant.

Edited by Erik Slagter, 7 November 2015 - 08:44.

[Erik Slagter]

 

 

 

That's where your reasoning is wrong. Contrary to what you say, the conflict detection doesn't know of fallback tuners at all. So it will never consider using it. So if all "local" tuners are "full", it will simply say "conflict" and it will disable the timer+recording, rendering your fallback tuner useless for recordings. Thát's the core of the problem.

ok, didn't know that, so makes more sense now. In this case you would indeed have 3 options :

- conflict detection on and forget about "free" remote tuners

- conflict detection off and hope a tuner is free at the moment of recording

- conflict detection on/off on timer level, as dimitrij wants it.

 

I'm with dimitrij with this one, this way you can keep the conflict detection for important recordings to make sure that they will be executed, and ignore conflict detection for less important recordings.

Where option #1 is the default and previous behaviour, option #2 is what you get when you disable conflict detection and option #3 is what we get with dimitrij's patch (I hope).

[Erik Slagter]

I would not recommend to put any limitation on this option... Any limitation is a limitation and makes the code more complicated. I would recommend to add this setting for any timer....

Yes, supported. Keep it generic.

[Erik Slagter]

The second attempt
 
Add option enable/disable conflict detection for each timer

Thx. Now we have to wait for Littlesat to review, because I hardly can make head or tail of enigma python code.

[littlesat]

It was already reviewed ...

Now I can revert my general setting... And someone else or I can add an option to quickly set this timer entry option via the timer conflict screen...

And regarding the expert, simole setting feature.... This whas a good intended idea from dmm... But actually never worked, because any user might be on expert mode....

Edited by littlesat, 7 November 2015 - 09:10.

[Erik Slagter]

After this patch and after revering 5983e1caa91a01d781f6c91cab49ab289a05b737, can I still globally disable the conflict detection? That is a requirement.

[littlesat]

No... Then you still get the warning... But can ignote it by pressing a button and the selected timer will have the ignore programmed....

But now dimitrij does not mixed it up in his last commit this can be rediscussed....

Edited by littlesat, 7 November 2015 - 10:18.

[Rob van der Does]

Good points guys, good discussion. And more important: good result ( I think).

 

IMHO the items that should be in 'basic' and in 'expert' mode should indeed be revised'. The fact that any user can set it to 'expert' doesn't diminish the value of such a setting. Default should be 'basic'. The value of such a setting is in thoroughly choosing what is in which mode.

[littlesat]

I think we better can revert the complete levels of expert etc.... This is bad design from the beginning.... And it leads to endless discussions about ehat should be simple and what should be expert... i would simply show all options available so you also are aware of everything your box is capable for....
And when you think there are too many options then I think you better can add an option to hide options......... Based on the way hotkey is designed.... But nobody did start implementing this...

[WanWizard]

I don't really agree.

 

There are a lot of people that are not "qualified" to touch most of the settings, and get into a state of panic when they see the huge amount of sometimes very detailed settings. So I think you need a separation between settings that are "safe" for beginners, and settings that can "break things".

 

I do agree that the current implementation, in which settings are hidden depending on the selected level is wrong. I personally quite like the system where you are shown all the basic settings, in a list, and then have a last entry in the list called "Advanced", which opens a new list with the expert settings. A Pana TV does that for example. So you don't have to toggle a "level", and you have clear separation between "safe" and "dangerous" settings...

[Rob van der Does]

I personally quite like the system where you are shown all the basic settings, in a list, and then have a last entry in the list called "Advanced", which opens a new list with the expert settings. A Pana TV does that for example. So you don't have to toggle a "level", and you have clear separation between "safe" and "dangerous" settings...

That is indeed a fine option, used in many devices. And sometimes 'advanced' even holds another 'advanced'.

[Erik Slagter]

No... Then you still get the warning... But can ignote it by pressing a button and the selected timer will have the ignore programmed....

But now dimitrij does not mixed it up in his last commit this can be rediscussed....

And now? How about my autotimer entries that need to be recorded from the fallback tuner? I don't care about warnings, it should be automatic!

Edited by Erik Slagter, 7 November 2015 - 13:05.

[Dimitrij]

 

No... Then you still get the warning... But can ignote it by pressing a button and the selected timer will have the ignore programmed....

But now dimitrij does not mixed it up in his last commit this can be rediscussed....

And now? How about my autotimer entries that need to be recorded from the fallback tuner? I don't care about warnings, it should be automatic!

 

Soon you will be able to add any autotimer as conflict detection is disable.

Edited by Dimitrij, 7 November 2015 - 14:59.

[Erik Slagter]

I have about 50 autotimers, now I should change them all???

[Dimitrij]

I have about 50 autotimers, now I should change them all???

yes

[Erik Slagter]

Hmm, I'll call on vi then (text editor).

 

Nobody else that wants to retain a global setting?

[jeanclaude]

Hmm, I'll call on vi then (text editor).

 

Nobody else that wants to retain a global setting?

actually, as I updated yesterday I got to "play around" a bit with the new parameter "disable timer conflict detection" in a timer setup.

it doesn't really makes sense (sorry, Dimitrij)

 

if you don't use a remote tuner then there is no reason whatsoever to disable the timer conflict detection - indeed, the number of tuners is well known so it stands to reason that you should want to know which timers will be recorded, and which will not. With this information you can use the timer conflict detection to change the timer settings to make sure that whatever's important for you gets recorded, by disabling less important timers and freeing a tuner for a more important timer. This works well, so why change this ?

 

now, if you do use a remote tuner, like Erik, then the timer conflict detection will disable timers even if a remote tuner is available at the time of recording. For these timers you can set "timer conflict detection" to OFF so that the timer stays active and will be recorded, if a remote tuner is available. If not, then bad luck. But this in turn will flood the timer list with a active timers, without conflict detection, interfering with those timers where "conflict detection" is set to ON. In this case, timers without conflict detection will take precedence over timers which have conflict detection activated. You might say that you want this for recordings that you really want to happen, as they take precedence over other timers, but hey, the mere fact that you're de-activation the timer conflict detection just means that you're not sure that this timer will be recorded at all. so what's the point of specifying timer conflict detection on timer level ?

 

I see more use for the "global" switch which is set to ON if no remote tuners are used, and which the user can set to OFF if he/she is using remote tuners.

although this isn't desirable also as you won't know any more what will be recorded and what will not, is this really what you want ?

 

the ideal solution would be to have 3 types of timers : active (with conflict detection), disabled and remote (without conflict detection)

in this case the autotimer plugin will create active and disabled timers in the timer list, and the user can then check the timer list, and change the timers to his/her priority. Active timers will always be recorded by a local tuner; disabled timers will not record; disabled timers set to "remote" will only record if a remote tuner is available at the time of recording (never use a local tuner as this might be needed for an active timer which is starting at a later time).

Edited by jeanclaude, 10 November 2015 - 11:38.