Jump to content


Photo

merge requests for PLi's git


  • Please log in to reply
1748 replies to this topic

Re: merge requests for PLi's git #641 Rob van der Does

  • Senior Member
  • 7,766 posts

+184
Excellent

Posted 8 September 2014 - 17:16

Of course I won't use it.
But as I said: it beats me that anybody would. For the reasons Erik mentioned.

Re: merge requests for PLi's git #642 jpuigs

  • Senior Member
  • 1,143 posts

+32
Good

Posted 8 September 2014 - 17:56

Talking about channel lists there is a thing which I'd love to have it (and possibly some other users too) : to be able to "unsort" channel lists, especially in satellites (green key) section.

Then I'd sort them like I do with favorites.

If it's not possible, I'd love too to choose to get them sorted by frequency (from lower to higher) instead of names.


Edited by jpuigs, 8 September 2014 - 17:57.

Enigma is getting old....

 

Spoiler

Re: merge requests for PLi's git #643 Erik Slagter

  • PLi® Core member
  • 46,951 posts

+541
Excellent

Posted 9 September 2014 - 14:47

But you can simply not use it.
A large part of what I suggest, I personally do not use, but it has asked for users, for which it is very important.

Maybe it's better to explain to the user why it works this way and also it may be better to find out what the user really wants (which often appears to be something not exactly the same) and solve that instead.

In this case it's often related to parental control. A better solution might be e.g. optionally locking the "all services" and "satellites" lists using a pin code, instead of damaging the database.

* Wavefrontier T90 with 28E/23E/19E/13E via SCR switches 2 x 2 x 6 user bands
I don't read PM -> if you have something to ask or to report, do it in the forum so others can benefit. I don't take freelance jobs.
Ik lees geen PM -> als je iets te vragen of te melden hebt, doe het op het forum, zodat anderen er ook wat aan hebben.


Re: merge requests for PLi's git #644 Taapat

  • PLi® Core member
  • 2,343 posts

+120
Excellent

Posted 9 September 2014 - 17:42

Sorry, my English is not good, but I have already explained why it is necessary when propose the patch.
It seems to me, that you do not create your bouquet by yourself. Therefore, you can not imagine that there are users who are important to know, which of the channels are working with the same name, when creating a bouquet on computer.
If we accept all TV channels deletion, why not accept the deletion of channels one by one?

If this option is not acceptable, of course you can revert it. I only propose, and your choice is to accept it or not. In my receiver it works, and if anyone do not need it, for me is not very important if it is in openpli image or not.


Edited by Taapat, 9 September 2014 - 17:43.


Re: merge requests for PLi's git #645 Erik Slagter

  • PLi® Core member
  • 46,951 posts

+541
Excellent

Posted 9 September 2014 - 17:51

As a matter of fact I do create all my bouquets myself.

 

I suggest you do this:

 

- select one by one all satellite positions

- press menu on it

- choose "create bouquet from satellite position"

 

Now you have "master bouquets" you can edit at will and derive other bouquets from.

 

We might want to implement something similar for the "all services", i.o.w. create a "master bouquet" as a copy of the "all services".


* Wavefrontier T90 with 28E/23E/19E/13E via SCR switches 2 x 2 x 6 user bands
I don't read PM -> if you have something to ask or to report, do it in the forum so others can benefit. I don't take freelance jobs.
Ik lees geen PM -> als je iets te vragen of te melden hebt, doe het op het forum, zodat anderen er ook wat aan hebben.


Re: merge requests for PLi's git #646 jpuigs

  • Senior Member
  • 1,143 posts

+32
Good

Posted 9 September 2014 - 18:54

Thanks, I already knew this way.

By the way, the option I have on menu is called "copy to bouquet", not "create bouquet from satellite position".

This option lets you edit and order all satelliteas you want, but there is asmall problem.

When background scanning is working, new channels are added to satellite lists, not to favourites. So new channels won't appear on these new master bouquets.

That's why I asked to be able to choose to order channels into satellite lists either by name (actual behaviour) or by frequency.

Then If you choose "by frequency", channel lists could have 2 colour bars to see differences between transponders.

Look at the attachment I've made.

 

 

Attached Files


Enigma is getting old....

 

Spoiler

Re: merge requests for PLi's git #647 Erik Slagter

  • PLi® Core member
  • 46,951 posts

+541
Excellent

Posted 11 September 2014 - 15:10

Yes exactly, the background scanning, which is going to overwrite any changes you make to the "all services" at some time.

* Wavefrontier T90 with 28E/23E/19E/13E via SCR switches 2 x 2 x 6 user bands
I don't read PM -> if you have something to ask or to report, do it in the forum so others can benefit. I don't take freelance jobs.
Ik lees geen PM -> als je iets te vragen of te melden hebt, doe het op het forum, zodat anderen er ook wat aan hebben.


Re: merge requests for PLi's git #648 zakalibit

  • Senior Member
  • 51 posts

+5
Neutral

Posted 15 September 2014 - 18:26

Hi,

 

again something for httpsream, I found that not all redirect codes are handled, just 302, I came across at least one service returning 301 which is a valid redirect code so could we change 

if (statuscode == 302 && strncasecmp(linebuf, "location: ", 10) == 0)

as per rfc to 

if ((statuscode==301 || statuscode==302 || statuscode==303 || statuscode==307 || statuscode==308) && strncasecmp(linebuf, "location: ", 10) == 0)

Edited by zakalibit, 15 September 2014 - 18:27.


Re: merge requests for PLi's git #649 Erik Slagter

  • PLi® Core member
  • 46,951 posts

