Jump to content


Photo

Changes in ServiceName


  • Please log in to reply
60 replies to this topic

Re: Changes in ServiceName #21 Taapat

  • PLi® Core member
  • 2,343 posts

+120
Excellent

Posted 20 March 2015 - 15:49

And one more thing, now we do not need in ServiceName self.mode staff: http://sourceforge.n...viceName.py#l16

self.mode = ""
  if ';' in type:
   type, self.mode = type.split(';')


Re: Changes in ServiceName #22 littlesat

  • PLi® Core member
  • 56,273 posts

+691
Excellent

Posted 20 March 2015 - 16:37

I already discovered that by myself... ;)


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


Re: Changes in ServiceName #23 Taapat

  • PLi® Core member
  • 2,343 posts

+120
Excellent

Posted 20 March 2015 - 17:43

And one more thing  :).

I think that we do not need to use the split(";") on TransponderInfo init.
If the converter remains as it is now, then using the "in self.type" we can get InRootOnly, NoRoot and detailed_satpos from self.type without split.
Using the split we just on every init unnecessarily spend time and resources.



Re: Changes in ServiceName #24 Taapat

  • PLi® Core member
  • 2,343 posts

+120
Excellent

Posted 20 March 2015 - 18:23

And I want to ask.
Is there a possibility that you could add def getProviderName from ServiceName2? https://github.com/O...ceName2.py#L126
I am using a provider in the channel list to display it picon. It is the last for how I use ServiceName2 in my skin.
Maybe that the code can be written better. I do not like the two loops for provider and service, but maybe I am wrong and this is the best that can be. And of course import from Screens.ChannelSelection should be used at the beginning of the file.

 

I would be very glad if you add it, and I could refuse ServiceName2.


Edited by Taapat, 20 March 2015 - 18:25.


Re: Changes in ServiceName #25 littlesat

  • PLi® Core member
  • 56,273 posts

+691
Excellent

Posted 20 March 2015 - 23:02

Sure that can be done...
The split is in a cosmetic way required... You can do no root and detailed sat position together.... At leasf the split defines a nice ; split ant the compares with in do check full strings...

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


Re: Changes in ServiceName #26 Taapat

  • PLi® Core member
  • 2,343 posts

+120
Excellent

Posted 21 March 2015 - 10:09

Yes of course, split defines a nice ; split, but without it would be a lot more flexible. That, without some kind of problems, allowing the user to make a mistakes in split symbols, or not use them at all.
But maybe I am wrong, and need strict order in specifying what need to do.

 

And what about the second question about provider in the service list?


Edited by Taapat, 21 March 2015 - 10:11.


Re: Changes in ServiceName #27 littlesat

  • PLi® Core member
  • 56,273 posts

+691
Excellent

Posted 21 March 2015 - 11:05

Af this place it doen not make problems... But for Some tags it may give issues.. The split is there for a structural reason...

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


Re: Changes in ServiceName #28 ims

  • PLi® Core member
  • 13,624 posts

+212
Excellent

Posted 21 March 2015 - 11:48

And I want to ask.
Is there a possibility that you could add def getProviderName from ServiceName2? https://github.com/O...ceName2.py#L126
I am using a provider in the channel list to display it picon. It is the last for how I use ServiceName2 in my skin.
Maybe that the code can be written better. I do not like the two loops for provider and service, but maybe I am wrong and this is the best that can be. And of course import from Screens.ChannelSelection should be used at the beginning of the file.

 

I would be very glad if you add it, and I could refuse ServiceName2.

 

add this into channel selection - it display picons

    <widget source="ServiceEvent" render="Picon" position="30,525" size="100,60" alphatest="blend" backgroundColor="secondBG" transparent="1" zPosition="1">
      <convert type="ServiceName">Reference</convert>
    </widget>

Kdo nic nedělá, nic nezkazí!

Re: Changes in ServiceName #29 Taapat

  • PLi® Core member
  • 2,343 posts

+120
Excellent

Posted 21 March 2015 - 17:39

@ims please read carefully. I'm talking about provider picon.



Re: Changes in ServiceName #30 littlesat

  • PLi® Core member
  • 56,273 posts

+691
Excellent

Posted 21 March 2015 - 18:07

Then give us a patch....


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


Re: Changes in ServiceName #31 Taapat

  • PLi® Core member
  • 2,343 posts

+120
Excellent

Posted 21 March 2015 - 18:35

Then give us a patch....

Attached Files



Re: Changes in ServiceName #32 littlesat

  • PLi® Core member
  • 56,273 posts

+691
Excellent

Posted 21 March 2015 - 19:41

Why do we need to add such a complicated extra function....? I suggest that could be made less complicated....


Edited by littlesat, 21 March 2015 - 19:44.

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


Re: Changes in ServiceName #33 Taapat

  • PLi® Core member
  • 2,343 posts

+120
Excellent

Posted 21 March 2015 - 20:18

As I wrote above:

Maybe that the code can be written better. I do not like the two loops for provider and service, but maybe I am wrong and this is the best that can be.

 

If you have ideas for how to do less complicated, it would be very good.


Edited by Taapat, 21 March 2015 - 20:20.


Re: Changes in ServiceName #34 littlesat

  • PLi® Core member
  • 56,273 posts

+691
Excellent

Posted 21 March 2015 - 20:28

If I had time I already fixed it ;)... but I still do not understand why this is required... you can get the provider name?


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


Re: Changes in ServiceName #35 Taapat

  • PLi® Core member
  • 2,343 posts

+120
Excellent

Posted 21 March 2015 - 20:32

Yes, with the following code I can get the provider name in channel selection.



Re: Changes in ServiceName #36 littlesat

  • PLi® Core member
  • 56,273 posts

+691
Excellent

Posted 22 March 2015 - 00:02

But then this suggested patch is completely not required at all...

Edited by littlesat, 22 March 2015 - 00:02.

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


Re: Changes in ServiceName #37 Taapat

  • PLi® Core member
  • 2,343 posts

+120
Excellent

Posted 22 March 2015 - 09:36

Why is not required? In channel selection info comes from self.source.info and therefore with info.getInfoString(iServiceInformation.sProvider) can't get the provider name.



Re: Changes in ServiceName #38 ims

  • PLi® Core member
  • 13,624 posts

+212
Excellent

Posted 22 March 2015 - 12:44

@littlesat - Provider's Name is available for current played service only. But for all others services in channelselection list this info does not exist and must be parsed from "lamedb". Time expensive.

I am creating for my plugin list[(ref, provider)] from lamedb for getting this names on plugin's start...  then is for me faster to get provider's names in plugin... But it is plugin.

 

May be - to make in .cpp some for get providers name for service reference


Kdo nic nedělá, nic nezkazí!

Re: Changes in ServiceName #39 littlesat

  • PLi® Core member
  • 56,273 posts

+691
Excellent

Posted 22 March 2015 - 14:32

then you also could get an incorrect provider as far I see... This is really rubish... ;)....

Then it is better to simply assign a picon to a user bouquet list... No double loops required...


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


Re: Changes in ServiceName #40 Taapat

  • PLi® Core member
  • 2,343 posts

+120
Excellent

Posted 22 March 2015 - 17:41

Why do you think that could get an incorrect provider? Channel id is unique.
Of course it is time expensive, therefore I wrote that I do not like this code.
Make in .cpp get some for providers name for service reference would be much better.

And assign a picon to a user bouquet list does not work if in one bouquet (e.g. sports) are channels from different providers.




1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users