Bitte, weil ich habe nur schnell den code gemacht, ob und was davon funktioniert müsst Ihr sagen ... ich würde aber wie gesagt das mit fletcher16 nehmen, wobei wenn Ihr sagt es geht mit fletcher32 auch dann werde ich wahrscheinlich die C++ cache routine nehmen die sowieso schon benutzt wird, weil die ist wahrscheinlich flotter als jede python checksum, egal wie simpel die ist. Vor allem könnte ich dann einfach die 2 vorhandenen checksums verwenden das ist dann noch schneller als jede zusätzliche.

Aber jetzt muss mal getestet werden ob wenn man durch die checksum immer die gleiche dvb event id bekommt das dann keine Probleme mehr bei den Aufnahmen macht

DAS ist genau das Verhalten das wir hatten wenn die dvb id > 65536 war - ob Ghost uns das jetzt glaubt oder nicht

Kann man alles viel weiter oben im Thread nachlesen.

Und jetzt sei so nett und probier die Variante mit der 16 Bit checksum ...

EDIT: Was solls, ich bin ziemlich sicher das ich recht habe, ich habe die Variante mit fletcher16 checksum einfach in eine 1.1 r9 vom OpenEPG und in eine 2.2 r2 vom XMLTV reingemacht, OHNE das an die grosse Glocke zu hängen - so sehen wir am schnellsten ob damit das Problem gefixed ist.

Ich habe daher die epgdb.py hier entfernt .... jetzt 'dürfen' halt alle testen ...

Na ja wenn es mit 16Bit checksum geht werde ich wohl einfach die title und die description checksum kombinieren dann sollte das fast keine extra processing Zeit benötigen, aber zuerst iwll ich mal wissen ob die dvb event id jetzt so auch über mehrerer Ladevorgänge gleich bleibt und die Timer nicht mehr durcheinander kommen, dann die Performance wieder dort hin zu bringen wo sie war ist nicht so schwer, weil wir ja schon reichlich checksums verwenden.

Und falls Ghost rausfinden warum der python code was falsches zurück kriegt wenn die dvb event id > 65536 womit der timer button dann im epg nicht mehr angezeigt wird, dann muss ich es sowieso nochmals umschreiben, insofern habe ich es nicht wirklich eilig ...

Und laut DVB standard muss die checksum wohl mit < 65536 ausreichen, sonst wäre es nicht so im standard - rechne nach 30 Tage EPG das sind dann 65536/30=2184 events pro Tag oder 90 pro Stunde, selbst wenn du einen sender hast der nur Videclips mit 2-3 Minuten dauer sendet und das EPG dafür liefert erreichst du das nicht.

Insofern ist bei realen sendern die chance darauf das die checksum gleich ist recht gering und da die Aufnahmen sowieso timestamp haben ist es auch kein Problem wenn bei gleichen test auch gleiche id verwendet wird.

Und ich habe extra den fletcher32 und fletcher16 code in der epgdb.py belassen - Ghost kann gerne das ändern und rausfinden was da passiert - wenn es mit 32 Bit WIRKLICH geht dann ändere ich es gerne, aber im Moment bin ich ziemlich sicher das es eben nicht geht. Ich kann gerne die stelle im Thread suchen wo wir uns damit schon mal gequält haben.

Na ja wenn ich heute nicht zu mühe bin baue ich gerne eine einfachere checksum benutzung für die dvb event id ein, zum reproduzieren ist die aktuelle Version aber nützlicher, weil du damit alle Varianten probieren kannst.

Aber wenn du sagst es geht bis auf die Performance jetzt wieder alles dann habe ich eben keinen Stress falls es bis zum Wochenende warten muss.

EDIT: Ich habe vom EpenEPG eine 1.2 r10 und vom EPGImport eine 2.2 r3 gemacht wo einfach die bereits vorhandenen Textchecksums recycled werden, das sollte jetzt kaum mehr sprürbar langsamer sein als vorher. Nachdem das beide 32Bit Integers sind dividiere ich die einfach durch das doppelte von 65536 und addiere sie, das sollte dann < 65536 sein und falls doch mal 32 Bit bei der dvb event id gehen muss man halt einfach nur mehr beide werte durch 2 dividieren vor dem Addieren. Nicht so tolle, aber da es Ineteger Mathematik ist sollte es recht flott sein.

Danke fürs testen, wie schon gesafgt sobald ich weis das die Aufnahmen passen fällt mir schon was ein was die Performance angeht.

Ich denke ich habe auch schon eine Idee - Ich werde da ganz einfach komplett auf die checksum von den Texten verzichten, solange ich als ID maximal 65535 verwenden kann habe ich sowieso das Rikisko im 1 % Bereich das die selbe ID rauskommt, da kann ich gleich auf die Texte verzichten und nur die Beginnzeiten als dvb event id verwenden. Weil wenn eine sendung verschoben wird dann verliert man halt die Beschreibung aber nicht den Titel und wenn wirklich mal eine sendung durch eine andere ersetzt wird dann nimmst man sowieso das falsche auf, da ist es dann sogar RICHTIGER wenn wenigstens die neue Beschreibung genommen wird. DAS Risko ist also wahrscheinlich sogar das genigere als wenn ich die Beschreibungen nehme und die Zeit ignoriere.

Und da sendungen immer zu ganzen Minuten anfangen: 24h x 60min x 30 Tage gibt 43200 was immer noch kleiner als 65536 ist. Die Leute die sich die Sache mit der event id im Standard überlegt haben sind ja auch nicht blöde gewesen als sie definiert haben das 16Bit ausreichen.

Ich code das mal so und dann sehen wir wie das performt, der Impact davon sollte aber schon minimalst und kaum mehr merkbar sein.

Ich habe jetzt die EPG Plugins aktualisiert so das sie nur mehr die Anfangszeit pro Channel als unique dvb event id verwenden.

Mal sehen ob das auch noch funktioniert und die Performance dadurch fast wieder wie früher ist

Jetzt nicht mehr

na ja dann sag mir welche Variante die schnellste war Fletcher 16, kombinierte standard hashes oder eben nur begin zeit.

Allerdings ist es seltsam wenn ein bisschen integer mathematik das so verlangsamt, nicht umsonst bin ich kein Python fan ...

Theoretisch müsste man das auch mit byteshifts rausschneiden können, in C wüsste ich wie das geht ...

Allerdings habe ich einen Fehler gemacht - ich gehe bei den sokunden auf das Vielfache von 65536, ich sollte noch mit 60 Multiplizieren damit es die Minute sind - sonst gibt es zu viele duplikate bei der id. Na ja man sollte sich nicht beeilen damit es vor dem Abendfilm fertig ist.

seitdem das als static definiert ist läuft der Thread egal was man macht, und der Standby check ist nur wenn es losläuft, aber gut das es mal wer ausprobiert hat.

Aber langsam komme ich mir hier ein bisschen blöde vor wenn wir zwei uns hier alleine abquälen und sich die anderen zurücklehnen und genau NICHTS beitragen.

Ich habe daher erstmal die r4/r11 der Plugins einfach ausgetauscht gegen welche wo die id richtig mit Minuten ermittelt wird, also bitte nochmnals runterladen.

Und die die sich hier nicht blicken lassen und das evt. nicht wissen haben dann jetzt halt Pech gehabt, weil mich zurücklehnen kann ich nämlich auch