Hallo Forum,

das beschriebene Phänomen habe ich leider auch auf meiner DM7020HD. Ich habe die letzten OE2-experimentals durchprobiert und der Fehler tritt bei allen Versionen auf. Bei den Tests habe ich nur das Autotimer-Plugin installiert. Sobald ich einen Autotimer anlege und speichern möchte, bleibt die Box stehen und reagiert auf nichts mehr. Bei einem leeren EPG (nach dem harten Ausschalten) kommt das Plugin über das Speichern hinweg, findet natürlich nichts. Ist das EPG gefüllt - s.o.

Zur Box: Aktuell läuft die mit zwei DVB-T-Tunern (Sat ist noch nicht da...)

Ich habe keinen aktuellen Thread mit so einem Problem im Inet gefunden, obwohl es hier und da Berichte über "Hänger" gibt, die aber von der Ursache nicht zu meinem Problem passen.

Ein Flash mit "Bad Sector Recovery" hat zwar zwei Sektoren makiert, führte jedoch nicht zu einer Besserung. Unter OE1.6 funktioniert alles wie es soll.

Hat jemand eine Idee?

Vielen Dank im voraus!

Gruselino

Ist das vielleicht ein spezielles 7020- Problem? Ich habe den autotimer auf meiner 8000er am laufen, das aktuellste OE2.0- Experimental auf der Box (erst gestern wieder upgedated) und der AutoTimer blieb noch nie hängen.
Sehr seltsam...
Der Fehler sieht so aus, als ob er vom QT Browser kommt... Ihr habt nicht zufällig per QUickbutton oder so den Autotimer auf die rote Taste gelegt?

Gruss
Tode

Ich habe auf meiner 7020HD das aktuelle Experimental (20120912) drauf und die aktuellen Plugins vom EPGRefresh und AutoTimer sowie SeriesPlugin. Alle 26 Regeln des Autotimers laufen sauber durch, hatte da noch nie ein Problem seit Monaten...

Edit: Vergessen zu sagen, dass ich eine reine DVB-S/S2 Box habe, also kein DVB-T-

Gruß Mike

ist das nicht das problem wenn es DVB-T/C in kombination mit DVB-S tuner gibt

hab ich vor ein par wochen im IRC auch mal gemeldet

(war irgenwie eine nebenwirkung von ein bugfix)

Hi,

war vielleicht nicht besonders pfiffig, mich an den alten Thread zu hängen. Die Fehlermeldung (log) aus dem ersten Post habe ich nicht. Nur das Verhalten bei der Nutzung des Autotimers ist identisch. Daher fand ich das eigentlich ganz passend.

Ich erstelle mal ein log vom enigma2, allerdings als ich das schon einmal gemacht hatte, war da (für mich) nichts auffälliges zu sehen.

Gruselino

Hi,

scheinbar bin ich der einzige, der dieses Problem hat.

Gibt es eine Möglichkeit das Plugin in einen "Debug-Mode" zu versetzen, so dass ich vielleicht selber dem Problem näher kommen kann?
Mein oben angehängter Logfile zeigt zumindest mir keinen offensichtlichen Fehler an.

Oder muss ich in alle Ewigkeit auf der 1.6 bleiben?

Danke!

Gruß
Gruselino

vielleicht könnte ein bootlog erkenntnisse bringen?

Threading in Opendreambox 2.0 basierten Images suckt und ohne Threading suckt der AutoTimer.

Siehe z.B. im WebIf, dass write/finish des request zwingend vom Coder auf dem Mainthread ausgeführt werden müssen (siehe 120418473e2f851c5092bc42382eddd7f07d0159, sonst gab jeder threaded request im AutoTimer die Fehlermeldung).

Ein voll asynchrones arbeiten mit vor- und zurückspringen aus/in den Mainthread erfordert einen umfangreichen Rewrite des parsing-Codes und dafür habe ich weder Lust noch Zeit. Plus das macht den Code unwartbar(er)…
Oh, ich habe übrigens keine Ahnung warum bei manchen Leuten eine Aufnahme nur aus dem Mainthread gestartet werden kann. Ich nehme mir ein Beispiel an der Politik und gebe spontan einfach jeder anderen Zeile Code die Schuld

Die Komplexität des AutoTimer würde unproportional zum Nutzen zunehmen.

Mit gewissen Einstellungen kann die Suche (nicht die "Suche" von Enigma2, sondern die erweiterten Suchoptionen im Plugin) locker > 30s dauern - soll das wirklich blockierend im MainThread gemacht werden?
Und durch die Art und Weise wie der RecordTimer inkl. TimerSanityCheck implementiert ist, können die also nur vom MainThread aufgerufen werden.

Du hast nicht richtig gelesen - nicht der AutoTimer ist da schlecht, sondern Enigma2

Der AutoTimer müsste MASSIV Threads spawnen, die immer bei einem möglichen Match zurück zum MainThread springen um zu versuchen eine Aufnahme zu starten um dann wieder zurück in einen Child zu wechseln.
Im Endeffekt würde das ganze dadurch nur noch langsamer werden - ein wenig Threadsafety der entsprechenden Funktionen in Enigma2 ist trivialer

*EDIT* Grad erst Ghosts Reply gesehen. Wie schon geschrieben gibt es etwaige Funktionen im AutoTimer die durchaus > 30s laufen bei einem Haufen Nutzer (und für mich selbst läuft eine Funktion spätestens dann zu lang, wenn ich die grauenhaften Zahnräder sehe). Deshalb sind im AutoTimer WebInterface einige Requests in Threads gepackt. Und der benannte Commit war halt beim Wechsel von Opendreambox 1.6 auf 2.0 notwendig.

Ich habe das gleiche Problem mit dem Autotimer Plug In unter OE2.0. Meine Dream 800SE friert auch ein. Das ist ärgerlich, da ich dadurch nicht auf OE2.0 umsteigen kann.

Gibt es abseits der Threading Diskussion vielleicht doch eine Lösung?

Bei dem aktuellen Stand, ist autotimer für mich fast nicht zu benutzen. Das Einfrieren ist so nervend, dass ich mittlerweile alle Einträge im autotimer deaktiviert habe.

Um dennoch irgendeinen Nutzen aus dem Plugin zu ziehen, aktiviere ich derzeit spätestens alle 2-3 Tage (dank auf der auf unsinnge Weise kastrierten EPG-Daten der privaten Sender ) alle meine autotimer einmalig, lasse die Timerliste aktualisieren und deaktiviere diese dann wieder. Das ist aber umständlich und extrem nervend.

Ist es denn nicht möglich die automatische Aktualisierung in Threads zu deaktivieren und das als alternative zeitgesteuert anzubieten?

Klar kann man das, wenn man AutoTimer mit EPGRefresh kombiniert und EPGRefresh so einstellt, dass nach dem Refresh Autotimer aktualisiert wird.

Hallo Reichi,

bisher konnte ich die Locks ja mit 100%iger Sicherheit repuduzieren. Ich teste das gerne mal...

Gruß
Gruselino