101 replies to this topic

[macnuts]

I will report on this soon...

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

[littlesat]

Try to debug yourself... that is what we should promote Today and tomorrow I'm limited....

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

[macnuts]

I meant that (to debug myself). Sorry for my English...

[littlesat]

Thanks!

[littlesat]

I found it... in fact it was a bug somewhere else...

http://openpli.git.s...03f60c10bb546aa

Edited by littlesat, 26 July 2012 - 18:50.

[macnuts]

Your latest commit fixes the problem.

Nevertheless, you can find enclosed the enigma2 output, as it is already ready. You may find in helpful maybe (with other stuff).
Search for [macnuts] inside. Just for reference, the initial channel was #3 at 19:57, then I zipped to #2 at 19:58, #9 @ 19:59, #10 @ 20:00. Then back to #9 at 20:01, #2 at 20:02, #3 at20:03.

Regards.
 enigma2.out.txt   168.25KB   3 downloads

[littlesat]

....

[macnuts]

...

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

...
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
...

It works well even with those lines present.

Good work!
Regards.

[littlesat]

These lines could indeed be put back.... they avoid that for each event the channel number is determained and are there just to save resources...

[macnuts]

I found two more issues with channel numbering.

1. Zap timer.
When the zap timer executes and the channel is switch to another one (instead of being recorded as with regular timers) then the channel number remains not changed. Even when the infobar is displayed again, the channel number is wrong. Moreover, using the navigation keys on the remote, zaps to the next/previous channel of the wrong channel number, not the channel being displayed.
Example: Set timer to zip to channel# 10. The zip timer triggers while watching channel# 15. The infobar displays #15. Dismiss the infobar and display it again. Still #15. Navigation keys zap to #14/16 not 9/11.

2. PiP
The same behavior as above in the following scenario (and only in this scenario):
- In settings, set the [0] button to move PiP into main window
- Activate PiP, set zapping to PiP, zap PiP to another channel using the numerical keys of the remote, press [0] to move the PiP into main window. The infobar will display the channel# of the active channel previously, not the new active one from PiP.

Regards.

[ims]

I think, there is little bug:

try with LEFT switch over several channels and then go back with History. You will see, that on first step is not made channelnumber=channelnumber-1 and then all numbers are n+1.

[macnuts]

Have you applied http://openpli.git.s...03f60c10bb546aa by hand? I do not think it is in the feed yet. This fixes the n+1 problem.

[littlesat]

I found two more issues with channel numbering.

1. Zap timer.
When the zap timer executes and the channel is switch to another one (instead of being recorded as with regular timers) then the channel number remains not changed. Even when the infobar is displayed again, the channel number is wrong. Moreover, using the navigation keys on the remote, zaps to the next/previous channel of the wrong channel number, not the channel being displayed.
Example: Set timer to zip to channel# 10. The zip timer triggers while watching channel# 15. The infobar displays #15. Dismiss the infobar and display it again. Still #15. Navigation keys zap to #14/16 not 9/11.

2. PiP
The same behavior as above in the following scenario (and only in this scenario):
- In settings, set the [0] button to move PiP into main window
- Activate PiP, set zapping to PiP, zap PiP to another channel using the numerical keys of the remote, press [0] to move the PiP into main window. The infobar will display the channel# of the active channel previously, not the new active one from PiP.

This could be the same issue as I did with the fix with the history...

What a maddness...

Edited by littlesat, 26 July 2012 - 23:02.

[littlesat]

The PIP isue I cannot confirm.... The infobar gives the correct info for the mainscreen

Edited by littlesat, 26 July 2012 - 23:16.

[macnuts]

The PiP error can be reproduced in one scenario only (which happens to be my favorite way of using PiP).

Here is how to reproduce:
1. Tune to any channel, let's say #9.
2. Press [blue][blue] to activate PiP.
3. Press [blue][red] to switch zapping to PiP.
4. Press [5][OK] to switch PiP to channel #5 (Use numerical keyboard, using left/right to navigate PiP does not always produce error in step 5).
5. Press [0] to move PiP to main view (and close the PiP). You will see that infobar shows channel# 9, not 5.

For 5 to work, the [0] behavior must be set in settings to "move PiP to main view" (or similar wording).

After step 5, pressing left/right navigation keys switches the channels and their numbers correctly to #4/#6 respectively, which is different from zap timer error.

Regards.

[macnuts]

Your latest commits correct both problems. Great work!

Moreover, it corrects one more problem which was present "from the begining" (April 2010): after the zap timer was triggered, when you press top/bottom to open boquet list, the item position was not updated to the new active channel. Now it is.

There is still one issue, that zap timer does not update history (history navigation keys work as if no zapping had occured). But it is not a channel number problem discussed here.

Again, great work and thank you.
Regards.

[littlesat]

That I did correct more stuff now that was what I already was scared of... As I suggest this was a bug that was in E2 for a longer time...

here is still one issue, that zap timer does not update history (history navigation keys work as if no zapping had occured). But it is not a channel number problem discussed here.

It can also be a feature not to add a channel selected by a timer to the history....

Edited by littlesat, 27 July 2012 - 08:44.

[macnuts]

here is still one issue, that zap timer does not update history (history navigation keys work as if no zapping had occured). But it is not a channel number problem discussed here.

It can also be a feature not to add a channel selected by a timer to the history....

You now it better probably (zap timer usage scenarios), but I can hardly imagine how:
One sets the zap timer not to miss the important show/movie/sport event, etc. After the zap, one can enjoy that he/she did not miss the event. But then, after some time the commercials come. One decides to switch to another channel. After some time he/she wants to return to the event (with back button) but the history buttons do not work (or, to be precise, they work perfectly but history has no track of that channel).

For me, the most convenient way is to have all active channels in history, regardless how they became active. But it is me, others can prefer the opposite.

Regards.

Edited by macnuts, 27 July 2012 - 09:29.

[littlesat]

I thing that plugin should be fixed. It should activily call addToHistory - or at least call zap in ChannelSelection class. Do we have access to the sources of that plugin? I suggest this plugin did not add it's zaps to the history already for years!!!

Regards zapping for the normal timer I see also that it is most likely possible to add these zaps also to the history... In addition to set the channel refrence correctly in the servicelist just before it is played I'm also able to add it to the history...

Edited by littlesat, 27 July 2012 - 10:21.

[macnuts]

The code is in /usr/lib/enigma2/python/RecordTimer.py, about line# 301

I tried to check the code, and also think that the zap of ChannelSelection class would be best to use. But I do not know enigma2 that well, I do not know what is the impact when Zap timer switches to channel in another bouquet (fav. list etc.).

Edited by macnuts, 27 July 2012 - 11:45.