Beiträge von msatter

    Nun haben wir dem EPG und heute Abend mochte ich etwas suchen in die WebInterface aber ich finde nichts. Es scheint das die such Funktion nur in die titeln sucht und nicht in de Umschreibung/description. Ich danach EpgSearch auch installiert aber die kommt auch nicht weiter.


    Wenn ich die epg.db in SQL suche dann findet der was ich suche.

    Hier geht gut es auf die 7080 aber auf die 8000 bekomme ich die beschriebene Fehlermeldung.


    update: komme gar nicht mehr ins hbbtv ubersicht vom NPO auf die DM8000


    enigma2-hbbtv-plugin - 0.999git20130417-r1.0
    enigma2-plugin-extensions-hbbtv - 3.999git20150105-r9.0

    Ich begreife noch immer nicht diese code snipplet:


    Code
    print "[EPGDB] starting cleaning of events from %s" % (epgdb_path)
    			# remove old XMLTV Events from epg.db as a single transaction
    			self.cursor.execute('BEGIN')
    			self.events_in_past_journal = 0
    			self.events_in_import_range_journal = 0
    			print "[EPGDB] cleaning outdated events ..."
                            cmd = "DELETE FROM T_Event WHERE changed < datetime(?, 'unixepoch')"
                            self.cursor.execute(cmd,self.epoch_time)
    			print "[EPGDB] connect finished"
    			return True


    Die Database die offen ist: epgd.db


    Warum outdated events deleten wenn wenige Momenten später oder beim abschließen diesen epg.db uberschrieben wird durch die in memory.


    Ich bekomme auch diese meldung:


    [EPGDB] FOUND Rytex XMLTV with source_id 5
    [EPGDB] starting cleaning of events from /media/sdcard/XMLTV-EPG/epg.db
    [EPGDB] cleaning outdated events ...
    [EPGDB] connect to EPG database /media/sdcard/XMLTV-EPG/epg.db failed


    Auch denke ich das es nicht gut ist um die db_Feld "changed" zu nehem weil das keine Verbindung hat mit die events im database außer wenn "changed" alter ist dann die 28 tage dann kann man den event löschen.


    http://www.dream-multimedia-tv…&postID=141820#post141820


    Ghost, danke und ich denke das Gutemine auch dafür ist. Kannst du etwas angeben über die Geister egp.db-journal die ich sehe?


    So wieder mal einige Stunden getestet und hier wirkt es sehr gut. Ich benutze es täglich so die dauertest lauft.

    Dank für die r11 und ich bekomme noch immer Problemen mit dem Geister Journal. Kann es sein das epgdb.py die Zeit die vergeht zwischen das beenden des ersten epg.db-journal und die Geister epg.db-journal nicht beachtet und die Entstehung der Geister epg.db-journal so vermisst?


    Die Initiierung zwei variablen ist noch immer im den try-exept und dann kann es dar zu Fehler kommen. Es geht um :


    Zitat

    self.events_in_past_journal = 0
    self.events_in_import_range_journal = 0

    Seit einge stunden steh ein update für den box.


    4.2.1r10
    - fixed epgcache description search (e.g. fixes autotimer)
    - Wizard.py: re-add lost optional retval argument
    - fixed incomplete python stacktrace in crashlog files

    Wenn ich eine zweiten import mache bekomme ich im epgimport.py eine melding:



    update: wenn es nicht gut geht schriebt nach dem epg.db-journal enigma noch eine zweiten kleines epg.db-journal und ich sah eine große vom 633KB. Die zweiten wird direct wieder gelöst so ich kann nicht die exacte grosse erkennen.


    update:


    So nach des umbenennen/kopieren von epg.db-journal nach epg.db gibst zu wenig zeit um die Geister epg.db-journal wieder zu deleten und die import startet schon weil es noch in die Geister epg.db-journal geschrieben wird.


    Auch zwei variablen mussen dupliziert werden aus der 'try' nach den init Teil der routine.

    Den Fehler das manchmal schon in eine alte epg.db geschrieben wird und deswegen das save vom enigma2 schiefgeht habt ihr auch noch nicht entdeckt.


    Ganz schön schwach Eure Testerei :smiling_face_with_sunglasses:


    Meinst du diese Meldung?



    http://www.dream-multimedia-tv…&postID=141354#post141354


    Danke für die 2.1_r9 und ich werde die gut testen. :smiling_face:

    Ich kenne das Problem und teste eine wahrscheinliche Löschung fur das. Es kommt oft vor wenn die epg.db sehr groß ist ud wie groß war deine epg.db denn?


    OK ich habe einige test gemacht und die Warteschleife hilft echt und ich sehe so kein Performance Degeneration und die 'spinner' störren mich nicht.


    Code Suggestion:



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


    Die 15MB grenze und die wartezeit mussen noch 'gefinetuned' werden aber es hilft echt. Ich könnte nicht einlezen und mit die Anpassung geht es. Vielleicht ist nur die "time.sleep(3)" genugend aber das muss ich nog testen.

    Ich habe es bemerkt das es falsch geht. :frowning_face:


    Das problem is dat die events schön eingelesen werden wahrend die epg.db-journal noch geschrieben wird. Ich habe nur 77MB und das dauert 30 Sekunden um zu schreiben.

    Dank und ich muss was du geschrieben hat noch lesen und I habe eine mir das problem die ich habe wenn die epg.db sehr groß das die epg.db-journal noch geschrieben wird und so die Import etwas warten muss.


    deleted


    Ich habe eine "epgdb_path_tempwrite" gemacht und eine warte schleife und isr sehr rudimentär aber ich bin noch eine Anfänger in Python. Es kann sicherlich eleganter.


    Ich habe auch "return false" wieder drin und noch immer my dirty trick to generate epd.db wenn die noch nicht besteht.

    Nicht jeder hat gleichzeitig auch drei Journaling Fenster offen stehen und es ist auch was man nicht sieht vermisst man auch nicht direct. Die Funktionalität wird nicht beeinflusst durch Abwesenheit von die "%s"


    Ich habe hier meine epgdb.py editiert so das die Zahler die nur Information um dort "_journal" hinter an zu hangen. Weiter habe ich erklärungs texten angepasst und neue hinzu gefügt. Ich werde auch nach die andere python scripts sehen. Ich werde die epgdb.py duch pm an dich senden dann kannst du erst sehen ob es sinn macht.


    Die Anpassung die ich gemacht habe ist dafür wenn gar kein epg.db anwesend ist. Das kann auf die oft benutze weise vom systemctl stop enigma2 oder wen gerade eine epg.db-journal geschreiben wird und entfernt die epg.db Normaler weise kommen beiden nicht vor aber ich mache gerne Programme "User Proof".


    Cross-EPG is ein super Programm aber die Import auf meine DM8000 ging sehr oft nicht gut und ich benutze zwei XMLTV bestanden nicht und benutzte dann OpenTV oder die Standard EPG. Dein Programm hat nicht so viele Möglichkeiten aber ist sehr zuverlässig und tut was es tun muss.

    Mal ne ganz anddere Frage zur EPG Datenbank.


    Wann wird diese geschrieben? Also auf hdd, sdcard, usb usw.
    Nur beim Neustart/Herunterfahren?
    Was ist wenn enigma2 zuvor crasht. Dennoch alles weg?


    Beim starten von de import und on standby or restart. Auf was du angebt im system-customize.
    Alles weg im RAM und die schon geschriebene event bleiben.

    Na gut, weil das nur 2 Codezeilen sind :face_with_rolling_eyes:


    Code
    cmd = "DELETE FROM T_Event WHERE changed < datetime(?, 'unixepoch')"
    self.cursor.execute(cmd,self.epoch_time)


    Wobei das delete über die Trigger gar nicht so schlecht performed, obwohl man dann die indizes behalten muss.


    Danke Gutemine und Ich dachte das es nicht wirken wurde mit die code die oben steht aber es geht einfach.


    Es dauerte gestern Abend was langer weil ich mich "Urban Priol: TILT! - Tschüssikowski 2014" angesehen hat und andere Dingen gemacht.


    I have some findings and I made a clean import and when examining the epg.db I noticed that the T_source was expanded with source 5 and secondly I had the following message when starting:


    Jan 02 00:53:21 dm7080 enigma2[1329]: [EPGDB] is located at /media/9016-4EF8/XMLTV-EPG/epg.db
    Jan 02 00:53:21 dm7080 enigma2[1329]: [EPGDB] %s not found, sorry


    This without any epg.db present and then T_Source contains only the four standard lines


    Jan 02 00:55:04 dm7080 enigma2[1432]: [EPGDB] is located at /media/9016-4EF8/XMLTV-EPG/epg.db
    Jan 02 00:55:04 dm7080 enigma2[1432]: [EPGDB] ADDED Rytex XMLTV with source_id 5
    Jan 02 00:55:04 dm7080 enigma2[1432]: [EPGDB] starting cleaning of events from /media/9016-4EF8/XMLTV-EPG/epg.db
    Jan 02 00:55:04 dm7080 enigma2[1432]: [EPGDB] cleaning outdated events ...
    Jan 02 00:55:04 dm7080 enigma2[1432]: [EPGDB] connect failed


    This was with a epg.db present and now line 5 is added XMLTV also the "connect failed" puzzles me.


    update: I inserted an "eEPGCache.load(epginstance)" when os.path.exists(epgdb_path) (file: epg.dat) is not found) and removed the following False. I don't know if that will disturb the rest of the import or the next import because of your warning # DMM has to fix that save is not synchronous.


    Code
    def start_process(self, epgdb_path=None, retry=False):
    		self.connection = None
    		epginstance = eEPGCache.getInstance()
    		eEPGCache.save(epginstance)
    		if epgdb_path is None:
    			epgdb_path=config.misc.epgcache_filename.value
    		if not os.path.exists(epgdb_path):
    			# DMM has to fix that save is not synchronous
    			print "[EPGDB] %s not found, sorry"
    			eEPGCache.load(epginstance)

    Sicher und die performance war immer gut. Und dass ich nun vollem EPG haben mach mich Freude jedes mal wenn ich es sehe auf die Fernseher.


    Meine weise vom denken ist. Die anwesende EPG event konnen nicht upgedatet werden durch die box weil die external sind und dan bleiben nur wenige sender uber die nicht im XMLTV sind. Also nehme ich an das die Internal Data events auch deleted werden im die r23 version wenn XMLTV wird benutzt.


    Ich denke die Event saving version is die weg su gehen und mach alles sehr flexibel. Will ich sicherlich testen.


    Wie behandelt DMM die outdated events und werden die in memory schon deleted?