94 replies to this topic

[Rob van der Does]

I'm a bit confused by the recently introduced option to disable timer conflict detection.

The hint text 'When you use the remote fallback tuner to do recording, the timer conflict detection can't handle remote fallback tuners. This option allows you to turn off the timer conflict detection' doesn't help me either. Timer conflict management has never been able to handle a tuner; it simply handles timer conflicts (and does a good job in that respect).

 

I assume that using a fallback tuner for recording actually means that the timer is being added to the client box, and that the client box does the recording (first trying to use a local tuner, and if not possible (due to a timer conflict or simply no local tuner at all) the remote tuner.

The actual 'disable conflict management' setting is a global one. So once disabled, you'll never be prompted for any timer conflict.

 

I suggest to make this a setting in the conflict manager. That means that the users remains being warned for any (potential) conflict, given the option to handle it, and to decide to disable the conflict manager for this timer in order to leave things to the remote tuner (never being sure if that recording will actually be made, as there is no indication whatsoever about remote tuners availability) if he wants to.

[littlesat]

I kept it simple and add an option to simply disable it completely... So for recordings with a fall back tuner makes sense...  So in fact this is a quick & dirty fix... (not really OpenPLi style but it helps developing Eric's fallback of recordings patch). In addition it gives me more time to think about a better solution.

 

For ignore it timer by timer you can press exit when you get the warning... Then you ignore the conflict, but a waring re-occured each time you make changes to the timers (add timers, change timers) -and- also when you (re)start enigma2.

 

So I'm considering to give a popup when you try to exit the timer conflict and gives you a choise to add  an additional timer flag so you can ignore the test for  specific timers.

 

I'm still thinking about the best option how to realize this... e.g. will also be an additional setting in the timer so afterwards you can also program it OFF or even in forehand you can program it ON.

 

Once this is made I can revert the imple patch -so- I do not prefer to made a lot of additional changes to it (so I get a clean revert).

[Rob van der Does]

For ignore it timer by timer you can press exit when you get the warning... Then you ignore the conflict, but a waring re-occured each time you make changes to the timers (add timers, change timers) -and- also when you (re)start enigma2.

Nope: if you use 'exit' on a conflict, the timer is simply not being added. So that is no solution.

 

IMHO disabling the conflict manager as a global setting only makes sense if no local tuner is present at all.

[Dimitrij]

For ignore it timer by timer you can press exit when you get the warning...

It must be so:

if you use 'exit' on a conflict, the timer is simply not being added.

If it is not, it is a bug enigma2.
But I did recently to fix it .

[littlesat]

if you use 'exit' on a conflict, the timer is simply not being added.

-> 

That is exactly why I made and we need this work-a-round for the temp being...

 

AGAIN

 

A real solution is in progress... THEN this will reverted...

 

IMHO disabling the conflict manager as a global setting only makes sense if no local tuner is present at all.

->

I agree.. But different... disabling the conflict timer stuff is also not required when you have fallback tuners... or it needs more stuff to be added...

...but I do not want to make exclusions here... e.g. when I need to revert this I need to revert two commits. So I leave it as it is and nod not recommend to add any complicated stuff (exclusions only allow when there is a fallback tuner).

 

And I think as it is now it clarifies clearly what it is doing....!!!! And the default is what is was before...!!!!

Edited by littlesat, 1 November 2015 - 12:21.

[Dimitrij]

My opinion...

Add verification of conflict for each timer yes/no

Create new timer(.....fallback_tuner=False)

if "Enable fallback remote receiver" is Yes-->this option visible "Timer conflict detection" yes/no -->default No

if global "Enable timers conflict detection" is Yes -->this option visible "Timer conflict detection" yes/no -->default Yes

 

And

global "Enable timers conflict detection" visible only  "Enable fallback remote receiver" is Yes and "Fallback remote receiver URL" not empty

[littlesat]

I prefer to make it without any (active required) configs...

 

and e,g, this global "Enable timers conflict detection" visible only  "Enable fallback remote receiver" is Yes and "Fallback remote receiver URL" not empty"

is a limitation.... I also do not prefer that... e.g. there may be someone who wants to disable a detection in case we do not have an exeption....

Edited by littlesat, 1 November 2015 - 13:17.

[Erik Slagter]

Anything suits me, as long as I don't get a regression on my situation. I have a receiver with "some" tuners. It's able to record most timers, but sometimes it lacks a tuner to record the 3rd, 4th or even 5th program broadcast simultanuously, programmed by the AUTOTIMER. That is where the remote FALLBACK tuner comes in (pay attention Rob ) and just gets the program from a remote tuner. Works like a charm (as long as you have enough demuxers available).

 

If you have conflict detection enabled, this will never work, because the conflict detection does not know about the fallback tuner. It will simply state: all tuners in use, program cannot be recorded. Which is incorrect and the program is not recorded.

 

So the text in the comment is really correct. And also if you use fallback tuner, in the way that I use it, there is no other solution but completely disable the conflict detection. If you don't use the fallback tuner for recording, you may very well leave the confliction detection enabled, it's all up to you.

 

I don't see the problem.

[Dimitrij]

 

I don't see the problem.

No problem.

I just offered to do further fine adjustments.
When the user really understands what he is doing.

[Rob van der Does]

@Erik: AT will add a disabled timer if it finds a conflict when adding one. If the conflict manager could be disabled on a case only (as I suggested, so not as a global setting), it would be very easy to go through the disabed timers and enable them. So the conflict manager could do it's work or could be disabled when really wanted for this case.

 

I keep hammering on this point, as when disabling the conflict manager one never knows if this recording will actually be made (because of the fact that noone knows if the tuner will be available). So the user would have the choice to either handle the conflict (in order to be sure the recording will be made) or to disable it (for allowing the uncertainty of using the FB tuner for this specific recording).

[Erik Slagter]

Yes I know your considerations. But for what you want, the autotimer needs to be adjusted, not (only) the global conflict detection. You might want to ask Dimitrij to do it... Please note this will have consequences. If you leave global timer conflict detection on and you restart enigma, enigma will still automatically disable one of the conflicting timers, without asking.

[Rob van der Does]

What needs to be adjusted in AT for this?

[Dimitrij]

My opinion...

Add verification of conflict for each timer yes/no

Create new timer(.....fallback_tuner=False)

if "Enable fallback remote receiver" is Yes-->this option visible "Timer conflict detection" yes/no -->default No

if global "Enable timers conflict detection" is Yes -->this option visible "Timer conflict detection" yes/no -->default Yes

 

And

global "Enable timers conflict detection" visible only  "Enable fallback remote receiver" is Yes and "Fallback remote receiver URL" not empty

+

Create new autotimer(.....fallback_tuner=yes/no)

Edited by Dimitrij, 2 November 2015 - 12:12.

[Erik Slagter]

Hmmm, I don't want to connect fallback-tuner and disable conflict detection. There may be sitations where you'd want to configure them independently.

 

I want to keep the global option "disable timer conflict detection".

 

Then for autotimer, there could be an option, for each entry, to disable the conflict detection. I think that's all that's needed here.

 

If people want to disable the conflict timer detection only for certain autotimers, don't set "disable timer conflict detection" in enigma and set it on certain timers. For people like I that don't want to have conflict detection at all, they can set the "disable timer conflict detection" in enigma.

[Rob van der Does]

I don't agree with Erik. That proposal only deals with AT, not with manually added timers. For those disabling conflict manager should be on a case to case basis, as I tried to explain before.

[Erik Slagter]

I don't get it (as you already noticed). As I already said before, I don't care if we get all sorts of autotimer-specific options for suppressing or enabling the conflict detection. I don't care. I won't use it. If Dimitrij wants to include it, please go ahead. But the important thing: the global setting "disable conflict detection" stays like it is, no discussion about that. If you don't want to use it, just don't enable it.

[Rob van der Does]

I don't get it: not long ago Littlesat promised to look into more smart options, and now it is 'no discussion'.......

Very inflexible, and for me unusable option, so my hope is now indeed focussed on Dimitrij.

[Erik Slagter]

You still don't get it. I never said there is no room for "smart options". I just said that the global (override) option won't go. That doesn't exclude other settings.

[littlesat]

I think this is getting a nightmare here because the original implementation was already a nightmare...
And now I added a feature that allows to disable this nightmare.... So another not ideal situation I would recommend for now at least as it is....
Note that adding limitations and conditions like do not show a specific option and disable it when another option is not enabled makes this stuff more complicated as it should be..... So please keep it simple and not consider to add a new nightmare to the other nightmare...

And when I undersand it correctly with autotimer disablling the conflict detect should work when you have a fallback tuner that also do not work always.... So with the current approach you should be fine....

The only argue it has is that it does not make sense not to enable the conflict detection in case you do not have a fallback timer...But also this is not true.... You will also consider to disable the conflict timer in case e.g. an alternative is a webstream....

Edited by littlesat, 2 November 2015 - 22:37.

[Rob van der Does]

I have no doubt that implementing the Conflict Manager was challenging. And changing the actual implementation will be quite a job again.

 

Regarding your remark about AT: AT does indeed add disabled timers when encountering a conflict. But in order to enable them, one has to disable the conflict manager as a global setting. So that brings in the disadvantages I mentioned above.

 

Just for my understanding: if one wouldn't use the fall back tuner, but alternative services (made by the remote stream converter or a web-stream): then the actual implementation of the conflict manager would work fine?