Yes , I stick like gum.
On 1 to 5, no I did not read the information you referred to on the sqlite site because it gives here a : Error code: SSL_ERROR_RX_RECORD_TOO_LONG" error. Looking at the short version on duckduckgo:
Quote
The VACUUM command rebuilds the database file, repacking it into a minimal amount of disk space. There are several reasons an application might do this: Unless SQLite is running in "auto_vacuum=FULL" mode, when a large amount of data is deleted from the database file it leaves behind empty space, or "free" database pages
On 6, a journal of the data being retrieved on zapping:
Sep 06 08:58:53 dm920 enigma2[350]: [EPGC] channel 0x36f6940 running
Sep 06 08:58:53 dm920 enigma2[350]: [EPGC] next update in 2 sec
Sep 06 08:58:55 dm920 enigma2[350]: [EPGC] start caching events(1662447535)
Sep 06 08:58:55 dm920 enigma2[350]: [EPGC] 5274 0c99 0003 00eb0000 has external data! won't update...
Sep 06 08:58:55 dm920 enigma2[350]: [EPGC] 17d1 0c82 0003 00eb0000 has external data! won't update...
.
.
Sep 06 08:58:58 dm920 enigma2[350]: [EPGC] 5287 0c96 0003 00eb0000 has external data! won't update...
Sep 06 08:58:58 dm920 enigma2[350]: [EPGC] 52ec 0c96 0003 00eb0000 has external data! won't update...
Sep 06 08:59:05 dm920 enigma2[350]: [EPGC] nownext finished(1662447545)
Sep 06 09:00:32 dm920 enigma2[350]: [EPGC] schedule finished(1662447632)
Sep 06 09:00:32 dm920 enigma2[350]: [EPGC] schedule other finished(1662447632)
Sep 06 09:00:32 dm920 enigma2[350]: [EPGC] stop caching events(1662447632)
Sep 06 09:00:32 dm920 enigma2[350]: [EPGC] next update in 60 min
Sep 06 09:00:35 dm920 enigma2[350]: [EPGC] cleanup invalid data
Sep 06 09:00:35 dm920 enigma2[350]: [EPGC] cleanupOutdated
Starts caching the events and does not update the events that are already in database in RAM. Nownext is always updated and overwrites the short description of the EPG but, so only on the screen not in the database. If you zap forward and back you will see again the short description from the EPG database and a few seconds later the short nownext description is overwritten again on on the screen.
There is no need to vacuum the database as long it is in RAM because it is fast enough to handle all. When writing back to disc it writes a clean database, which is ready to be imported again.
On EPGimport the database on disc is being used to insert/update events. Now most likely, you do a import after vacuum to clean out the obsolete events that are replaced by updated events and maybe you also remove outdated events keeping the events defined by: config.misc.epgcache_outdated_timespan=hours
Vacuum reduces then size of file on disk and that smaller epg.dat file is then loaded into RAM to be used. When the box is restarted or shutdown then a new optimized epg.dat file is overwriting the previous version.
The epg.dat file on disc is renamed, not erased when the EPG from RAM is saved. When the box crashes before restart/shutdown the epg.dat file is still on disc and on start it will be used to fill the EPG in RAM. This way you don't loose EPG data except for the EPG data that is in RAM. This because it is not written back to disk.
Above is general description how the EPG works and I updated that with the vacuum you are now doing. The EPG working is simple on the outside and works very well since a long time.
If you want, please correct any errors I made and add what I forgot. This could be used as a general bit of information for users who want to know how EPG is handled.
Looking forward to the EPGImport version so I test it also.