94 replies to this topic

[Erik Slagter]

Right and the badness ist that when you programm the timers with conflict detection, you see  the conflicts and can solve the conflicts and everything if fine because the box knows how all local tuners can serv the timers but if a stream is running, you have a conflict and no user know about that tuner blocking handling of streams. That is not what the user expect

If you want to rely 100% on conflict detection, don't use fallback tuners. There is no way at all to make that work.

 

On the other hand, for a situation where your all your timers are created by autotimers (like for me), the fallback tuner can take care of more parallel programs being recorded instead of just a few.

[anudanan]

For me streaming is from the usecase very similar to watching live TV but only from a remote box and  I expect the same handling. Why must I accept the handling from today even when I configure timers has die highest priority. From a user view you can say it is a bug, because timer conflict handling works as normal and noone knows that streaminghandling etc.

Edited by anudanan, 27 January 2016 - 13:44.

[WanWizard]

I think the discussion is becoming way to complicated.

 

There is a standard settting that allows you to choose between giving priority to watching or priority to recording, in the situation where the box has no free tuner left.

 

If I interpret the remarks correctly, the only question is, that if this is set to "recordings have priority", the box should also terminate a stream to free up a tuner when there is no free tuner left.

 

This has nothing to do with conflict detection. If I have 4 tuners, and four separate recordings planned on four unique transponders, there is no conflict. Yet if at the time they start 4 streams are active, all 4 recordings will fail. Which should not happen.

 

I don't think there is more than this, or am I wrong?

[anudanan]

exactly, this is the only thing.

 

I mean with conflict detection, that during programming the conflict detection shows me, if I will have timer conflicts or not and it based only on local tuners inside the box. So I expect that other consumers of tuners later when timers claims the tuner must abort like live TV

[jeanclaude]

correct.

timers set up correctly with conflict detection activated should never fail, whatever the cause.

[Rob van der Does]

There is a standard settting that allows you to choose between giving priority to watching or priority to recording, in the situation where the box has no free tuner left.

 

If I interpret the remarks correctly, the only question is, that if this is set to "recordings have priority", the box should also terminate a stream to free up a tuner when there is no free tuner left.

Exactly. A stream should be regarded by E2 as 'viewing', not as a recording (as is the case now).

[littlesat]

We need a change in cpp to stop a stream... We already have a function that can chrck if streams are already running, including the client box ip and service ref and if the stream is encoded or not... I have trouble with my build environment, and more trouble to find time to fix my build environment. When someone create a function that can be called from python that can stop streams started remotely I can easily add in python stuff that stop streams....

A stream is seen as stream... Not as recording... See the latest function in Navigation.py to see how to obtain a list of streams...

With e,g, 

 

from enigma import eStreamServer

if eStreamServer.getInstance().getConnectedClients():

 

You can check if streams are running.... 

Edited by littlesat, 27 January 2016 - 14:48.

[Rob van der Does]

A stream is seen as stream... Not as recording... See the latest function in Navigation.py to see how to obtain a list of streams...

OK, that should simplify life!

But you have to find a way to tell the drivers this: at least for Xtrend & VU the recording icon shows on the VFD.

[littlesat]

What the drivers do with the VFD is not related what E2 is doing.... That is completely different.... And stuff in drivers we cannot fix... I think the drivers do indicate the recording icon when there exist a stream without showing it to the Video output encoder.... (or PIP)... And I'm also afraid the driver can never see if it is a stream of recording in those cases.... So somehow this can't be really fixed...

 

Very recently the list of streams was added... (the same could e.g. be used to give an indicator on the channel list...)

E.g. we need a function that stop one stream (when we have more running).... then we can stop it stream-by-stream until the recording can be made....

Edited by littlesat, 27 January 2016 - 14:57.

[anudanan]

I think also the record icon on the VFD is not the problem for implementing the stream abort function.

 

That sound very good. If anyone can integrate that, I´ll test it

Edited by anudanan, 27 January 2016 - 15:00.

[Rob van der Does]

What the drivers do with the VFD is not related what E2 is doing....

True. It's only cosmetic.

[anudanan]

I have understand most of the people here in the thread would prefer a solution that timers have a higher priority than streaming so it would be nice to abort streaming if a timer needs a tuner. That is mostly userfriendly and the same handing as watching live TV with local tuners

 

Is it visible in future to have this function in openPLI so

[littlesat]

It needs time.... Amd changes in cpp code... And my compile/build environment is broken that costs more time to rebuild....

[anudanan]

Thank you for information, no problem, it is not so urgent but nice for future

[littlesat]

When someone else can make a function to stop stream(s).... I really appreciate.... 

[littlesat]

FYI: https://github.com/O...82ce08d537da43f

 

Of course it can be finetuned.... But I would recommend to keep it simple... (I think recordings need always protection....)

Edited by littlesat, 6 February 2016 - 12:55.

[anudanan]

I'm not at home until 13th february. I will test it later. Great news and thank you

[anudanan]

I´ve tested it now successfully. Now if a timer needs a tuner which is using by streaming the stream aborts now

 

Thank your for work to implement this

[anudanan]

One additional topic for using fallbacktuner

 

The timer conlict detection during programming the timers works only with the knowledge of the local tuners and detects conflicts, if local tuners can´t serv the timers. I think that is fully ok and there is no need to use the fallbacktuner during this conflict detection because the availibility of fallbacktuner is not safe.

 

I´ve made some tests and saw that sometime a timer uses a fallbacktuner instead of using a local tuner. The situation was the following on the et9000 with 2 local tuners

 

I´ve programmed two timers for different transponders at nearly the same time. Timer 1 will start at 13:05, timer 2 will start at 13:10.  Before the timers start I watch live Tv on a 3rd transponder (Tuner A). Normaly without fallbacktuner  the first timer starts normally (on tuner and when the second timer starts I will get a message that the box will switch to an other channel (Tuner A)  to serv the second timer.

If  fallbacktuner is enabled then the situatuion differs. I watch TV on tuner A, The first timer uses tuner B. But when the second timer wil start it doesn´t switch local tuner A to the needed transponder.  The second timer uses the fallbacktuner, so the recorded movie uses the unsafe fallbacktuner.

 

From my point of view it would be better that the second timer also uses the local tuner A instead of the fallbacktuner. If I I would like to watch TV during the 2 timers run than the live TV can use the fallbacktuner.

 

So my idea is, that the timers first must use all local tuners (therefore switching live TV and/or abort streams). If all local tuners are busy then a fallbacktuner can by use

[WanWizard]

The box sees no difference, a tuner is a tuner. It sees that the local tuners is in use, so it will select a free tuner.