137 replies to this topic

[WanWizard]

No problems with 1.

 

2. users who will use fallbacktuner for recordings and live TV

The box than use first the local tuners but doen´t interrupt live TV and use the fallbacktuner for the recordings which can´t use local tuners

That is exactly that what openpli 6.1 actual does

That is really ok for that users

 

Yes, this is what 6.1 does, but to me it is wrong. It should interrupt the TV to claim the local tuner, unless it is configured that TV has priority over recordings. Better to have a succeeded recording and some hickups watching TV, then watching TV uninterrupted, and have a recording fail in the background.

 

So I don't agree with the fact that the current situation is ok for users.

 

So my question is, why is that switch so bad. I can´t understand it and I know from my 3 boxes with openpli 4.x it works very well and there is a diffferent between True and False of that switch. 

Today the user group 3 can´t user fallbacktuner for live TV only and must disable fallbacktuners. From my point of view it works better with the old switch.

 

And no problems with 3.

 

The issue isn't that the presence of that switch is bad, the issue is that the implementation in that commit didn't do what it was supposed to do. The fact that it also did what you wanted was if you will a side-effect. So that commit will not be re-implemented (as it is wrong), but that doesn't mean your use case is not valid.

 

Question is how to implement the required functionality for both 2 and 3, which is:
- the option to enable/disable the fallback for TV/Recordings/streams, to replace the current global "fallback yes/no" question 

- the option to define that a recording should always use a local tuner if available (so pretend no fallback is configured), and only if that fails, use the fallback (if enabled)

[anudanan]

I understand your point.

But if openpli will work as you expected for use case 2 (all local tuners will use for recording including that the last tuner claim will swtich the live TV) than there is no need to make a special switch for disabeling fallbacktuners from recording. Using in that case fallbacktuners for recording will only happend if the users program timers without conflict detection and when a user do that he must know that if all local tuners are busy by recording than the fallbacktuner will be used.

 

The only change we need is that if fallbacktuner is enable the last tuner claim for recordings must use the tuner of live TV instead of using fallbacktuner

[anudanan]

I´ve made today some dirty code changes in 

/usr/lib/enigma2/python/RecordTimer.py 

to find a solution for me. 

Before the activation of timers I set temporary the confg.usage.remote_fallback_enable to false and after activation I set it back to the old value

 

It works for me now that timers now claim the last tuner of live TV if neccessary until the openpli 6.1 image has a better solution

Edited by anudanan, 6 February 2018 - 12:04.

[littlesat]

The reversion of the commit is reverted now in Develop so we can further investigate this one...

[anudanan]

Wow, that is a quick reaction

 

Thx for that and I hope you will find a solution for all user and developers 

[Erik Slagter]

Don't get happy yet. I will probably just prove my point that it doesn't do what you want and if so, it will get reverted. Again.

 

We all understand your case, it's just not so easy to implement it.

[anudanan]

Actually I work with my dirty code changes of RecordTimer.py and that works fine for me.

Edited by anudanan, 7 February 2018 - 03:30.

[Dimitrij]

anudanan

Show these changes.

[Rob van der Does]

@Dimitrij

have you seen my PM?

[anudanan]

Because I don´t what to use fallbacktuner for recordings anymore I´ve made a very dirty change in RecordTimer.py. I use this way because changing a py file for a running system is easy, but changing cpp files needs a new enigma build which I can´t do quickly.

 

So this change is only goog for me but  I think the change is bad for you because I changed temporary the config parameter for fallbacktuner, that it not a way to do it, but so I only need to change one py file in my running system

 

Here the changes, the 3 additional lines are bold. They are in doActivate(self,w) at line 759

 

                        tmp = config.usage.remote_fallback_enabled.value

                        config.usage.remote_fallback_enabled.value =  "false"

                        if w.activate():

                                w.state += 1

                        config.usage.remote_fallback_enabled.value = tmp

[WanWizard]

The problem with this is that it doesn't address the problem of "use local tuner first" for people that want to use the fallback tuner.

[anudanan]

Yes that is right, that feature needs more code changes

 

My dirty patch makes the same as the reverted changes from march 2016 without a config parameter to enable/disable recordings with fallbacktuner, It is only a patch for users like me

[anudanan]

I think there are code changes neccessary in

 

 eDVBServiceRecord::doPrepare() and other files

 

today the early use ot tryFallbackTuner call is from my point of view the reason that the last claimed tuner comes not from live TV but from the fallbacktuner 

 

But I don´t have an overview how to change it

[WanWizard]

From a logical point of view, we need to call doPrepare() with the fallback tuner disabled. If that fails (no more tuners), and you had fallback enabled, and you want to use the fallback for recording, call doPrepare() again, but with an enabled fallback.

 

Unfortunately, my knowledge of the inner workings isn't of the level that I can say what code is needed to achieve that.

[littlesat]

What my patch did in doPrepare is in the try function indicate that it should be tried for an recording. When it is not a recording it tries with the current setting for fallback tuner, when it is a recording it checks of it can use a fallback by the new fallback setting regards the recording... No need to call stuff twice...

 

That is also the reason of the hard coded recording flag in doPrepare... Note that you also need to be somehow backwards compatible with other stuff and plugins in E2 for the usual try function....

 

I cant remember why I put that else (void)0; there.... for as far I can see this looks like a mistake so this can be removed...

 

https://github.com/O...98672ef38ea9825

+ if(is_recording)
+ if (!eConfigManager::getConfigBoolValue("config.usage.remote_fallback_recording_enabled", false))
+ return false;
+ else
+ (void)0;
+ else
+ if (!eConfigManager::getConfigBoolValue("config.usage.remote_fallback_enabled", false))
+ return false;

Edited by littlesat, 7 February 2018 - 14:20.

[WanWizard]

Your patch uses the fallback tuner when there is still a tuner available. And that is the main point of this discussion.

[littlesat]

+ if (is_recording)
+     if (!eConfigManager::getConfigBoolValue("config.usage.remote_fallback_recording_enabled", false))
+         return false;
+ elif (!eConfigManager::getConfigBoolValue("config.usage.remote_fallback_enabled", false))
+     return false;

Edited by littlesat, 7 February 2018 - 14:23.

[WanWizard]

Yes.

 

So if the fallback is enabled, it falls through, and uses the fallback instead of the local tuner that is still available, and which would be used if fallback wasn't enabled. 

 

This is the point of this topic as reported by the TS.

[WanWizard]

To make it clear (example: a twin tuner box with fallback enabled):

 

Start situation:

• Tuner A in use by recording #1
• Tuner B in use by watching TV
• Fallback tuner free

Now a new recording starts on a different transponder.

 

Desired situation:

• Tuner A in use by recording #1
• Tuner B zaps away to start recording #2
• Fallback tuner free
• Using the < button will restart watching TV, on the fallback tuner

What actually happens:

• Tuner A in use by recording #1
• Tuner B in use by watching TV
• Fallback tuner will be used for recording #2

Correct, TS?

[littlesat]

Yep now I got it ... Sounds like we need to search for a 'free' tuner -before- we check for a fallback tuner...