94 replies to this topic

[anudanan]

I´ve one question to fallbacktuner

 

If I have a box with n local tuners, then the timer conflict detection works find and detects timer conflicts during timer programming.

 

What is the result if I use a fallbacktuner. Works the timer conclict detection only with the internal tuners and does not use the fallback tuner, so the user can´t programm more timers than without the fallbacktuner? So the fallbacktuner can only user for live TV? Is that the intention of fallbacktuner? If it is not so, how works the timer conflict detection with fallbacktuner?

 

 

[WanWizard]

Timer conflict detection doesn't work with the fallback tuner. The same way it doesn't work with any stream.

Both sides of the stream have no way of guaranteeing that a tuner will be available the moment one is requested.

[anudanan]

So you mean if I use fallbacktuner than the receiver makes no conflict warning if the local tuners can´t serv the next programming timer and the box will use also the fallbacktuner for recording and not only  for live tV?

[WanWizard]

I think so, yes.

 

But I have to say I have never set a recording on a box that uses a fallback tuner. I use the remotetimer plugin to set the recording directly on my main tuner box. And I have no boxes that have both a local tuner and use the fallback.

 

It is easy enough to test. Zap around, make some instant recordings until all your tuners are busy, then define a timer for a channel that would use the fallback tuner. And then you will know.

[Rob van der Does]

So you mean if I use fallbacktuner than the receiver makes no conflict warning if the local tuners can´t serv the next programming timer and the box will use also the fallbacktuner for recording and not only  for live tV?

That is correct.

The (main) reason for that is that the client box has no idea about the availability of the tuner of the server box.

If you do it the way WanWizard suggests, all will be fine and safe.

The only other way is to disable conflict warnings in the settings (but then you will never get a warning at all).

Edited by Rob van der Does, 24 January 2016 - 05:14.

[anudanan]

Are you sure it is safe then? If I programm all timers on my main Box and use from my client box without tuners a fallbacktuner from the main box than I have the problem that the remote fallbacktuner blocks a tuner on my main box and it is not safe that all timers I have programmed there without conflicts can start there. 

[WanWizard]

Not if you have configured that on that box recordings have precedence (and afaik that is the default).

[anudanan]

I will Test it but I think the main box will block the tuner when a remote Client use it by fallbacktuner. It is the Same Situation like streaming from a tuner

[anudanan]

I've tested it now but it works not userfriendly from my point of view, the fallbacktuner client side works very well. If I programm there timer then the box detects timer conflicts based on the local tuner and does not include the falbacktuner for the recording schedule. That is a good idea so the fallbacktuner is useable for wathing tv when als local tuners are busy during recording.
On the main box side the test result is not safe for the timers which are programed there. I you watch tv via fallbacktuner from a client then these stream blocks one tuner on the main box. If the timers there need all local tuners for recordings because they need other trsnsponders than used by the stream for fallbacktuner use one or more timers fail. So it is not safe for timer programming on the main box. It is the same problem as with the partnerpox,
The only soltution for that was aborting streams when timer need tuners. But I understand it is not easy to integrate because the internal data structurs need typ informations for recordings to abort streams. I've seen that in the source of openatv enigma

[littlesat]

This can never work..... the tuner does cannot know if in future a fallback tuner is available.... Nothing is possible here....

[Rob van der Does]

@anudanan: you're correct: streams do ruin recordings.

So streams are a no go....

[anudanan]

It is not neccessary that a tuner knows ff a remote tuner is available in future because there is no need to record over a fallback tuner, only live watching make sense. And on the other end at the fallbacktuner serverbox there is a need that streaming must abort by recordings. Without these feature nothing is safe on the main box, so the result ist, streaming and fallbacktuner make no sende in recording szenarios..

 

Is it possible to integrate some source of openatv which handel these abortin (I know that are some c++ and python changes neccessary)

[Rob van der Does]

