137 replies to this topic

[anudanan]

yepp, that is the idea

[WanWizard]

Sounds like we need to search for a 'free' tuner -before- we check for a fallback tuner...

 

That was what I meant with "check twice".

[littlesat]

Finally al our spaghetti thoughts come together... ... In short my patch that was reverted and now reverted-reverted needs indeed to be 'improved'.... The separate config is good... only the 'fallback' for recording should first try to 'steal' a tuner before using a fallback tuner...

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

[littlesat]

But there is something weird at the code I don't get now... the try function returns true or false and this true and false only gives the debug code.... 

[Erik Slagter]

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

Depends what you call available ;-) It's in use at that point, but it can be forced to another service because it's used for viewing. Enigma calls it "unavailable".

[Erik Slagter]

I will revert the revert of the revert iow remove the patch again, so it can buried for good now. Then, as suggested in the commit, we can start from scratch and make it correctly.

[anudanan]

Thank you for your information

 

I can work until a correct and clean  solution is available with my three dirty code lines in RecordTimer.py because I don´t need recordings from fallbacktuners

 

What exactly is a correct solution from your point of view? 

Edited by anudanan, 8 February 2018 - 19:29.

[WanWizard]

Depends what you call available ;-) It's in use at that point, but it can be forced to another service because it's used for viewing. Enigma calls it "unavailable".

 

Semantics. You know what I mean...

[anudanan]

Do you have made changes around the fallbacktuner handling or is the code equal to the code from the beginning of 2018

[Erik Slagter]

The base code is exactly the same. But I don't know what has happened to the features around it.

[WanWizard]

In develop support for timers has been added, so a slave box can see, edit and add timers on the server box. And there were some details changed around the EPG sync. But nothing to the streaming itself.

[anudanan]

I´ve found in the release notes of openpli 7.0 the following note

 

Improvements

• Fallback tuner possibilities extended. (See wiki... tbd.)

 

Do you have more information about the improvements?

[littlesat]

On a cliënt box you can control the timers on the server box... (with some tiny limitations). Enable the feature in the fallback tuner setup and do menu timer and you see...

Edited by littlesat, 17 November 2018 - 11:20.

[anudanan]

Since 2 weeks ì´ve installef openPLI7.0 and it is very stable and I like it.

 

I´ve tested my demand on the fallbacktunerhandling with recordings I don´t like to use fallbacktuner für recordings if a local tuner can switch from LIVE TV to the channel for recording. I like to use the fallbacktuner only für LIVE TV

 

My result is that in 7.0 as in 6.1 I have to implement my workaround for my demand with a little modification of RecordTimer.py to have that feature.

 

https://forums.openp...e-2#entry840803

 

Is there a plan in future to implement the handling (switchable) which prevents recordings from fallbacktuner?

Edited by anudanan, 3 January 2019 - 13:04.

[littlesat]

What is the idea behind your suggested patch....? I think it is better to add a feature 'never plan an instant recording on a fallback tuner' and cover it in w.activate or so...

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

Edited by littlesat, 3 January 2019 - 15:30.

[littlesat]

But it is hard to find where is 'activate'..... as it is a 'dummy' function....

But this is a repeated discussion... not record on fallback tuner... You know you can already plan a timer or on remote directly or on local box... the instant recording I is not done yet this way.... And wat of in your example a local tuner is not available...??? It never can fallback again... so there must be a 'smarter' way...

Edited by littlesat, 3 January 2019 - 15:41.

[anudanan]

in short the idea behind my patch

 

I would only programm timers for my local tuners on my boxes The timer conflict detection works only for the local tuners and I that is fine for my and I think for many other users with local tuners.

 

If I use the last tuner for my live TV watching and the next timer needs this last tuner then I would like that the timer claims the last tuner for LIVE TV and so the box switches the LIVE TV to the channel for recording of the timer. Than I can switch the LIVE TV back to and then it takes the remotefallbacktuner.

 

I would like this because my box which provides the fallbacktuner has also programmed timers: So there is a conflict on that box if  their timers need all tuners of that box.

 

My problem with the implementation today is

Today without my dirty patch the first box uses for the last recording the fallbacktuner and then the remote box has a problem for their timers. The timer conflict detection has said everything is ok with timerprogramming but if one tuner provides a fallbacktuner then it is not true.

 

So in short I would like to have a parameter "Never use fallbacktuner for timer recording". A user can than decide which setting is useful 

[anudanan]

See also here the explanation for that of Wanwizard

https://forums.openp...e-2#entry841046

Edited by anudanan, 3 January 2019 - 16:41.

[littlesat]

I remember in the past I had a seperate config for the fallback tuner for recordings... but someone of the team reverted it as he thinks it cannot work...

 

 

This reverts commit 65250a2.

- it's confusing
- it doesn't actually do what it suggests
- there is no advantage really

When you use this option and set it to "no", the only difference
is that a recording that already couldn't be made in the first place,
now also won't be made using the fallback tuner, so it always fails.

This option works at the wrong level, at this point the user cannot
be informed so the only options are:

- make the recording using the fallback tuner
- don't make the recording at all (and thereby failing)

So this option is useless. It should be implemented at user-interface
level, i.e. in the timer conflict detection. If one doesn't disable
the conflict detection explicitly, fallback tuners won't be considered

for timer recordings anyway.

 

https://github.com/O...606df79f6eef93f

Edited by littlesat, 3 January 2019 - 17:20.

[anudanan]

Yes, this was based on my request. I have not understand in the past the reason for the revert. I think without a special parameter at user level there is no way to have a solution for different demands of users which are using fallbacktuners for different situations.