Zitat von Ghost

Das ist in der Tat ein Bug... und er ist weder im Experimental, noch im Stable behoben.

Also das mit dem Wechsel von einem FBC auf einen non FBC Tuner...

Vielleicht hilft ja die Beschreibung zum Reproduzieren der Meldung weiter:
Sundtek USB-Tuner

Wenn ich nur den FBC S2x verwende, dann hatte ich sowas noch nie.
Das ist bei mir immer nur in Kombination mit dem Si2166B aufgetreten.

Ich hatte dazu hier schon mal was geschrieben :
Sundtek USB-Tuner

Aber selbst bei 10 min hast du dann kurz vor dem Ende schon die nächste Sendung im Display

Weiß auch nicht, ob Timeshift einen eigenen Screen hat.
Ich vermute mal nicht, wenn ich das bei mir so sehe.
Glaube, da bleibt einfach der normale Infobar_summary.

War mir ja nur nicht sicher, ob das bei allen so ist oder nur bei mir irgendwas vermurkst ist.

Könnte man das vielleicht über einen Converter regeln?
Der müsste dann irgendwie prüfen, ob Timeshift aktiv oder nicht und dann den entsprechenden Sendungstitel und die passende Restzeit zurückgeben.
Cool wäre auch, wenn der gelbe Fortschrittsbalken bei Timeshift z.B. blau wäre

Wäre diese Idee überhaupt machbar mit einem Converter?

Genau, die Symbole sind dann so leicht angedeutet (halbe Symbole).

Wo siehst du die Markierung?
Normalerweise werden die angrenzenden Sendungen ja nur optisch anmarkiert, um Überschneidungen anzuzeigen. Als Fehler würde ich das nicht bezeichnen.

Hallo

Ist es richtig, dass sich die LCD-Anzeige bei aktivem Timeshift weiterhin auf die aktuelle Live-TV-Sendung bezieht?

Das ist für mich immer etwas verwirrend, wenn im Display schon die nächste Sendung steht, obwohl ich ja per Timeshift noch die andere Sendung schaue.
Dadurch passt dann auch die Restlaufzeit nicht.

Ist das nur bei mir so oder generell?

Hab dazu jetzt mal 3 Pull Requests gemacht
https://github.com/opendreambox/enigma2-plugins/pulls

Wäre toll, wenn die Änderung im nächsten Feed-Update dabei ist.

Danke

edit: betonme hat die Änderungen gerade ins git übernommen, Danke

Zitat von Teiresias

...
Die Sache mit dem nachträglichen Entschlüsseln u.a. habe ich mir abgeschminkt. Meiner Meinung nach hat DP hier kein Interesse....

Solange es den TV-Anbietern egal ist, passt das ja auch.
Spätestens wenn sie einen Zwangsumstieg auf neue oder gepairte CI+ Module umsetzen, wäre das schlecht für die Dreamboxen.
Spätestens dann müsste DP nachziehen, um mithalten zu können

Wenn es dann soweit ist, wird DP sich Gedanken machen müssen, weil sonst keiner mehr eine Dreambox kauft.
Was nützt mir eine Dreambox, wenn ich nur noch schwarze Aufnahmen habe.
Da kann ich dann auch den TV nutzen, der kann das auch

Cool.
Da scheint es wohl einige Möglichkeiten zu geben.

Na schauen wir mal.
Denke, früher oder später wird man nicht mehr ohne die Funktion auskommen
Spätestens dann müsste sich DP da ja Gedanken machen.

Hier mal Zahlen zur prozentualen Verteilung:
https://de.statista.com/statis…-empfangsart-seit-2005/#0

In 2016: 46% Sat und 43,3% Kabel

Prognose für die nächsten Jahre zeigt einen sinkenden Anteil bei Kabel.

Hallo

In den verschiedenen OE-Versionen (2.5, 2.2 und 2.0) des aktuellen AutoTimer ist im github noch ein Bug enthalten (nach Hinweis eines Users im ihad).

Da werden an einer Stelle bei der Duplikatprüfung die Timer-Offset-Werte fälschlicherweise nochmals mit dem Wert 60 multipliziert (Umrechnung in Sekunden), obwohl der Offset-Wert an dieser Stelle bereits als Sekundenwert vorliegt.
Es erfolgt vorher an anderer Stelle in der AutoTimerResource.py schon die Multiplikation mit 60.

Dadurch kommt es unter bestimmten Umständen zur Erstellung doppelter Timer-Einträge.

Weitere Infos gibt es hier:
http://www.i-have-a-dreambox.c…ostid=2198911#post2198911

Es wäre schön, wenn jemand den Fehler im git vor dem nächsten Feed-Update noch beheben könnte.
Der Fehler wurde schon gegengeprüft und bestätigt.

Also bei den beiden Zeilen jeweils am Zeilenende beim timer.offset[x] das „ * 60“ entfernen

