Ich bekomme die folgende Meldungen wenn ich eine andere liste einlesen nach einander. Die erste geht aber die zweite nicht obwohl die vorige import fertig is. Die epg.db-journal wird dann noch immer geschrieben. Wichtig ist es nicht weil import nicht addiert aber 'excludes' existing events.

Jan 01 17:10:07 dm7080 enigma2[1583]: [EPGImport] ### importEvents exception: database is locked
Jan 01 17:10:07 dm7080 enigma2[1583]: [EPGImport] ### importEvents exception: database is locked
Jan 01 17:10:07 dm7080 enigma2[1583]: [EPGImport] ### importEvents exception: database is locked
Jan 01 17:10:07 dm7080 enigma2[1583]: [EPGImport] updating status ...[EPGImport] ### importEvents exception:
Jan 01 17:10:07 dm7080 enigma2[1583]: [EPGImport] ### importEvents exception: database is locked
Jan 01 17:10:07 dm7080 enigma2[1583]: [EPGImport] ### importEvents exception: database is locked
Jan 01 17:10:07 dm7080 enigma2[1583]: [EPGImport] ### importEvents exception: database is locked

Ich finde es noch immer das beste um erst eine leere epg.db, wann es möglich, ist ein zu lesen und dann die import zu tun. Meine bestehende epg.db ist uber 100MB und wenn ich 2000 events einlese 300KB dan habe ich noch immer ein egd.db die über 100MB ist.

Ich werde es wieder probieren mit vacuum ob die nun wohl packt.

Eine Wunsch vom mir ist um von 'External Data' (99) nach 'Internal Data' (0) zu gehen so dass EPGC auch die cache events kann aktualisieren in die vom XMLTV geladene EPG events.

Im EPGImport.py Bigstorage umgehen und nur '/tmp' benutzen um der ort wo die XMLTV bestanden geschrieben werden. Spart die zeit die das anlaufen der Harddisk aus.

def do_download(self,sourcefile):
		path = '/tmp'
		filename = os.path.join(path, 'epgimport')
		if sourcefile.endswith('.gz'):
			filename += '.gz'
		sourcefile = sourcefile.encode('utf-8')
		print>>log, "[EPGImport] Downloading: " + sourcefile + " to local path: " + filename
		downloadPage(sourcefile, filename).addCallbacks(self.afterDownload, self.downloadFail, callbackArgs=(filename,True))
		return filename

'Indexing' muss ich mich noch ansehen und auf meinen plus 100 MB EPG habe ich es abgebrochen weil es sehr lange dauerte.

Ich muss auch ausfinden warum die epg.db immer mit 162KB zunimmt ob woll es keine neue Daten sind beim einlesen.

Gelukkig nieuwjaar!!

Nach eine ruhe in letzten Jahr geht es weiter und danke Gutemine für die schnelle stelle Bereitstellung der 2.1-r1 Version.

Wenn die epg.db beim abschießen der Box geschieben wird dauert das lange und entstanden epg.db is bei mit 118MB. Komprimiert wegschreiben der epg.db ist eine Option aber das kostet und ich sehe DMM das nicht schnell tun. Die epg.db wird vom 118MB reduziert auf 28MB.

Ich habe mir die epd.db in sQLite angeschaut und sah das jede Eintrag vom eine "create" datum hat und wen ich die nicht mehr schreibe in die epg.db dann gehe ich vom 118MB nach immer noch 81MB. Und wenn das Datum wichtig ist dann denke ich ist nur einmal wichtig und das ist im T_event oder T_data.

Sicher und I jetzt ruhe ich ganze Jahr und gehe erst nächsten Jahr weiter.

Ich sehe mir gerne die journaling an und habe gerne genauere ausgaben:

# now we go trough all the events for this channel/service_id and add them ...
				self.event_counter = 0
				events = self.events

# increase dvb event ID
                                            self.dvb_event_id += 1
                                            self.events_in_import_range += 1
		                            self.event_counter += 1
                                    else:
                                            self.events_in_past += 1


           print "[EPGDB] added %d from %d events for channel %s" % (self.event_counter, self.events_in_import_range, channel)
           self.EPG_TOTAL_EVENTS += number_of_events

Das erklärt das in die Sender liste nicht immer die EPG event sichtbar waren. Danke für die Anpassung und ich kann es noch spezifischer machen bei die Next/Now time mit die Dauer der Sendung zu addieren.

# now insert into epg.db what we have
		self.end_time = self.begin_time + self.duration
		if self.end_time > self.epoch_time and self.begin_time < self.epg_cutoff_time:

Und dann kann die 4 stunden extra auch entfallen.

Hallo Gutemine, hier knallt es schon und die Raketen fliegen schön durch die Luft und es ist noch nicht einmal 0.00 Uhr.

