101 replies to this topic

[littlesat]

In the list you can see the number... but once you select such stream service on the OSD infobar you see "---" instead of a number. Zapping to the number is still OK....

[ims]

put there your streams line from bouquet, please, i will try it with. For my streams it works.

[macnuts]

The latest changes to the ChannelNumber.py (http://openpli.git.s...1e669fc42227246) breaks alternative channel lists numberings.

I have a single bouquet configuration, with multiple alternative channel lists in it (among regular channels, of course). Some of them have channels with the same name, others have channels with different names (different spacing most of the time).

With latest changes to the ChannelNumber.py I never get a channel number when I select the "alternatives element" from bouquet list. It used to work before changes (I got the alternatives list position as the channel number). Now it is always "---".

Maybe it is not a problem with ChannelNumber.py but a general problem how enigma2 handles alternatives channel list handling. The streaming via web of the alternatives do not work either. But that is stated in another thread.

Edited by macnuts, 24 July 2012 - 10:04.

[ims]

I think, that this number before was not same numbers as numbers in bouquet.

Edited by ims, 24 July 2012 - 10:05.

[littlesat]

In fact enigma2 is not designed to not have channelnumber at all... That is the biggest issue here...

It can be suggested that I have to revert the commit from Ims... which was still done based on a good idea (having the numbering on service reference).

services = serviceHandler.list(eServiceReference('1:7:1:0:0:0:0:0:0:0:(type == 1) || (type == 17) || (type == 195) || (type == 25) FROM BOUQUET "bouquets.tv" ORDER BY bouquet'))

Regards the not numbering on the OSD from streams is likelu caused that the type for streams (4097) is not included here....

Edited by littlesat, 24 July 2012 - 10:11.

[ims]

but in this cases there will be numbers and not "---", but this numbers will be nonsence, imho. What is better ?

[littlesat]

Sorry I'm lost....

[ims]

when will be numbering on service name, yes, then there will be numbers and not "---", but this numbers are nonsence. Then it is number of first founded equality, not true number for this service in bouquet.
Numbering on service reference is less wrong, imho

[littlesat]

Numbering on service reference is less wrong, imho

I fully agree....

alternative channel lists numberings.

What is this?

Edited by littlesat, 24 July 2012 - 10:24.

[ims]

I never used alternative service...

[littlesat]

So do I....

but probable due to side effects the orriginal creator of the numbering python code desided to use the channel Name....

Edited by littlesat, 24 July 2012 - 10:28.

[macnuts]

Alternative channel list, as I understand it (and use it that way):

a kind of "sub-bouquet" that is treated as single entity (single channel). That "sub-bouquet" is supposed to contain the same channel but from different providers. I have the DM8000 with 2xDVBS2 + 1xDVBT. There are 3 multiplexes in DVBT, so having single DVBT card, I created alternative channel list for all the DVBT channels that contains the corresponding DVBS(2) "copies" of them. As the DVBT copy is of better quality here, I have configured in settings the preffered order "DVBT/DVBS/DVBC". And it all works like a charm (except channel numbering):

When I zap to the alternatives channel list, I got the service from DVBT. When some recording starts of another alternatives list, it is recorded from DVBS (if DVBT "primary" entry is on different multiplex).

Regards.

[Rob van der Does]

'Alternative channels' will be used by the box if the channel you zap to is not available (and an alternative has been created).

[Robinson]

Bouquet 1: 1.Channel A, 2.Channel B, 3.Channel C
Bouquet 2: 4.Channel D, 5.Channel E, 6.Channel F
Bouquet 3: 7.Channel G, 8.Channel E, 9.Channel H
Bouquet 4: 10.Channel I, 11.Channel J, 12.Channel H

If I am flicking through Bouquet 3, instead of seeing channel number 8, I see number 5, and if I am flicking through Bouquet 4, instead of seeing channel number 12, I see number 9.

Do I understand correctly that this problem has been fixed in the latest builds?

[macnuts]

Latest changes did somthing wrong to channel numbering, unfortunately.

Standard zipping works ok, but when I use the [<<] and [>>] on my DM8000 remote to zap through the "last seen services history", the channel numbers are "shifted" like in the example:
([x] -> #a, #b; where [x] is a remote button to press, the #a is the channel number on OSD and #b is channel number being played actually)
[1] -> #1, #1, OK
[2] -> #2, #2, OK
[3] -> #3, #3, OK
[<<] -> #3, #2, WRONG (should be #2, #2)
[<<] -> #2, #1, WRONG (should be #1, #1)
[>>] -> #1, #2, WRONG (should be #2, #2)

The code I use is up to http://openpli.git.s...d8441773196520c (latest as of writing).

Regards.

[littlesat]

I didn't notice that yesterday. I'll look into this one later...

But I'm scared this will possibly not be an easy fix... as I guess the playlist selected is likely the history playlist......

But it also looks like something is not upgraded probably.... and the numbers are one behind.

Could you try for me without the when event checks?? (remove these four lines)

This gets really mad.....!!!

hopefully you can help me to debug this one....

from Components.VariableText import VariableText
from enigma import eLabel, eServiceCenter, iPlayableService
from Renderer import Renderer
from Screens.InfoBar import InfoBar
firstChannelNumberClass = True
text = ""
class ChannelNumber(Renderer, VariableText):
def __init__(self):
  Renderer.__init__(self)
  VariableText.__init__(self)
  self.text = "---"
  global firstChannelNumberClass
  self.firstChannelNumberClass  = firstChannelNumberClass
  firstChannelNumberClass  = False
GUI_WIDGET = eLabel
def changed(self, what):
  global text
- if what[0] != self.CHANGED_SPECIFIC:
-  return
- if what[1] != iPlayableService.evStart:
-  return
  if not self.firstChannelNumberClass:
   self.text = text
   return
  self.text = "---"
  service = self.source.service
  if service and service.info():
   serviceHandler = eServiceCenter.getInstance()
   CurrentServiceList = InfoBar.instance.servicelist
   root = CurrentServiceList.servicelist.getRoot()
   if 'userbouquet.' in root.toCompareString():
	services = serviceHandler.list(root)
	channels = services and services.getContent("SN", True)
	channelIndex = CurrentServiceList.servicelist.l.lookupService(CurrentServiceList.servicelist.getCurrent())
	markersCounter = 0
	for i in range(channelIndex):
	 if channels[i][0].startswith("1:64:"):
	  markersCounter = markersCounter + 1
	self.text = str(CurrentServiceList.getBouquetNumOffset(root)+channelIndex+1-markersCounter)
  text = self.text

Edited by littlesat, 26 July 2012 - 12:46.

[macnuts]

Commenting those 4 lines did the trick in some way (see next paragraph). I do not know what side effects it may introduce. The alternative channels numbering is working.

Some elements on infobar are updated with small delay on infobar during zap operation (SD, HD, TXT icons, etc.). Now, the channel number update is also delayed, but only when zapping using the "history zap buttons". No delay on direct channel zapping (by number or next/prev).

Regards.

[macnuts]

...
But I'm scared this will possibly not be an easy fix... as I guess the playlist selected is likely the history playlist......
...

You mean that the numbers displayed when zipping with "history zap buttons" are from some kind of temporary history playlist with items numbered with the order# as they were zapped? Well, it may look from my example but it is not so, it just follows the "one behind" pattern. (The sequence in example was 1,2,3; for "1 -> 12 -> 55 -> 3" you get << 3 << 55 << 12 instead of << 55 << 12 << 1).

Regards.

Edited by macnuts, 26 July 2012 - 14:04.

[littlesat]

The side effect is that it might be slower.... I have to debug this one... Somehow during history zap the trigger that a new channel is zapped becomes later or so....

When you put e.g.

print "--------------------------------------------------------------------------->",when

after e.g. the row with global text and run enigma2 via the console (telnet/putty/ssh) after a init 4 then you could help me with debugging... What do you see then? Probably I have to find a better "trigger" type to start calculating the zap number....

I tried to avoid that it was calculated several times per zap.... as this is waste of resources...

Edited by littlesat, 26 July 2012 - 14:04.

[littlesat]

Probably replacing the raw with the what[1] by

if what[1] != iPlayableService.evStart and if what[1] != iPlayableService.evEnd:

might help also... (just by head)

of not what[1] in (iPlayableService.evStart, iPlayableService.evEnd):

But still this needs to be debugged....

Edited by littlesat, 26 July 2012 - 14:15.