59 replies to this topic

[Dimitrij]

+1

This is 100% marketing.

[Satpal]

Problem is there are thousands of channels and you can only pre-tune a few. So how do you decide which ones?

This isn't really an issue, the way it is possible to configure it now should do it: e.g. previous channel and next (+1,2 or 3) would be sufficient for most users, I guess. As long as you know how you have to adapt your bouquets it should be fine.

[Huevos]

My channels are in alphabetical order.

[WanWizard]

I never zap that way, that is wasting too much time zapping to channels that don't have anything interesting on. I always zap using EPG information, so I can skip channels with rubbish on...

[mymon]

same here.. I open the list >> fly through >> jump on what I want to watch

but I guess some people use the PiP and zap through it till they find what they want (not my thing either)

[Rob van der Does]

And I never zap at all, as I never ever watch any live-TV, which is a waste of time. Everything that is or might be interesting will end up on my hard drive.

 

So a not-me-too from me

[holymoly]

Since Opli says that they know what end users need, many have turned away from the image. With this opinion, they will eventually stand alone. I like to use FCC on a different team image.

[WanWizard]

You seem to have trouble reading.  We said:

 

We can't implement whatever VU+ has cooked up. And we don't think this feature is important. We are not going to spend our very scarce free time on what we think is a gimmick, we have more important things to do. If someone else finds it important enough to create an offer the code and the code meets our standards, we have no objections adding it to the image. To be clear, it is not a NO, it is a "we are NOT going to do it".

 

It is a misunderstanding that if YOU complain long enough, and YOU think that because it is important for YOU, we should drop everyone and serve your every whim. 

 

To make it clear, it doesn't work that way. Capice?

[holymoly]

Then do as you think. Always on your own head and you are losing more and more users. Bye,Bye oPli

[Erik Slagter]

#meToo

 

PS: the pre-tuning part of FCC would also add value on the zapping speed and this is possible as a plugin without harming anybodys feelings when the box has enough tuners free.

And have you read the whole topic and also understand the way VU+ implements it?

[Erik Slagter]

Then do as you think. Always on your own head and you are losing more and more users. Bye,Bye oPli

Yes, we could definitely do with one user less that is only complaining, whining and annoying, and not contributing anything.

 

I think we should stop explaining our considerations because clearly some users cannot handle that knowledge.

[mymon]

so much noise about gaining few mili-seconds while changing the channel? - or am I missing something significant?

[Lost in Space]

Yes I have read the topic and I understand how ugly it is inplemented

 

And yes tuning a channel without viewing it is possible (every recording knows how to do that) and it saves around 200-300 msec when zapping. This is exactly the difference in zapping speed when you switch between channels on same transponder or a new transponder.

 

The code for maintaining the next/last/history in a list is not that bad and if you use it to keep some spare tuners busy and get the above positive effect on EVERY box with enough tuners ... why not ?

 

For achieving this simple part you ONLY need a python plugin and no C++ code, changes in drivers, etc. at all.

 

And yes I know that this works, because I tried it out already

Edited by gutemine, 29 December 2017 - 12:10.

[mymon]

not sure how you measured that (would have to check the oscam log while zapping) but even assuming it is 200-300ms than its simply not worth the hassle

Edited by mymon, 29 December 2017 - 12:17.

[littlesat]

VU's FCC does not only tune. It also decodes and decrypts the channel in forehand so you can zap the 'pretuned' services withing a mili second... So when zapping to the previous channel, the next and over next in a list you've picture like it was in the analogue time.

 

So you can tune and decode 4 channels at once (which Quadpip proves and that is also why VU disabled this feature in Quadpip). And when you have a PIP window you can pretune one channel less (I see a lot of fixes on the orriginal VU's patch on this PIP topic). 

 

So there is no wait for 200-300 msec in VU's FCC way... the original fastzap 'plugin' indeed had this...

 

For this 'pretune' and switching the video encoder to the screen you actually see you need some c++ code.

 

But to control the pretune services and select an encoder that pretunes a channel selected can (should) be arranged in python. As in python we have the controll to the 'current' service list.

 

I have a 'raw' idea how to make it properly, but no 'time' to implement it, as other stuff has priority...

 

If 'others' were also motivating to make it properly we might already had it... We're open source so everyone can start... We're willing to help and guide through how we prefer to have it in a structured way...

Edited by littlesat, 29 December 2017 - 12:25.

[Lost in Space]

You just need a print in the enigma2 code logging the timestamps to verify the gained time pretty accurate.

 

If you consider 10-30% of the typical zapping time ... useless ... thanks for your input!

 

Even if you avoid the decoding you still gain ... something ... without the trade-offs already discussed extensively in this thread ... and fully portable because you then rely on the e2 tuner handling which is already clever enough to re-use pretuned frontends instead of allocating new ones.

 

 

But off course then you only get "Faster" Channel Cange ...

Edited by gutemine, 29 December 2017 - 12:23.

[mymon]

I really do.. its not a voice call or any other service that gets interrupted due to latency - its just 200-300ms while changing the channel - get a life

[Erik Slagter]

Yes I have read the topic and I understand how ugly it is inplemented

 

And yes tuning a channel without viewing it is possible (every recording knows how to do that) and it saves around 200-300 msec when zapping. This is exactly the difference in zapping speed when you switch between channels on same transponder or a new transponder.

 

The code for maintaining the next/last/history in a list is not that bad and if you use it to keep some spare tuners busy and get the above positive effect on EVERY box with enough tuners ... why not ?

 

For achieving this simple part you ONLY need a python plugin and no C++ code, changes in drivers, etc. at all.

 

And yes I know that this works, because I tried it out already

You are here suggesting to take an alternative approach. Which isn't bad, I think, but it doesn't take advantage of the low-level support VU+ has in it's drivers for this.

 

I am agnostic here, if someone makes a plugin, or even better, some code that implements in enigma, that does what you propose, I'll gladly add it. OTOH if someone makes the specific code for VU+, I'll also be adding it. The only factor here is "time", that we cannot spend on this.

[Lost in Space]

well, ff somebody tells you that you can solve 30% of a problem with only 10% of the effort - you can still ask for the 100% ... but I'm not listening ...

Edited by gutemine, 29 December 2017 - 12:27.

[Frenske]

Nothing is impossible.

 

It is a matter of listing the plusses and the minusses of a feature, and with the result find someone who is willing to spend their spare time implementing it. 

 

The result of this is that for the moment, we see not a lot of plusses (it only works for a specific group of people, and only for boxes with plenty of tuners), quite a few minusses (it will result in a lot of disabled smartcards or server connections due to excessive requests), and not a massive improvement in zap time.

 

And this means we're willing to look at it if someone provides the correct code for it, but we will not spend any of our free time on it.

 

I guess, for now we have stated how the present opinion is. As soon as there is more available time, we'll think about implementing this option.

I close this topic and if the time is right I will open it again.