ach so, das ist ja nur der übliche architektur Fehler, der workaround mipsel zusätzlich einzutragen sollte aber jetzt schon ausreichen bekannt sein.

Ich könnte aber auch mips32el ipks bauen

Und nicht wundern die r8 ist ident zur r7

Nein reines Umbenennen bringt nichts das muss im control file stehen - probiere die kits die ich gerade hochgeladne habe.

Na ja dann enigma2 restarten und nochmals laufen lassen aber ich denke es wird funktionieren, die frage ist eigentlich nur ob es den Patch im OE2.0 immer noch reichtig erkennt um die epg daten zu laden.

Aber das ist schon ziemlich OT hier

lass dir Zeit, letzendlich ist das nur Spielerei, offiziell supporte ich das OE2.0 ja gar nicht mehr

no Oudeis patch, load(/media/hdd/epg_new.dat) required
[EPGImport] attempt load() patch
FATAL: LINE 168 descriptor not found in descriptor cache 02cb68b2!!!!!!
PC: 75afb0f4

Wie ich vermutet habe der code findet sich mit dem Patch fürs EPG Laden im OE2.0 nicht zurecht, aber ich weis nicht einmal ob das Standard das ipk nicht das Selbe Problem macht. enigma2 sollte durch den Crash dann aber die epg.dat trotzdem laden

Unsere Holländischen Freunde haben ja keine enge Beziehung zu DMM mehr, also kann es schon sein das es schon länger und bewusst so ist. Liesse sich zwar fixen (CrossEPG kann den Patch zum Laden ja richtig benutzen) aber sicher NICHT von mir.

Jetzt siehst du warum die Datenbanklösung im OE2.2 schöner ist

Der Patch fürs CrossEPG hat Ghost ja im OE2.0 noch angepasst, um Schadensbegrenzung zu betreiben, dass das unseren Holländischen Freunden egal war ist ja nicht unsere Schuld.

Insfern sind wir froh das es möglich war den Rest des EPGImport Plugins für unsere Zwecke zu recyclen, es gibt ja auch noch diverse Mods davon, und da meine Codechanges nur wenige Zeilen sind und im Wesentlichen eigenltich nur in einer eigenen epgdb.py sind, kann jetzt jeder damit machen was er will.

Ich habe nicht umsonst jetzt die aktuelle Version auch bei OoZooN hochgeladen, weil ich kann euch hier im Thread nicht ewig die Schuhe zubinden.

Im Prinzip fiunktioniert es jetzt ja und es müssen jetzt genug User die aktuelle Version BENUTZEN und damit Testen ob es noch Probleme gibt, es bringt wenig noch ständig was zu ändern, jetzt muss es sich erstmals im ALLTAG bewähren.

PS: Im OpenATV Crashed es ja nicht, also ist mir das OE2.0 auch egal, weil das reicht mir zum Vergleichen aus.

das sollte eigentlich nicht sein ... nochmals löschen und enigma2 beim laden in telnet starten so wie im Thread beschrieben.

Dann kannst du auch mitlesen welche sender geladen werden, weil nur das was im xml ist kann auch geladen werden. Wenn was fehlt müsstest du dich im XMLTV Forum bei unseren Holländischen Freunden einfinden und deinen Wunschsender sowie eine Websource mit den EPG Daten posten, dann bauen sie es dir vielleicht ein.

SAT oder Kabelkunde, weil wenn Sachen fehlen sind meistens die service references unterschiedlich ?

dann hat es auch nicht geladen, nochmals laden.

Verwendest du auch wirklich die aktuelle version 2.1 r7/r8 ?

stoppe mal enigma2 mit systemctl stop enigma2 dann lösche die epg.db und dann starte UND restarte enigma2 damit ein saubere epg.db rausgeschrieben wird. Dann sollte es eigentlich funktionieren und auch so bleiben.

Selbst eine LEERE epg.db muss wenigstens 23kB gross sein:

ls -alh /etc/enigma2/epg.db
-rw-r--r--	1 root 	root   	23.0K Jan  3 18:37 /etc/enigma2/epg.db

Sonst fehlen die Tabellen und dann kriegst du deine Crashes.

das ist sehr seltsam, wenn du das Plugin gar nicht benutzt sollte der enigma2 restart eine leere 23kb grosse epg.db schreiben und da sind dann auch alle nötigen Tabellen drinnen.

EDIT: Aber ich habe nicht umsonst im EPGdbBackup Plugin die Möglichkeit implementiert die epg.db zu sichern und einen Database conistency check drüber laufen zu lassen.

LG
gutemine