merge requests for PLi's git
Re: merge requests for PLi's git #641
Re: merge requests for PLi's git #642
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....
Re: merge requests for PLi's git #643
Posted 9 September 2014 - 14:47
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.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.
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
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
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
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....
Re: merge requests for PLi's git #647
Posted 11 September 2014 - 15:10
* 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
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
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
Re: merge requests for PLi's git #651
Re: merge requests for PLi's git #652
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.
Attached Files
Re: merge requests for PLi's git #653
Re: merge requests for PLi's git #654
Re: merge requests for PLi's git #655
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
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
Re: merge requests for PLi's git #658
Re: merge requests for PLi's git #659
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
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 .
6 user(s) are reading this topic
0 members, 6 guests, 0 anonymous users