Dreamboard

dre · 31. Dezember 2014

Doc ist wieder da. Bezüglich tmdb: ich hab ja auch einen moviecoverloader gebaut. Den apikey dafür hab ich. Allerdings kann ich den key in python nicht genug schützen. Darum hab ich den loader noch nicht released. Und vom cover zu den inhaltsangaben ist es ja nicht mehr weit.

Lost in Translation · 31. Dezember 2014

ja in der TMDB gibt es einiges an Zusatzinfos die nützlich wären und dann auch den Autotimer in ungeahnte Höhen katapultieren könnten.

Ich denke da nur an die FSK für den Jugendschutz aber man könnte damit sogar VPS wieder aufleben lassen für die Senioren die das vermissen.

Und für den appkey reicht doch eine kleine *so in C, der Doc sollte wissen wie das geht und hilft da sicher gerne- Er hat mir ja auch erlaubt mich bei den DB Routinen der VideoDB zu bedienen für die epg.db, auch wenn dann weniger nötig war als ich dachte.

Wenn er aber mal über mein Machmerk an sqlite code in python drüber schauen würde wäre es sicher nicht schlecht, weil da ist noch genug Optimierungsbedarf würde ich mal sagen

dre · 31. Dezember 2014

Der moviecoverloader wird wohl letztlich die sachen von videodb reusen. Klar, ein .so würde das lösen

msatter · 31. Dezember 2014

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.

Lost in Translation · 31. Dezember 2014

ich habe mir gerade spassweise das sqlitebck für die dreambox compiliert. Ist in unserem Fall zwar nicht wirklich notwendig weil wir im enigma2 ja load/save haben. ABER willst du ein externes backup shell script ala EPGBackup machen und das von ausserhalb enigma2 aufrufen ist das evt. ganz nützlich und der c code um so ein python module zu machen incklusive DB Anbindung ist eigentlich ganz simpel wenn ich mir das so ansehe. Damit liesse sich der loader wahrscheinlich wesentlich performanter umsetzen als in python, jetzt wo wir wissen wie es geht - aber ich habe meinen Beitrag schon geleistet, jetzt seit ihr dran.

msatter

Ich habe auch so angefangen und der Mensch wächst an der Aufgabe Aber dann probier ich halt deine Codeschnisel die du gepostet hast reinzumachen, OK ?

msatter · 31. Dezember 2014

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.

Lost in Translation · 31. Dezember 2014

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

Und es ist besser zum debuggen enigma2 mit systemctl stop enigma2 zu stoppen und dann mit enigma2 in telnet zu starten und mitzulesen.

msatter · 31. Dezember 2014

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:

Code

# 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.

Lost in Translation · 31. Dezember 2014

ja das erste Laden triggert ja auch ein Speichern, beim zweiten mal Laden sollte es also auch funktionieren - das muss sich DMM ansehen warum das save nicht synchron ist.

Probier einfach die 2.1 aus dem Anhang, da habe ich die Parameter wie gewünscht eingebaut, es aber NICHT mehr getestet, weil du sagtest du bist nicht sicher ob du es schaffst, aber damit müsst Ihr jetzt auch langsam selbst zurecht kommen

Settings parameter sind im enigma2 alles strings, du musst also in der formel mit int() arbeiten.

EDIT: Ich habe die Anhänge entfernt, ich hoffe da sind alle deine Änderungswünsche zum Nachlesen, aber testen und anpassen musst du es schon selber.

LG
gutemine

msatter · 31. Dezember 2014

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!!

Lost in Translation · 31. Dezember 2014

Danke, ich mache daraus noch schnell eine echte 2.1 und dann geht lieber das Neue Jahr begrüssen

EDIT: Ich musste aber bei den outdated events noch 4h dazu geben damit wenigstens Now auch geladen wird. Das Maximum dort bei der enigma2 Einstellung sind 96h - also effektiv jetzt 100h die alte Daten geladen werden können - sofern das xml die überhaupt beinhaltet.

