Since the last update of timer.cpp (12 June) there are a couple of lines that do nothing (I think). This may be a mistake, so I bring it to the attention. It is about the following lines:
line 198:
eEPGCache::getInstance()->lookupEvent( ref, time );
line 2413:
eEPGCache::getInstance()->lookupEvent( (eServiceReferenceDVB&)tmpService, newEventBegin+newEventDuration / 2 );
To opinion a value is returned by these calls which is not stored anywhere. Also the values of the parameters will not be changed by this call. Is this a mistake?
tmp = eEPGCache::getInstance()->lookupEvent( bla, bla ) ;
But then the old error with scheduling repeated timer events appeared again. That one was gone since the last update. I must admit that I do not understand why the cache is parsed to get event data
Sat-turner hat geschrieben:
Since the last update of timer.cpp (12 June) there are a couple of lines that do nothing (I think). This may be a mistake, so I bring it to the attention. It is about the following lines:
line 198:
eEPGCache::getInstance()->lookupEvent( ref, time );
line 2413:
eEPGCache::getInstance()->lookupEvent( (eServiceReferenceDVB&)tmpService, newEventBegin+newEventDuration / 2 );
Oh yes.. this is a bug... tmp= eEPGCache::.... is correct..
I fix this in the CVS.. thanks !
Sat-turner hat geschrieben:
But then the old error with scheduling repeated timer events appeared again.
The last update solved a problem, but that will reappear if you just put "tmp =" in front of these lines. If you schedule a repeated timer event in the very near future then the field LAST_ACTIVATION will be filled with a very wrong value, somthing like "10522", although this event has never run. The result is that the event will never run. Here is an outline of timer.log of such an event:
hmm i cannot reproduce the problem with multiple timer and incorrect last activation..
When i add a multiple event.. the last activation is empty until the event has started..
bye
Tonight I did some research in the problem together with Sat-Turner.
The problem that occurs is that there is a union defined in ePlaylistEntry. What happens is that event_id of this union is being changed also when a recurring timer is being programmed. This should not happen.
There are two possible solutions in my opinion.
1. Get rid of the union, what is the use here? (then do initialisation of those vars)
2. Do not change event_id when programming a recurring timer by checking multiple->isChecked()
Do you have any idea why there is chosen to use a union in the ePlaylistEntry struct? Not very usefull in this situation I guess and faillures can be made easlily this way as we saw
A repeated timer don't need a event_id ... the event description must be searched by start_time.
bye
If memory is an issue there are a lot of other things that can save more memory, we're talking about 8 bytes of savings ;-)
I understand that the repeated timer does not need the event_id but the problem is that a mistake is easily being made using a union, therefore in my opinion it is not worth it to use a union here.