OE2.5 (master-branch): Zeile 387 + 388
https://github.com/opendreambo…mer/src/AutoTimer.py#L387

OE2.2 (branch 4.2): Zeile 493 + 494
https://github.com/opendreambo…mer/src/AutoTimer.py#L493

OE2.0 (branch 4.0): Zeile 492 + 493
https://github.com/opendreambo…mer/src/AutoTimer.py#L492

Vielen Dank

PS: Ich könnte auch ein Pull-Request über Fork machen, weiß jetzt nur nicht, was die bessere/schnellere Variante ist.

@zombi
Ok, dann kenne ich nicht die ganze Geschichte und halte mich daher zu diesem Thema etwas zurück
So gesehen, ist eure Zurückhaltung dann wieder nachvollziehbar.
Wollte wie gesagt keinen persönlich angreifen.

Ok, auch wenn ich seine Reaktion nicht verteidigen will, ist sie vermutlich etwas emotional veranlasst
Bisher ist er mir persönlich nicht wirklich negativ aufgefallen.
Vermutlich habe ich auch nicht alles gelesen, aber egal.

Aber grundsätzlich finde ich es gut, wenn es User wie ihn gibt, der aus einem anderen Blickwinkel die Funktionen von DreamOS und den Plugins betrachtet.

Auch wenn nicht alle seiner Ideen sinnvoll sind, waren aber auch schon gute dabei
Ich denke da nur die durchaus nützliche Funktion im EMC zum Beenden von wiederkehrenden Timern und die direkt anschließende Frage zum Löschen der Aufnahme
So kommt doch wieder fischer Wind ins DreamOS.

Ich denke, dass bei vielen Usern vielleicht schon eine gewisse Betriebsblindheit eingetreten ist und sie teilweise auch nicht mehr offen für Neuerungen sind.
Irgendwie habe ich auch den Eindruck, dass sie sich dann gleich persönlich angegriffen fühlen, wenn jemand DreamOS mit einer neuen Idee "kritisiert"
Ok, es kommt auch immer auf den Ton an, da muss ich euch recht geben.

Das jetzt bitte nicht persönlich nehmen. Ich wollte einfach mal meine persönliche Einschätzung dazu abgeben.
Vielleicht liege ich da ja auch völlig falsch.
Ich möchte damit keinesfalls eure bisherigen Bemühungen kritisieren.
Denn ohne euch wäre DreamOS mit all seinen Plugins und Screens jetzt nicht da, wo es ist

Das ist aber etwas egoistisch gedacht.
Warum soll ich denn mit meinem Wissen nicht einem Neuling helfen.

Dann zu sagen, sieh zu wie du klarkommst, mir hat damals auch keiner geholfen, ist da doch irgendwie die falsche Art.
Schade, eigentlich.

Auch schade, dass ein eigentlich interessanter Thread wieder so enden muss.

Ich hatte das Problem mit dem Nichtaufwachen gestern zum ersten Mal.
Ein Timer in der Nacht wurde nicht ausgeführt und die Wakeuptime für das Elektro-Plugin wurde auch ignoriert.
Ein Log habe ich leider nicht.

Komisch ist nur, dass meine Box sonst immer vom Elektro in den Deepstandby geschickt wird.
Da hatte ich bisher noch nie das Problem, dass die Box nicht selbständig aufgewacht ist.
Vorgestern hatte ich sie am Abend aber mal manuell in den DeepStandby geschickt.

Zitat von murray

ich kann mir vorstellen, dass das dafür ist damit die Box ausgeht wenn man vor dem Fernseher einschläft.

Und wenn man die Frage nicht beantwortet (weil man ja schläft), geht die Box dann trotzdem aus?
Wäre ja sehr unschön, wenn da parallele Timer laufen.

Zitat von Swiss-MAD

...Ich hätte viel lieber das der WakeUp Bug verschwindet. Also das sicher die WakeUp Time geschrieben wird damit Timer auch ausgeführt werden.
Wobei ich sagen muss, das ich das nun schon eine weile nicht mehr hatte.....

Ich hatte das gestern zum ersten Mal.
Ein Timer in der Nacht wurde nicht ausgeführt und die Wakeuptime für das Elektro-Plugin wurde auch ignoriert.
Ein Log habe ich leider nicht.

Komisch ist nur, dass meine Box sonst immer vom Elektro in den Deepstandby geschickt wird.
Da hatte ich bisher noch nie das Problem, dass die Box nicht selbständig aufgewacht ist.
Vorgestern hatte ich sie am Abend aber mal manuell in den DeepStandby geschickt.

PS: gab es für dieses Problem einen eigenen Thread, hab dazu leider nichts gefunden.

Eigentlich ist die Frage doch überflüssig solange die Box an ist, oder?
Oder braucht jemand diese Frage, wenn er gerade TV schaut?