43 replies to this topic

[Pr2]

Hi,

 

I am running Openpli4 with default skin and running OScam in pmt_mode 6 (use CA PMT server).

2nd infobar is defined to have no timeout (so it remains permanent until I quit it).

 

1) When watching scrambled channels and enabling PiP also on scrambled channels enabling the 2nd infobar show the crypto info toggling between main screen and PiP screen info (remark: a nice to have a feature would be a PiP flag on the crypto info to mention that this one is for the PiP).

This is, I guess, the normal behavior expected by the skin.

 

2) When watching on the main screen a FTA channel and enabling a scrambled one in PiP, we have no info at all in the crypto info. It remains stuck on FTA so no toggling between FTA and scrambled info (like described in point 1).

 

3) When watching on the main screen a streamed channel by another STB that does the unscrambling on the same LAN (so stream is FTA), that is predefined in the channel list (remote_server) and when we enable the PiP on a DVB channel that is scrambled we have no info at all about the crypto.

 

Can you please have a look at this? I think we should let the crypto info always looking for crypto info independently from the watched main screen type.

 

Pr2

 

 

 

 

[littlesat]

Crypto info is simply displayed by parsing /tmp/ecm.info..... So it depends on what your emu does (cccam behaves different from oscam)... So always with pip and also with recordings this info coud ve alternating (oscam) or showing just the first decoded service (CCcamm as it creates more ecm.info files - enigma2 cant know what is thte mainscreen...)

There is no solution for this bahavior... Even de emu does not know which ecm is intended for the mainscreen... So in oscam it can't be solved either...

At this moment it is as it is... unless this I exactly understand what you meant.

Edited by littlesat, 10 June 2014 - 21:03.

[Pr2]

Hi,

OK I understand for the case 2, the mainscreen is FTA so what prevent the scrambled PiP ecm.info to be displayed?

But perhaps it is because the softcam doesn't delete the ecm.info "when expired" so switching to and FTA and checking the /tmp/ecm.info will generate a false info, is it right?

Perhaps a stupid suggestion but cannot we have the CA_PMT server to generate also a kind of ecm.info that can be used to display proper information in the skin? Since CA_PMT is I think a specific implementation of Openpli you probably have more control on it and provide a more accurate information than the one from the softcam?

Pr2

[littlesat]

For the ecm.info we are depending on the used softcam... That is how it works... pliextrainfo.py does already some transfers... Ehat you mention we can only give the cw created by the softcam... Even the ecm used can't be given...
So the info we display here is in fact fully depended on what the softcams do offer us...
I'm afraid everything was designed for a single tuner... Not for dual tuners, streaming stuff etc...

Edited by littlesat, 10 June 2014 - 21:28.

[Satpal]

Crypto info is simply displayed by parsing /tmp/ecm.info..... So it depends on what your emu does (cccam behaves different from oscam)... So always with pip and also with recordings this info coud ve alternating (oscam) or showing just the first decoded service (CCcamm as it creates more ecm.info files - enigma2 cant know what is thte mainscreen...)

 

Ok, that's maybe the time to jump in. I was wondering about this issue for quite a while already, thanks for clearing this up. So as I see it CCcam at least would provide the necessary info by creating two ecm.info files for the skin to display the ecm info for both tuners (speaking about a dual tuner here, of course; so btw, I guess CCcam would create even more info files on boxes with 3 or 4 tuners?). As those ecm.info files are created by CCcam I never really understood why nobody seemed to feel the need to implement those into the skin, for my taste way more useful than a lot of graphic stuff.

 

