94 replies to this topic

[jeanclaude]

can I make a suggestion : is it not possible for the conflict manager to treat this remote tuner as an extra internal tuner, so that the conflict manager will only report a conflict if the remote tuner is also reserved for a recording.

on a receiver with 3 tuners then the remote tuner will be treated as a 4th tuner and a conflict will only arise if you're planning 5 recordings on 5 different transponders.

whether or not the remote tuner will be actually free at the time of the recording cannot be verified in advance, so it's possible that the recording which is assigned to the remote tuner will fail, without notification. But this is also what you'll get when de-activating the timer conflict manager altogether (and much worse).

AT can set disabled timers if all internal + remote tuner are occupied. It's up to the user to change the timers by activating the timers you need and by using the conflict manager to resolve the timer conflict by de-activating the timers you don't want/need.

[Dimitrij]

jeanclaude

Let's first solve your problem.

[Rob van der Does]

@ jeanclaude: Interesting though. And should be relatively easy to implement.

However: fallback tuner can in reality be 4 (or even more) tuners. So conflict manager might see a conflict (far) too soon.

[jeanclaude]

new input field : number of fallback tuners ?

that way the conflict manager can take this into account when determining possible conflicts.

as a bonus, when you find that too many timer events are not recording (due to the fact that the remote tuners are occupied) you could decrease this number so that you are warned of possible timer conflicts when too many remote tuners are already assigned.

[Rob van der Does]

True.

[littlesat]

That will not work at all.... Note that at the time of the recording the fallback tuner might used for a different porpuse...
The only thing you can do is leave the conflict detection on and plan the conflicting timer on the fallback tuner box itself.... (As e.g. an option on the timer conflict popup...)

Edited by littlesat, 3 November 2015 - 15:07.

[Erik Slagter]

In short, one way or another, the timer conflict detection can never know when the remote tuner is available. It can't even know WHAT SERVICES (or positions or even DVB-type) can be served at one given moment. Conflict detection can never work with a fallback tuner. Forget about it. And that's why you can disable it now.

 

@Rob, yes, the base for the detection is complex, but that's not the problem I'm talking about. I am talking about the current implementation, which makes it very hard to make corrections.

[jeanclaude]

one last say : if you're using remote tuners then you must know that they can be unavailable at the time of a recording, and that recordings may fail. That's the price you have to pay when you're using remote tuners.

the conflict manager need not concern itself with this issue, it considers the remote tuners to be available at the time of recording, just the same as the internal tuners. And it must consider that the remote tuner has access to all channels in the local services file. Too bad if this isn't the case, but that's another consequence of using remote tuners.

 

I think you guys are making it too difficult : you will never be able to find the "perfect" solution.

 

using remote tuners as extra internal tuners (and limiting the number of extra internal tuners to add) will solve most problems, but not all. There will still be cases where recordings will fail. It's up to the user to decide if this is acceptable or not. If not, he can set the number of extra internal tuners to 0 in which case the timer conflict manager will not use any external tuner and will signal a conflict as soon as all internal tuners are used for a recording. The remote tuner will still be available for viewing/streaming but will not be counted for setting timers. If your remote system has several tuners, then you might set the number of external tuners to 1, hoping that this will be available in most cases.

 

in fact, the more I think about it, the better I find it :-)

 

I'm not a programmer, but implementing this is just a matter of letting the local receiver "think" that it has more tuners than it actually does, so this shouldn't be too difficult I suspect.

[Dimitrij]

AT can set disabled timers if all internal + remote tuner are occupied. It's up to the user to change the timers by activating the timers you need and by using the conflict manager to resolve the timer conflict by de-activating the timers you don't want/need.

Same option is for add standard timer.

If show conflict menu-->press green for disable this timer.

[Dimitrij]

step 1

Add option enable/disable conflict detection for each timer

Edited by Dimitrij, 5 November 2015 - 20:52.

[Erik Slagter]

one last say : if you're using remote tuners then you must know that they can be unavailable at the time of a recording, and that recordings may fail. That's the price you have to pay when you're using remote tuners.

the conflict manager need not concern itself with this issue, it considers the remote tuners to be available at the time of recording, just the same as the internal tuners. And it must consider that the remote tuner has access to all channels in the local services file. Too bad if this isn't the case, but that's another consequence of using remote tuners.

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.

[Erik Slagter]

step 1

Add option enable/disable conflict detection for each timer

Apparently this needs some discussion, a.o. with Littlesat

[Dimitrij]

You will not apply my patch?
Then I will not make the same code for the autotimer and think topic can be closed.

Edited by Dimitrij, 6 November 2015 - 10:48.

[Dimitrij]

Not enable fallback tuner --> not disable conflict detection

[blzr]

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

[jeanclaude]

 

 

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.

[littlesat]

You will not apply my patch?

Then I will not make the same code for the autotimer and think topic can be closed.

 

Probably it can be reconsidered...  Or at least commit a slightly different version.

 

 

Not enable fallback tuner --> not disable conflict detection

 

But I prefer to leave out the "coupling" and checks if the fallbak tuner is enabled.... Keep it as flexible as possible... I would not recommend to add restrictions. Keep it as a feature that just add an option to a timer where you can exclude that specific timer from the conflict check...

 

And please do not make changes to my previous general ignore timing conflict check stuff as I'm really considering to revert that stuff completely. I think it is not really required anymore when you can disable a specific timer from the check... I convinced this is even better!

 

E.g. a good addition then could also be to consider e,g. with yellow button or so on the conflict screen that allow you to disable a specific timer entry from the conflict check quickly without going back to the entry en step down to program the new "setting"...  With that suggestion added why should you need a general setting.... It is better to disable the check on purpose...

 

i understand really good that it is not "nice" when you make something and then it is not (directly) accepted... Sorry for that!!! And I think it will also not interfere with you considered changes to the Auto Timer plugin...

 

In between I hope my meaning, suggestions and considerations are clear...

Edited by littlesat, 6 November 2015 - 12:19.

[Dimitrij]

 

So the problem is with a fallback tuner...

 

Not enable fallback tuner --> not problem conflict detection

Therefore, such a check 'self.fallback_tuner = config.usage.remote_fallback_enabled.value and "http" in config.usage.remote_fallback.value' a must for each timer.

 

In my opinion it is not even necessary to discuss .

 

Autotimer changes can only be provided new option 'conflict detection for each timer'

Edited by Dimitrij, 6 November 2015 - 13:37.

[Dimitrij]

littlesat

You can then fix the patch as you see fit and apply it.

[littlesat]

I can "restore" the patch when you offer it again but next weekend I do not have time. So you need to allow me some time...

 

Not enable fallback tuner --> not problem conflict detection

Therefore, such a check 'self.fallback_tuner = config.usage.remote_fallback_enabled.value and "http" in config.usage.remote_fallback.value' a must for each timer.

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