Also meine erste schritte, "Hello World!!", und ich habe nur die epgdb.py ge-zipt und schließe die bei.

Allen eine gute rutsch in das neue Jahr!! Happy New Year!! Gelukkig nieuwjaar!!

Zitat von gutemine

wenn du die epg.db löscht musst du einmal enigma2 restarten damit sie wieder rausgeschrieben wird, erst dann kann man was hinein laden.

Oder ein zweitem mal laden weil es bleibt gleich.Die output wird noch geben und ich habe auch probiert mit die regeln:

# is it really wise for the small performance gain ?
                #cmd="PRAGMA synchronous = OFF"
                #self.cursor.execute(cmd)
                #cmd="PRAGMA journal_mode = OFF"
                #self.cursor.execute(cmd)

auskommentiert.

@#%&^%#(**^%#))(& und jetzt funkt es gleich. Ich habe die timespan drin und nun noch die andere variable.

Habe ich vor ein einige Stunden probiert und es hat nicht funktioniert so später will ich es nochmal probieren.

Ich habe fremde Feedback von der plug-in.

Kein epg.db anwesend und auf und ich bekomme erst mal ein Fehlermeldung das epg.db nicht besteht und die epg.db wird geschrieben und is dan 23bytes groß und also leer. Danach kann ich importieren aber bekomme keinen output in journalctl -f | grep EPGDB

Dann importiere ich nochmals dasselbe und dann bekomme ich wohl die output.

Kann irgend wo die config variablen suchen und ich dachte die die Namensgebung gleich war als in enigma.py aber das ist sie nicht.

Hahahaha was denkt ihr, ich habe noch nicht einmal "Hello World!!" in Python programmiert und dann gleich eine Plug-in beibehalten......Enigma ist fur mich noch echt ein Enigma.

Gutes denken vom dir und jetzt is das Enigma die EPGImport umgab, gelöst!!!!

Mit r27 geht es jetzt und ich habe eine gute EPG auf UK.

Ich filtere die EPG events die nicht im definierten Zeitbereich liegen aus:

Zitat

# keep events older than one hour as it is now
self.epoch_time = int(time.time())-3600
# one day cut-off and don't import events beyond that
self.epg_cutoff_time=int(time.time())+(1*24*60*60)
self.events_in_past = 0
self.events_in_import_range = 0

Zitat

# now insert into epg.db what we have
if self.begin_time > self.epoch_time and self.begin_time < self.epg_cutoff_time:

Zitat

## increase dvb event ID
self.dvb_event_id += 1
self.events_in_import_range += 1
else:
self.events_in_past += 1

Zitat

def final_process(self):
print "[EPGDB] importing finished with total available %d, events imported %d, not in range %d" % (self.EPG_TOTAL_EVENTS, self.events_in_import_range, self.events_in_past)

,
Frage, wie kann ich die variablen einlesen vom Enigma(.py) fur "EPG cache time span" und Keep outdated EPG (in hours)"?

Zitat von gutemine

Ich habe noch den Bug mit den gelegentlichen getitem exceptions gefixed, anbei ist eine r25 wo der Fix dafür drinnen ist.

Dda wird jetzt auch der Inhalt der T_Service Tabelle beim laden weggeworfen, weil falls ihr ständig Quellen wechselt beim Testen macht das Sinn, sonst sind Sender als extern versorg angelegt, die dann gar keine Daten geladen kriegen.

I can't get vacuum line fitted in any more in epgdb.py. I am afraid that there will a lot of fragmentation in time and if all the events are deleted before importing the need of writing big files is not necessary.

update: I just started a new import and the epg.db-journal is small from size....lets see how the total import works out.

I am back on r23 and I have deactivated the total delete section in epgdb.py. I also now only import events that are not in the past. Good news I have now EPG on the UK channels but that I have to test further because it can disappear without any warning.

So my epg.dat wil grow each time I run an import of new events or if I choose I new XMLTV listing to read in.

I get the lock while the file is written out to storage. If there is corruption in the memory then on the next restart the old epg.db is read in.

Hahahaha with this command, cursor.execute('vacuum my_table'), all is vacuumed and I am left with a file of 1.585KB after import one small XMLTV into the BIG epg.dat.

Next is to do it with all the four XMLTV imports and then it should work better.

Update 1:
When the database locks at startup I get this message:

Exception AttributeError: "epgdataclass instance has no attribute 'epg'" in <bound method epgdataclass.__del__ of <Plugins.Extensions.EPGImport.epgdata_importer.epgdataclass instance at 0x2d2d490>> ignored

Update 2:

