@Scanman,
I think it might need faster GUI components , maybe a way to do GUI updates less frequently.
alternative: the module could just regularly export the EPG data to a file, and GUI could be a seperate exe and it could read the EPG data from that file.
Stuttering, beeing slow or hangups should / could not be a GUI-prob or depending on the EPG itself.
I do collect data as follows in the callback-routine:
- Is GUI 'working' (update / select / delete old data...) ?
- if YES (there's a 'irgnore-data' flag) exit immedeatly to DD !
(no more consideration of incoming data)
- Is date/time + duration older then actual time ?
- if YES (we dont need them) exit immedeatly to DD !
(no more consideration of incoming data)
- Is channel-data already listed in buffer ?
- If NOT, amount memory and copy data and remind pointer to that
+ set a flag 'new ch-data'
- If YES remind pointer to that
- Compare event-ID of incoming data with listed event-IDs of 'actual' channel
(This is a loop - normally i dont have more than 300-400 events per channel !)
(So NOT all events a searched for !)
- event-ID found ?
If YES (we already have it) exit immedeatly to DD !
If NOT, amount memory and copy data
+ set a flag 'new event-data'
- exit to DD
Thats all. As you can see there are only a few steps what the callbach-routine have to do.
IT IS NEVER BLOCKED BY ANY GUI-RELATED FUNCTION !
The buffer is totaly independent from the rest of the programm.
To Display, filter, select, deleted and other things i do it this way:
- Every 500ms a timer set the 'ignore-data' flag first so that the callback isnt block or interfered in any way.
- Now i loop through all channels witheir all events and take a look at the date/time. If older than actual date/time, those events are deleted from buffer. So normally the list / file couldnt rise up to the moon.
- Next is checking the 'new-ch-data' flag. Only if set the ch-list will be updated. Normaly this happens periodicly only after the first minutes you read a new (not yet readed !) channel. After a short while the list normally should not more updated.
!!! I will implementd a routine thats checks if the 'new' channel is in a possible filter-list (from favorites) and so the list doesnt need to be updated. Should reduce 'flipping' on / by non-selected channels.
- Same procedure for event-Data.
All data-handling happen in memory ! Nothing will be written to disk until DD (not the EPG !) is closed.
The file & size:
When i often zap through channels on ASTRA 19.2°/23.5° (europe's most used satellite-family !) i will collect around 300-400 channles within 30.000 - 40.000 events. Not more. Filesize then is around 3.5 to 4.5 MB - depending on available short- and extended description. Not more. This causes a little 'slowdown' less than 2 seconds during start and closing of DD. Not more. That seems to be quite normal. The delay could be read in / from DD's log-file ???
Storing / loding the file:
- Number of channels
- Outer loop for channels:
- some IDs and references
- Provider- and channel-name ONLY IN EFFECTIVE LENGTH ! (not the array-length)
- Innerloop for events per channel:
- some IDs and references
- Name, short- and extended description ONLY IN EFFECTIVE LENGTH ! (not the array-length)
(if no name or description, nothing will saved readed !)
As you can see, i already do something like lightly compression...
When i write the complete array-lengthes, the file (same as mentioned above) rises up to 80 - 110 MB !!! A little bit to big...
If somebody has some more effective ideas - let me know.