Although I'm not a coder (far from it), it seems to me that E2 should (be able to) know if a 'recording' is actually a 'real recording' (due to the fact that it was initiated by a timer??) or a stream (due to the destination being an IP-address or by the way the stream was initialized).

[betacentauri]

Yes, OpenATV has adapted their E2 to distinguish between normal recordings, streaming, EPG refresh and so on some months ago.

[jeanclaude]

I've said it before : the new recording settings don't make any sense any more if you attempt to use them as you will break any recording conflict logic.

take a receiver with 3 tuners and a remote fallback tuner declared on it.

you set 3 recordings : one at 10:00, one at 10:10 and one at 10:20, all on different transponders for one hour. There is no recording conflict but at 10:20 all 3 tuners are busy.

now you want to set another recording at 10:15. This will signal a recording conflict but you think "no problem I'll use the remote fallback tunet" so you de-activate the conflict detection parameter and you save your new timer.

 

what's going to happen you think ?

at 10:00 the first recording starts on tuner 1, at 10:10 the second recording starts on tuner 2, and on 10:15 the third recording will start but not on the remote fallback tuner but on tuner 3 which is still free.

now we're 10:20, time to start the fourth recording. As the 3 tuners are now taken, the remote fallback tuner will be used but if there is no tuner available on the remote receiver then this recording will FAIL, even it it has been set with the "detect timer conflicts" parameter on YES and with no conflicts detected during it's setup.

setting this parameter on "no" so you can use the remote fallback tuner will break the existing timer conflict detection on all timers which are in the same time-frame of the new recording. You'll never be sure what gets recorded and what doesn't.

 

I've already suggested in the past to remove this parameter. That way the timer conflict detection remains untouched, but you won't be able to set a recording for the remote fallback tuner. You will onlybe able to use this fallback tuner for viewing, if all local tuners are taken, and provided there is a free tuner on the remote receiver.

 

If you need more recordings than you have tuners available : set this timer on the remote receiver, NOT on the local receiver with timer conflict detection set to "no".

[anudanan]

My idea is not to record more movies than the local tuners can serv. You are right, only local tuners make sense to use for timer and the conflcit detection works fine for that.

 

But if you will watch live TV on the box which tuners are serving the recordings than fallbacktuner oder streaming from a remote tuner is fine to watch TV on other transponder. But if the remote box needs their tuner later for their own recording than the remote box must abort the streaming to use the tuner for their local recordings.

 

It is the same as you see when the box switch the live tV to make recording. Here the remote box cuts the stream and you see than no TV or the TV to which the tuner must swtich

 

Not more and no need to make recordings over fallbacktuner or streams

[littlesat]

Yes, OpenATV has adapted their E2 to distinguish between normal recordings, streaming, EPG refresh and so on some months ago.

 

Where did they made the change on github.

 

(and somehow I did never notice an issue here...)

Edited by littlesat, 25 January 2016 - 11:21.

[anudanan]

The changes are here

 https://github.com/o.../master/lib/nav

for some core rouines

 

and here for starting timer, claiming tuners and aborting streamings

https://github.com/o.../RecordTimer.py

 start at line 466

 

And I think some more files for setup the parameter 

Edited by anudanan, 25 January 2016 - 11:34.

[littlesat]

I found the "basic" patch...

 

https://github.com/o...8b58eb870cf49f4

 

sorry.... what a madness hack on my recording registration hack.......

 

But as far I can see streamings are also stopped.... They are not registered as recording in OpenPLi... Unless there are some drivers that indicate a recording thing in the display of a tuner... As far I know a stream is not registered as a current recording...

Edited by littlesat, 25 January 2016 - 12:28.

[anudanan]

Are you shure? if I use a stream from a remote tuner (an et9000 with 2 tuners)  and during watchting them I start a recording timer on the streamserver box on a different transponder then I see in the channellist after starting the timer only the channel highlighted which are on the transponder of the timer or the stream tuner

 

So I think enigma handels inside openpli image the streams similar to recordings

But you are right? I look like a madness hack

Edited by anudanan, 25 January 2016 - 13:21.