Run with three XMLTV imports due to that the UK epg is half functional and the filesize is 65.270KB so the vacuuming works. I have only one cursor.execute('vacuum my_table') in there between the last cursor.execute('DELETE FROM... the commit.

Question, on starting import the epg.dat is written again with epg-journal.db and can't we do the import totally in memory en at the end write it out?

I have to do some shopping so it will be evening before I am on-line again.

About cleaning...it would seems to me the best way is for DMM to do it when reading into memory from the epg.db and then ignore all events that are older than now-keep outdated EPG. Keep outdated EPG is in Menu-Setup-System-Customize.
Secondly on erasing events the check if there is one than more events with the same pointers to sub records as title, description, etc so that these are only erased if event is unique....it can become unique if all the past events are erased earlier and this is so last one.

Next time the memory is written out into epg.db it does not contains obsolete events and added are the new events.

I take always a long time to type so I will now restore epg.db and add the cursor.execute("vacuum my_table") .

Zitat von gutemine

Thanks for trying and testing, but only multiple runs with different sources should grill the data of the previous one (but this was the same with the epg.dat if i remember right).

If you run multiple sources in a single import it should work without uncommenting the deletes.

I have good and bad news. The good news is that all events are still there and none are mangled/broken after reboots. EVEN the web interface is now stating complete days, so 31.12.2014 instead of 00.12.2014.

The bad news is that the EPG clean-up does nothing or is so less that I it does not change the file size of the epg.db (113459KB)

Dec 30 13:26:44 dm7080 enigma2[179]: [EPGC] cleanupOutdated
Dec 30 13:27:44 dm7080 enigma2[179]: [EPGC] cleanupOutdated
Dec 30 13:28:44 dm7080 enigma2[179]: [EPGC] cleanupOutdated
Dec 30 13:29:25 dm7080 enigma2[179]: [EPGRefresh] Stopping Timer
Dec 30 13:29:25 dm7080 enigma2[179]: [EPGImport] autostart (1) occured at 1419942565.07
Dec 30 13:29:25 dm7080 enigma2[179]: [EPGImport] Stop
Dec 30 13:29:25 dm7080 enigma2[179]: [EPGC] remove channel 0x2f86310
Dec 30 13:29:25 dm7080 enigma2[179]: [EPGC] db thread stopped
Dec 30 13:29:25 dm7080 enigma2[179]: [EPGC] data thread finished
Dec 30 13:29:25 dm7080 enigma2[179]: [EPGC] Saving database from memory

I had this before and is the EPGC authorised to clean-up events generated by EPGImport (external)?

By The Way (BTW) I had with the r22 a lot of file-locks when starting the import and before I had it only one in more than thirty runs. It seems to run faster and also in the meantime I have reinstated the out-commented line in Navigation.py. Going now to try r23.

Update: running r23 had also a few starting problem due to locked database but finally I could get pass it. I did not commented anything out so the r23 was original. The clean-up took ages due that my epg.dat is over 100MB but finally it was completed.
Sadly the size of the epg.db is still 113.459KB and even worse is that I lost all the events because I only imported one XMLTV instead of the four I normally do. The good news is that I backup-ed it first so I can try again without loosing all the good information.

Will do.

I had broken EPG when I imported a second list or several list at the same time. I had the same behaviour as with the the UK channels and I tried commenting out the start-up deletes in epgdb.py and that works fine.

The UK epg in the web interface I have now times but the day of the date is still zero but that is an bug in the webinterface. I will see if tomorrow all is still good. I leave it up to enigma2 itself to clean-up outdated events.

ps. I did not see your last posting so I will run r22 and look if I can do some python coding.

If you are using this from xmltvconverter.py then it should be go well:

def get_time_utc(timestring, fdateparse):
#print "get_time_utc", timestring, format
try:
values = timestring.split(' ')
tm = fdateparse(values[0])
timegm = calendar.timegm(tm)
#suppose file says +0300 => that means we have to substract 3 hours from localtime to get gmt
timegm -= (3600*int(values[1])/100)
return timegm
except Exception, e:
print "[XMLTVConverter] get_time_utc error:", e
return 0

UTC and GMT are almost the same but UTC ignores summertime so it is a good constant.

Update: I am now back with my DM8000 and the programme starts at 23:00 so I had it wrong.

Like you it seems to me better to wait for DMM to shed some light on it all because I get really inconsistent output the more I look into it. I have now even found wrongly displayed dates and times when browsing in the EPG of the BBC Four HD.

According to the database it should start at 20:00GMT --> 21:00 our time and here is displayed 23:00 our time on the date 0.12.2014 which should be 31.12.2014. Epoch: 1420056000

Thank you so much for all the good work and we will see next year if all things can be ironed out with help of DMM.

Eine gute rutsch im neues Jahr!!

I am running now r21 and I have to wait till it is ready. BTW I always start with an empty epg.db before running an import.