+541
Excellent

Posted 19 September 2014 - 13:31

Applied.


* Wavefrontier T90 with 28E/23E/19E/13E via SCR switches 2 x 2 x 6 user bands
I don't read PM -> if you have something to ask or to report, do it in the forum so others can benefit. I don't take freelance jobs.
Ik lees geen PM -> als je iets te vragen of te melden hebt, doe het op het forum, zodat anderen er ook wat aan hebben.


Re: merge requests for PLi's git #650 lonas

  • Member
  • 1 posts

0
Neutral

Posted 27 September 2014 - 03:14

Here it is.

 

Please!! have available package opera-hbbtv_20140725_0.tar.gz ???



Re: merge requests for PLi's git #651 Taapat

  • PLi® Core member
  • 2,343 posts

+120
Excellent

Posted 28 September 2014 - 21:34

I see that in AudioSelection have added translation for languages​​, but the same is needed for subtitles.

Attached Files



Re: merge requests for PLi's git #652 Taapat

  • PLi® Core member
  • 2,343 posts

+120
Excellent

Posted 14 October 2014 - 19:47

If we try python speed test we can see that if we use 'is' instead of '==', then we can get 2 times higher speed:

python -mtimeit -s 'a="tututu"' 'if a == "tatata": b=a'
1000000 loops, best of 3: 1.88 usec per loop

python -mtimeit -s 'a="tututu"' 'if a is "tatata": b=a'
1000000 loops, best of 3: 0.952 usec per loop

Of course 'is' not the same as '==', 'is' we can use only if the parameters are identical, and not use if equal is their values.
I have not had time to check all enigma2 python source code, but here are 3 patch in which I've changed in some Components, Converters and Screens '==' to 'is' and '!=' to 'is not' for better performance.



Re: merge requests for PLi's git #653 littlesat

  • PLi® Core member
  • 56,270 posts

+691
Excellent

Posted 14 October 2014 - 22:56

Also when it is running from pyo files, like enigma 2 does....

Edited by littlesat, 14 October 2014 - 22:57.

WaveFrontier 28.2E | 23.5E | 19.2E | 16E | 13E | 10/9E | 7E | 5E | 1W | 4/5W | 15W


Re: merge requests for PLi's git #654 Taapat

  • PLi® Core member
  • 2,343 posts

+120
Excellent

Posted 15 October 2014 - 07:40

Of course I am no python expert, but do you want to say that running compiled files python using other methods, and performances will not be?



Re: merge requests for PLi's git #655 Erik Slagter

  • PLi® Core member
  • 46,951 posts

+541
Excellent

Posted 15 October 2014 - 12:35

Time to try I guess...


* Wavefrontier T90 with 28E/23E/19E/13E via SCR switches 2 x 2 x 6 user bands
I don't read PM -> if you have something to ask or to report, do it in the forum so others can benefit. I don't take freelance jobs.
Ik lees geen PM -> als je iets te vragen of te melden hebt, doe het op het forum, zodat anderen er ook wat aan hebben.


Re: merge requests for PLi's git #656 Taapat

  • PLi® Core member
  • 2,343 posts

+120
Excellent

Posted 15 October 2014 - 18:41

Time to try I guess...

 

Ok, create two files and compile them.

test1.py:

def Test():
  a = "tatata"
  for x in range(1000000):
    if a == "tututu":
      b = a
test = Test()

test2.py

def Test():
  a = "tatata"
  for x in range(1000000):
    if a is "tututu":
      b = a
test = Test()

Then run the test:

spark:~# time python /usr/test1.pyo
real    0m 3.44s
user    0m 2.84s
sys     0m 0.38s
spark:~# time python /usr/test2.pyo
real    0m 2.95s
user    0m 2.38s
sys     0m 0.37s


Re: merge requests for PLi's git #657 addybo

  • Senior Member
  • 45 posts

0
Neutral

Posted 15 October 2014 - 18:49

did you test the output?

 

because if i use "is" , it is not working

 

 

maybe this is reason, it works faster....



Re: merge requests for PLi's git #658 littlesat

  • PLi® Core member
  • 56,270 posts

+691
Excellent

Posted 15 October 2014 - 21:01

Do you have some reference from the www why is is better performing than ==?....

WaveFrontier 28.2E | 23.5E | 19.2E | 16E | 13E | 10/9E | 7E | 5E | 1W | 4/5W | 15W


Re: merge requests for PLi's git #659 tension

  • Senior Member
  • 117 posts

+4
Neutral

Posted 15 October 2014 - 22:02

Of course 'is' not the same as '==', 'is' we can use only if the parameters are identical, and not use if equal is their values

 

the answer is in the question, so errors in the patches

>>> a="DVB-C"
>>> b="DVB-C"
>>> id(a)
140602432801120
>>> id(b)
140602432801216
>>> a is b
False
>>> a == b
True
>>>


Re: merge requests for PLi's git #660 Taapat

  • PLi® Core member
  • 2,343 posts

+120
Excellent

Posted 15 October 2014 - 23:36

Do you have some reference from the www why is is better performing than ==?....

I am too lazy to search, but I think that the answer can be seen in the tension example.
Python do not need to get real value to compare, for example, he can use the id, and therefore work faster.
 

the answer is in the question, so errors in the patches

Therefore, I tried to change only for those variables, which are assigned a value, which compares them later. For example:

self.type = EPG_TYPE_MULTI
...
if self.type is EPG_TYPE_MULTI:

But perhaps I have something changed too much :( .




1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users