service number
#1
Posted 5 January 2012 - 08:01
Currently in db.h we in loadServicelist we read service_number from lamedb but we never store or use it other than to check if it is set to -1 to skip the service in lamedb.
If we store it then we can let people set service numbers for the whole list, but it would also allows us to add something like #NUMBER to the user bouquets to allow for individual service numbering in bouquets.
Of course this requires a change to InfoBarNumberZap and ChannelNumber renderer, but I think this would allow us to be more flexible with channel numbering and also keep old behaviour and compatibility with userbouquets from other enigma2 releases.
Re: service number #2
Posted 5 January 2012 - 10:26
The servicereference should uniquely identify a service.
By adding a service_number, you could have multiple instances of the same service, with different service_numbers.
This would seriously mess with the dvb hardware allocation in e2.
Having the service type as one of the serviceref fields is causing us enough trouble already, as servicetypes can be wrong, causing duplicates.
Re: service number #3
Re: service number #4
Posted 5 January 2012 - 10:36
Thats what I had in mind, just havnig it set and having a getter method for it.Actually, just adding it to the serviceref, but NOT in the serviceref string (nor in the '==' operator), would be harmless of course.
This would allow us to set a global service number for each serviceref and one for each one in the user bouquets.
This also wouldnt hurt to have in the native c layer with out implementing anything in the python source.
Ofcourse you have a small impact on memory which is n*( size of unsigned short or size of whatever data type ) where n is the number of service reference.
Re: service number #5
Re: service number #6
Re: service number #7
Posted 20 January 2012 - 10:52
Ok, well then for now I will use 2 bytes to store the channel number.no, just check the datatypes which are used to store the channel number.
However, if you look at the logical channel descriptor (used by providers to provide channel numbering), the channel id is only 10 bits...
I have solution for channel numbering, I just need to fix a few things and then I will post it here.
The solution should allow you to keep the current behaviour by default and allow custom numbering.
Re: service number #8
Posted 22 January 2012 - 22:00
Do you know how I can get the service list listbox on the ChannelSelection screen to update?no, just check the datatypes which are used to store the channel number.
However, if you look at the logical channel descriptor (used by providers to provide channel numbering), the channel id is only 10 bits...
The only way I can get it to update is by flushing all changes, this seems to work for when I hard and remove services, but when I move service around the list does not seem to get refreshed. I don't understand were the caching is happening, could you give some help here?
Re: service number #9
Re: service number #10
Posted 23 January 2012 - 11:36
The channel is not refreshed.You mean the channel number is not refreshed, when you move a service around?
Or does the service not move at all?
The way my changes work is that they modify the service reference in the bouquet, but after this it seems the channel is not refreshed.
Re: service number #11
Posted 25 January 2012 - 22:48
basically the current behaviour is kept the same so it starts numbering the channel numbers from 1 and incrementing
If you enter a line in the bouquet file like the one below then the channel number sets that channel to use that number and keeps numbering from that channel number onwards or until it finds another line.
#CHANNEL 120
Right now add and remove service work, but the channel is not correctly numbered, this can be fixed by flushing the changes to the bouquets, but I left this out for now since it does not help to do that when moving services and I would like a general solution for all of them. If anyone has a solution for that please let me know.
Zapping seems to work, and displaying the channel number correctly in the channel list and info bar.
Also channel numbering works more efficiently this way since we don't have to always loop through lists to number the channels.
Attached Files
Re: service number #12
Re: service number #13
Posted 25 January 2012 - 23:07
It first searches the bouquet you are currently on, so if it finds the number in there then it uses that one, otherwise it goes through all your bouquets starting with the first one and picks the first channel with that number.how are channel number conflicts handled?
If a user would for instance place a lower number behind a higher number? (leading to duplicate ranges I guess)
Or if a user simply adds duplicate numbers?
Re: service number #14
Re: service number #15
Posted 30 January 2012 - 19:49
looks like reload bouquets is need to get this to update the list, which works for adding and removing services.ok, this might also be useful for our 'fastscan' or 'cablescan'.
Means we no longer need the 'numbered' markers hack I had to make for those.
Any idea if a different object is created for the service list? I can't seem to track down when the channel number doesn't update other that the list may have a different service object
Re: service number #16
Re: service number #17
Re: service number #18
Posted 7 August 2012 - 15:06
We just revised the complete channel number system.... now without using any 'shadow' database... But not by adding a number field to the services/bouquets that needs to upgraded/updated.
Edited by littlesat, 7 August 2012 - 15:20.
WaveFrontier 28.2E | 23.5E | 19.2E | 16E | 13E | 10/9E | 7E | 5E | 1W | 4/5W | 15W
Re: service number #19
Re: service number #20
8 user(s) are reading this topic
0 members, 8 guests, 0 anonymous users