Guten Rutsch!
gutemine

msatter · 31. Dezember 2014

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.

Code

# 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.

Lost in Translation · 31. Dezember 2014

Cleverer, so würde das besser gehen, aber erst 2015

msatter · 31. Dezember 2014

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:

Code

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

Code

# 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

Lost in Translation · 1. Januar 2015

Prosit 2015

msatter · 1. Januar 2015

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.

Lost in Translation · 1. Januar 2015

Ich denke DMM hat überall das Datum dabei damit das Housekeeping weis welche alten events es löschen soll, aber im Prinzip hast du recht die haben es wohl nicht wirklich mit so viel Daten ausprobiert wie sich das Handling verhält.

Lost in Translation · 1. Januar 2015

nachdem das save der EPG db aus dem Memory nicht synchron ist wird es nicht fertig wenn der code schon die Datenbank connecten will, was bei laufendem enigma2 nicht so schlimm ist weil man es dann halt nochmals aufruft und die epg.db wurde in der Zwischenzeit geschrieben.

Dreht man aber das epg laden beim booten im Plugin auf, dann ist das fatal weil es zu crash und Endlosschleife führt.

Ich habe das halt auch noch gefixed, indem ich das connecten der epg.db mit dem löschen der Tabellen in eine eigene routine ausgelagert habe, die dann auch vom processing als retry ausgeführt werden kann. Nachdem das laden und parsen der xml einige zeit dauert wird dann sobald das Laden losgeht halt reconnected und das Plugin erfängt sich sozusagen.

Damit sollte es auch in dem Fall nicht mehr crashen und auch wenn man /etc/enigma2(/epg.db löscht funktionieren. Ich habe den 2.1 kit gegen eine r2 ausgetauscht wo das drinnen ist.

Dafür habe ich den python code für das Offline laden des EPG aus dem Plugin entfernt, weil der ist nicht mehr nötig und würde auch nicht mehr funktionieren.

Ausserdem habe ich den code ja schon so angepasst das er auch weiterhin mit epg.dat funktioniert. Ich habe daher aus der 2.1 auch ipks gemacht, um sie im OpenATV image gegenzutesten - funktioniert und braucht NUR ca. 30-40% der Zeit zum Laden, womit es wenig Sinn macht an der Performance noch gross zu drehen, weil dann ist das laden der epg.db eh schon vergleichbar mit der Dauer auf den alten Dreamboxen.

Falls das wer gegentesten will sind im Anhang auch die ipks von der 2.1-r2.

Ich hoffe das war es dann erstmal, weil ich würde auch gerne wieder was anderes machen und 2 Manntage Arbeit die da reingeflossen sind sind denke ich genug.

LG
gutemine

Viril · 1. Januar 2015

Dann nochmals danke und ich werde im Verlaufe des Tages mal testen.

Und die ipk-Version läuft nur im OpenATV?

Oder verstehe ich dich richtig, da es mit der epg.dat funktioniert, es auch mit einem DMM-OE2.0-Image läuft?

P.S.: Ich frage lieber einmal zuviel als einmal zu wenig.

Lost in Translation · 1. Januar 2015

Das ipk müsste eigentlich auch in einem OE2.0 Image funktionieren, aber ausprobieren müsstet Ihr das schon bitte selber. Ich habe das ja nur gemacht damit der code wenigstens theoretisch in sein git zurück könnte und eben jetzt um die Performance gegentesten zu können.

Und ja, sachen wie z.B. die besch* checkerei mit dummy recordings ob ein Channel existiert habe ich ja entfernt und durch einen simplen check nach dem Channel Name ersetzt (weil es das Logging im OE2.2 überfordert), genauso wie das jetzt auch die Language extrahiert und wenigstens an die processing routine auch für die epg.dat übergeben wird (wird aber dort natürlich ignoriert, verwendet wird es derzeit nur in der epgdb.py)

Insofern ist das auch eine unbeabsichtigte Verbesserung für die alten Boxen wenn ich so nachdenke