Seite 2 von 2

AW: SD und die Timer.db

Verfasst: Mi 21. Mai 2014, 16:34
von wohliks
Thorsten hat geschrieben:Aber auch bei anderen Fehlern, die nachvollziehbar sind, kommen diesen Fragen :-)
Ich will mich da auch nicht weiter aus dem Fenster lehnen, denn ich habe nur SRPs und die sind ja nun hard- und firmwaremäßig anders gestrickt als die CRPs...

Aber ich streite nicht, ab dass es bei Dir spezielle Konstellationen gibt, die vielleicht bei der überwiegenden Mehrzahl der User gar nicht vorkommen.

Zum Beispiel die Sache mit der doppelten Aufnahme: Ich bin noch nie auf die Idee gekommen, einen laufende Aufnahme mit einer folgenden Aufnahme verbinden zu wollen und sehe für mich persönlich auch keinen praktischen Nährwert bei diesem Vorgehen - aber es gibt Leute (nicht nur Dich :wink: ), die sowas tun möchten und dabei dann so einen Fehler entdecken...

AW: SD und die Timer.db

Verfasst: Mi 21. Mai 2014, 17:11
von Thorsten
Müssen aufpassen, wird sonst Offtopic hier :) ...

Aber ich denke, es kommt schon vor - machst 2-3 Aufnahmen (durch Timer) und hast vielleicht keinen Slot mehr frei um eine nachfolgende Sendung aufzunehmen. Ich empfinde dieses kombinieren als sehr praktisch, auch weil es im Dateinamen ja verzeichnet wird.

SE hat Qualitäten, bei denen können sich andere EPG Programmierer einfach eine Scheibe abschneiden bzw. à la Apple vieles gab es sicher schon vorher, aber beim SE funktioniert es einfach und ist gut zu bedienen. So soll es sein.

Und wenn da mal was schief geht, nun ja, es wurde von Menschen geschrieben und 100% bugfrei gibt es einfach nicht.

Mag sein, daß die verstrubbelte timer.db mit anderen Gegebenheiten korreliert, aber genau den gemeinsamen Zusammenhang zu finden, das ist die Herausforderung. Fehler sind IMMER reproduzierbar, es ist nur schwierig die Gegebenheiten nachstellen zu können :) ...

Gruß
Thorsten


PS: Ist ein SRP2401 und ein CRP2401 wirklich so unterschiedlich in Hardware oder ist nur ein anderer Tuner verbaut und die Firmware vom CRP etwas anspeckt, weil es dort so manche Funktionen (unterschiedliche Sendelisten für beide Tuner, OWA Updates, ...) nicht gibt?

AW: SD und die Timer.db

Verfasst: Mi 21. Mai 2014, 17:22
von Twilight
Thorsten hat geschrieben:Letztens hab ich den SE Scan Timer "verlegt", daraufhin hat sich der SD Timer sofort verschoben und beim nächsten Reboot war die Timer.db wieder defekt (und immer nur die).
was war denn schon wieder der grund dafür ?! :thinker:

twilight

AW: SD und die Timer.db

Verfasst: Mi 21. Mai 2014, 19:18
von Thorsten
War einer der Versuche vor einigen Tage als ich mich hier noch nicht meldete :-)

AW: SD und die Timer.db

Verfasst: Mi 21. Mai 2014, 20:21
von Thorsten
Mal ne Verständnisfrage - SD Timer ist für 1:00 und 12:00 freigegeben. SE Scantimer steht auf 5:30 Uhr.

Im Autodecryption Folder steht eine zu entschlüsselnde Datei von 1:00 Stunde Laufzeit (inkl. Vor- und Nachlauf). Wieso wird der SD Timer hier nicht auf 1:00 gesetzt sondern auf später? Die eine Stunde hätte doch locker in der Nacht schon dekodiert werden können!?

Gruß
Thorsten

AW: SD und die Timer.db

Verfasst: Mi 21. Mai 2014, 20:37
von Twilight
das kann ich dir nicht sagen. die timerlogik kommt von firebird. ich denke das er einfach den größeren slot nimmt von den beiden die es gibt.
haben wir uns nicht darauf geeinigt das se erst etwas später scannt? :rolleyes:

twilight

SD und die Timer.db

Verfasst: Mi 21. Mai 2014, 20:55
von Thorsten
Hatte ich eingestellt. Beim Reset ist das wohl wieder reingerutscht. Mir ging es auch eher die Logik zu verstehen, wie was zusammenhängt :-)

AW: SD und die Timer.db

Verfasst: Mi 21. Mai 2014, 22:08
von Twilight
wie gesagt, er wird sich für das größere fenster entscheiden.

twilight

AW: SD und die Timer.db

Verfasst: Mo 26. Mai 2014, 10:10
von FireBird
Wie Twilight schon schrieb, wird immer der größte zusammenhängende Block verwendet.

SD und die Timer.db

Verfasst: Mo 26. Mai 2014, 14:01
von Thorsten
Die Strategie ist aber etwas überarbeitungsbedürftig. Der Morgen wird ja im Prinzip immer durch einen Scan unterbrochen. Stelle ich den auf 7 Uhr, dann habe ich maximal 7 Stunden zum Dekodieren minus einpaar Minuten dazwischen. Die sind aber schnell zu, wenn ich mal 3 Filme und 2 Serien dekodieren lassen muss.

Stelle ich das ein, dass er erst nach dem Scan loslaufen soll, verschwende ich Zeit davor.


Im Worst Case kommen immer mehr Aufnahmen dazu weil er nicht in der Lage ist die Blöcke abzuarbeiten auch wenn mal ein Zeitfenster für weniger möglich wäre.

Also eine Teilung wird nicht durchgeführt.

Schade, vielleicht als eine Optimierung für die Zukunft wert :-)

AW: SD und die Timer.db

Verfasst: Mo 26. Mai 2014, 14:18
von Twilight
wenn SE den SD timer setzt so hat dieser vo den scan timer vorrang. setzt RBN den SD timer so wird dieser als normal gesetzter timer behandelt.

wenn mann RBN so programmiert das es das setzen der timer SE überlässt bzw. dies in SE sogar aktiv anstößt, so würde man alle nicht SE user ausschließen und das wollten wir vermeiden :rolleyes:

twilight

AW: SD und die Timer.db

Verfasst: Mo 26. Mai 2014, 18:56
von Thorsten
Man könnte eine Erkennung einbauen, so wie SE ein RbN und SD erkennt :-)

AW: SD und die Timer.db

Verfasst: Mo 26. Mai 2014, 19:05
von FireBird
Man könnte unheimlich viel, wenn die Lust dazu da wäre... :wink:

AW: SD und die Timer.db

Verfasst: Di 27. Mai 2014, 07:40
von Thorsten
Wie, keine Lust mehr? :-) Schonmal an ein Bezahlmodell nachgedacht zum Freischalten von Funktionen, die über die Basis hinausgehen (modular)?

AW: SD und die Timer.db

Verfasst: Di 27. Mai 2014, 08:52
von FireBird
Ja und das Modell kommt nicht in Frage.