With CCcam I figured out that it was mostly possible to get the required info even without going through a lot of menus by using PIP and swapping it around. (Although I still never found the Node ID displayed in E2 as it was in E1, or is there some other reason it's not done anymore?)  But i didn't check if there were changes with the new PIP developments that might prevent this from still working.

 

But there's also one question I haven't seen asked or answered about the new PIP functions until now: Before activating PIP resulted in duplicating the active channel into the small picture. Now it seems that the previous small picture is always restored. Is this the case? And if so was this intended and is this adjustable?

[littlesat]

Indeed in the pip we show now the latest pipped channel... In fact everytime showing the current channel was stupid... I think we should not make this confirable. What exactly do you not like with this new behavior?

Edited by littlesat, 11 June 2014 - 09:35.

[rtzhjgg0]

 ...Before activating PIP resulted in duplicating the active channel into the small picture. Now it seems that the previous small picture is always restored. Is this the case? And if so was this intended and is this adjustable?

I'm too not comfortable with the feature 'new PiP=latest pipped channel', so hopefully it will be  somehow configurable in the future

[Pr2]

I agree I also dislike that the lastest PiPed channel is still used by default. 

 

Lets give a clear exemple: if you PIP a porn channel, the next time you press the PiP key you probably don't want to start on this channel... 

 

Less "sexy" exemple is that now when you press the PiP channel you will probably not remember the last channel you were on, so if you have small children pressing the PiP will always be a gamble on what will be displayed on screen (exemple -16 or -18 movies)... not very good.

 

I think that this feature should have a kind of timeout, you watch a PiP channel by mistake you leave it, then by pressing again PiP it returns to this PiPed channel immediately (that sounds good), but not after several hours not.  

I think that we can imagine that after 5 minutes without watching the PiP this history is cleaned and we return to the normal PiP behavior (PiP current channel). So everybody can be happy with this.

 

Pr2

[Dimitrij]

Eventually it will be improved.
Give it time.

[betacentauri]

I found the old behavior quite bad. If you accidentally closed the pip, it took several klicks to see the old channel in the pip window.

And the pip channel is only stored until restart of the GUI. And if you can watch 18+ videos/channels your children can also accidentically open that channel via channel list...

[Rob van der Does]

I found the old behavior quite bad. If you accidentally closed the pip, it took several klicks to see the old channel in the pip window.

That's why you should configure 'exit PiP' with pop-up or not with 'exit' at all.

[littlesat]

The pip will not start for porn when you use parental control....
Possibly a timeout if one minute or so could arrange a fall back to not using the latest pipped channel.... This is just a suggestion... I suggest we should not made this...
A popup for closing pip is even more terrible...

Edited by littlesat, 11 June 2014 - 14:49.

[Satpal]

The first time I used PIP on a device it behaved the way OpenPli does now, i.e. last used small picture pops up again. When I started to use OpenPli with the old PIP style it took me a while to get used to it. Same happens now, I'll probably get used to the new behaviour again soon enough but I still believe it would be a good idea to add this choice in menu, too, if it's not too much trouble. All the points given above are valid and both sides should have the possibility to configure it as they like.

[betacentauri]

If you change it, please don't implement it with a timeout. That's only a workaround to don't show specific channels. Or add also infinite to the choices...

[Pr2]

... And if you can watch 18+ videos/channels your children can also accidentically open that channel via channel list...

Hi,

Except that they watch TV under my supervision, so in the older way I can press the PiP without problem since I know what will be displayed in the PiP screen.
With this new approach you never know which kind of image will be displayed in the PiP windows and a quick zap requires: to press the blue, the red one to enable PiP-Zap and then you can zap to something not really the most efficient thing.

I don't understand why when a new feature is implemented we cannot choose to still use the old behavior since it is technically possible.

About the discussion about the PiP exit menu we already have it in OpenPli (I hope it is still there!) and I have enable this feature, so I never exit PiP by mistake.

Pr2

[Satpal]

Pr2 just summed up my point of view exactly.

[littlesat]

Indeed the new algorythm is not parental protected as far I can see now.... So a work a round to stop remembering the last pipped service is already a good work a round...

We're open source and usually we do not make changes that will have a direct effect. But also we try to avoid extra configs and keep everyting as far as standard possible...

For now I think a timeout for remembering then last pipped service
is a good idea...

Please remember... To improve thinks you do not stive to suck with something you're used to.

Edited by littlesat, 11 June 2014 - 22:30.

[Satpal]

In fact everytime showing the current channel was stupid...

 

Indeed the new algorythm is not parental protected as far I can see now.... So a work a round to stop remembering the last pipped service is already a good work a round...

We're open source and usually we do not make changes that will have a direct effect. But also we try to avoid extra configs and keep everyting as far as standard possible...

For now I think a timeout for remembering then last pipped service
is a good idea...

Please remember... To improve thinks you do not stive to suck with something you're used to.

 

After a few days of consideration (and trial and error with the new setup) I must say that I don't like the new style at all. When reading your comment at first I totally agreed as I felt the same way

 

from the beginning when using PiP, it just seemed stupid. But now I have to disagree. For 10 days I tried to get used to the new way and noticed a few things: I NEVER remembered what had been

 

the pipped channel after a few hours or the next day and I NEVER needed to use the last pipped channel. Ok, the last point may change from time to time and may certainly varies from person to

 

person.

 

But what really hit me is that there is no way to call PiP now even if you know which channel is pipped if you don't want to let a third person see the pipped channel. So now I think the way it was

 

before was not that stupid but had it's good reasons. I don't think any kind of timeout would really help me there unless the timeout would be configurable and "0" would mean old style. Using

 

parental control would make things only worse as I never use it and never needed or wanted to use it. That's one of the main reasons I use linux stb's instead of the boxes provided by pay tv

 

providers: to get rid of things like parental control.

 

Of course I understand your point about avoiding extra configs but when I have a look at it now I see things like the "exit PiP" with exit button config or "preferred tuner for recording" which wasn't

 

there in the beginning, I believe (which I couldn't believe at the beginning), I certainly feel this one to be just as important.

 

Not to mention that with this change OpenPLI now is acting in a different way than standard E2? So what about keeping standards there?

Edited by Satpal, 20 June 2014 - 14:03.

[WanWizard]

What is "standard"?

 

We work on the OpenPLi product, and since there is no community, all we can do to progress and improve is to work on our image.

 

If we have to take other projects into consideration, given the fact that none of them want to interact (and DMM has even withdrawn themselfs) , every attempt at innovation would grind to a halt.

 

OpenPLi is a product in itself. People should stop assuming (or expecting) that everthing with the "Enigma2" label is identical and interchangable.

 

It's like with cars: Both Mercedes and Jaguar are cars. That doesn't mean you can simply take the wheels of one and put them on the other. Or that the light switches are in the same place and operate the same...

[Rob van der Does]

Granted

What is "standard"?

OpenPLi is a product in itself. People should stop assuming (or expecting) that everthing with the "Enigma2" label is identical and interchangable.

Granted.
But: then one should also stop saying about the CH+/- buttons 'that they are meant to open the bouquets, because that's how it has been designed in E2' (while all but DM's R/C have then designed as zap-button).
The same argument can't be used both ways.