Wie jetzt ?
Es geht wenn sie aus dem Deep Standby kommt, aber es geht nicht wenn sie schon lief.

Ich denk die Problematik is genau andersrum?
Dann kannst Du aber nicht sagen, daß es dort nicht passiert, wennTorsten73 hat geschrieben:@Kexxen:
Ich habe mehrere Boxen! Mir viel halt nur auf, dass das mit den 2 Timern bei der "immer an" Box passierte. Aus dem Deep Standby habe ich das noch nicht probiert, bzw. kann mich nicht an probleme erinnern, weil ich dort eigentlich nie 2 Timer hintereinander mache.
die timer sind weg, gelöscht! und keinen deep standby zu nutzen,KeXXeN hat geschrieben:@Micha
Ich kann dich beruhigen, wenn ich das so richitg gesehen habe dann laufen Timer die auf der Box gespeichert werden und über einen Streamingserver aufnehmen und die Box zu diesen Timern nicht aus dem Deep Standby aufwachen muss, absolut tadelos und ohne Fehler durch.
@P.S.
Siehe FAQ Unter "serielles Log / Bootlog"
Hab ich ja auch nicht behauptet.Micha911 hat geschrieben: die timer sind weg, gelöscht!
Dann würde es sich schon ehr lohnen den Stecker vom TV immer raus zu ziehen und den nicht auf Standby laufen zu lassen ebenso beim Bildschirm vom Computer und evtl beim Vorhandenen DVD-Player oder Videorecorder. Das würde im Jahr mehr Strom sparen.und keinen deep standby zu nutzen,
ist doch enrgieverschwendung, oder?
Eng betrachtet nicht. Global betrachtet aber schon.und auf einen nfs-server
direkt aufzunehmen sollte doch kein unterschied zum speichern auf
einen streamingserver machen, was die behandlung der timer
angeht, oder?
Code: Alles auswählen
#!/bin/sh
date -s 010101001970
sectionsd
timerd -d &
sleep 5
Die Frage ist, ob das im normalen Standby nicht passiert undKeXXeN hat geschrieben:Hab ich ja auch nicht behauptet.Micha911 hat geschrieben: die timer sind weg, gelöscht!
Da bin ich nicht so sicher, mein TV hat einen guten Standby-Wert,KeXXeN hat geschrieben:Dann würde es sich schon ehr lohnen den Stecker vom TV immer raus zu ziehen und den nicht auf Standby laufen zu lassen ebenso beim Bildschirm vom Computer und evtl beim Vorhandenen DVD-Player oder Videorecorder. Das würde im Jahr mehr Strom sparen.Micha911 hat geschrieben: und keinen deep standby zu nutzen,
ist doch enrgieverschwendung, oder?
Das würde ich dann mal testen bei Gelegenheit. Welcher Streaming-KeXXeN hat geschrieben: ... Beim Streamingserver aber der Computer die Box entlastet.
Man könnte einen Zusammenhang zwischen fehlerhafter Anmeldung oder schlechten Timing und dadurch resultierenden fehlerhafter Aufnahme und dem verschwinden der Timer in Betracht ziehen.
1. Ist das date -s 010101001970 nicht auch ein bißchen problematisch?ChakaZulu hat geschrieben:...Code: Alles auswählen
date -s 010101001970 sectionsd timerd -d & sleep 5
Wenn in diesem Fall auch in der /var/tuxbox/config/timerd.conf nichts steht, dann sind sie tatsächlich gelöscht...
ChakaZulu
Die Zeit kann vorher nicht ok sein, da sie niemals gesetzt wurde. Da der sectionsd derzeit u.a. auf Jahr >= 2005 prüft wird mit o.g. Datum sichergestellt, dass diese Bedingung nur erfüllt ist, wenn eine Zeit gesetzt wurde (entweder extern oder aus dem EPG). Vorher waren auch z.B. Jahreswerte mit 2019 möglich und dieses Datum wurde als ok betrachtet.Micha911 hat geschrieben:
1. Ist das date -s 010101001970 nicht auch ein bißchen problematisch?
-d impliziert das starten im Vordergrund, der Rest von start_neutrino sollte aber trotzdem abgearbeitet werden. Das sleep habe ich mal reingemacht, weil ich mir nicht sicher war, ob es einen zeitlichen Unterschied macht, wenn der timerd selber forkt oder er direkt im Hintergrund gestartet wird. Wahrscheinlich kann man es auch weglassen..2. Was ist der Unterschied zwischen "timerd" (nicht im Hintergrund und
ohne nachfolgendem sleep) und "timerd -d &" plus "sleep 5"?
naja, wenn er durch ein falsches Datum entfernt wurde, dann steht er nicht mehr drinP.S. Ja mein Wiederholungstimer ist wirklich weg, steht nicht mehr drin
in der timerd.conf
woher weiß die box dann, wie sie aus dem deep standby erwachenChakaZulu hat geschrieben:Die Zeit kann vorher nicht ok sein, da sie niemals gesetzt wurde.Micha911 hat geschrieben:
1. Ist das date -s 010101001970 nicht auch ein bißchen problematisch?
Konkret mache ich folgendes in start_neutrino:Wenn jemand andere Synchronisationsmechanismen nutzt, dann sollte er das natürlich rausmachen![]()
jeden montag bis freitag um die gleiche zeit, er kann doch eigentlichnaja, wenn er durch ein falsches Datum entfernt wurde, dann steht er nicht mehr drin
Was ist der wiederholungstimer eigentlich für einer? wöchentlich, täglich,...?
die box hat keine RTC. Es wird über einen Treiber festgelegt, in wievielen Minuten die Box wieder aufwachen soll (wie das genau funktioniert weiss ich nicht, vielleicht werden irqs gezählt? wobei man, wenn man an den Zähler herankommen würde, da auch eine Uhr draus basteln könnte). Leider kenne ich mich mit den Treibergeschichten und der Hardware nicht aus... Die Uhrzeit kann man beim start dann auch nicht irgendwie berechnen, solange unbekannt ist, ob die Box durch eben diesen Timer gestartet wurde oder nicht.Micha911 hat geschrieben:
woher weiß die box dann, wie sie aus dem deep standby erwachen
soll. ist das eine andere baustelle? wird die uhrzeit beim aufwachen
nicht aus der hardware initialisiert?
Ich denke mal, rdate blockiert solange, bis die Zeit gesetzt ist.Konkret mache ich folgendes in start_neutrino:
/sbin/rdate time.fu-berlin.de
neutrino -u -f
/sbin/rdate time.fu-berlin.de
Sollte ich das "date -s 010101001970" trotzdem machen?
Die Wochentage hast Du eingegeben? Sonst wird er automatisch in einen einfachen Timer umgewandelt
jeden montag bis freitag um die gleiche zeit, er kann doch eigentlich
nicht durch eine falsche zeit verschwinden, weil er ja in alle ewigkeit
aufnehmen sollte. und außerdem ist da ja noch das rdate was ich als
zusätzliche sicherheit hatte.
ja, kommt über die Konsole.p.s. -d heißt also debug beim timerd? und wo kommen die ausgaben
hin? krieg ich sowas nur über eine serielle konsole hin?
Beim normalen Standby bleibt die Box komplett in Betrieb.Micha911 hat geschrieben: Die Frage ist, ob das im normalen Standby nicht passiert und
wenn ja, warum.
KA. Aber wenn sie in Standby ist kannst du das Display mit der Mute taste auch abschalten.Allerdings kann man vom PC aus auch im Standby
noch auf das Webinterface zugreifen, und das finde ich einen Vorteil.
Weiß jemand wie stark die Leistungsaufnahme ist, wenn man das
Display stark dimmt?
UDrec läuft unter Mono.Das würde ich dann mal testen bei Gelegenheit. Welcher Streaming-
Server ist unter Linux eine gute Wahl? Und ich welchen Formaten wird
dann aufgezeichnet?
KeXXen:
Dann würde es sich schon ehr lohnen den Stecker vom TV immer raus zu ziehen und den nicht auf Standby laufen zu lassen ebenso beim Bildschirm vom Computer und evtl beim Vorhandenen DVD-Player oder Videorecorder. Das würde im Jahr mehr Strom sparen.
Code: Alles auswählen
- Wenn Jahresdatum ungleich aktuelles Jahr nach 15s Wartezeit(verankerte Variable) dann Programmwechsel (auf einen sinnigen Programmplatz z.b. +1) und Infoanzeige (Uhrzeitsync)
- Bei shutdown der Box Variable "aktuelles Jahr" in neutrino.conf (oder ähnlich) speichern.
okay mach ich, mal sehen was passiert.ChakaZulu hat geschrieben:Ich denke mal, rdate blockiert solange, bis die Zeit gesetzt ist.Micha911 hat geschrieben: Konkret mache ich folgendes in start_neutrino:
/sbin/rdate time.fu-berlin.de
neutrino -u -f
/sbin/rdate time.fu-berlin.de
Sollte ich das "date -s 010101001970" trotzdem machen?
Du solltest das sinnvollerweise vor den Aufruf von sectionsd stellen.
ja die wochentage, hat ja eine ganze zeit funktioniert. nur 2 tageDie Wochentage hast Du eingegeben? Sonst wird er automatisch in einen einfachen Timer umgewandeltjeden montag bis freitag um die gleiche zeit, er kann doch eigentlich
nicht durch eine falsche zeit verschwinden, weil er ja in alle ewigkeit
aufnehmen sollte. und außerdem ist da ja noch das rdate was ich als
zusätzliche sicherheit hatte.
Habe dieses Problem nicht, wenn ich die Aufnahmen programmiereMicha911 hat geschrieben: Aktuell ist noch folgendes Problem: nehme ich zwei sendungen
direkt nacheinander via timer auf, so geht die box 3 minuten nach
beginn der zweiten aufnahme (bei zwei minuten vorlaufzeit für jeden
timer) in den deep standby und die zweite aufnahme ist futsch.
dieses problem ist übrigens reproduzierbar.
Nö, war kein Zufall. Ich hab die Announcetime für den Überschneidungscheck verwendet. Kann man aber ändern und sollte kein Problem sein, da aufeinanderfolgende Timer funktionieren dürften..Micha911 hat geschrieben: Interessanterweise meckert die Box beim Programmieren des
zweiten Timers, daß sich diese Aufnahme mir der ersten überlappen
würde (deren Endzeit aber gleich der Anfangszeit der zweiten
Aufnahme ist). Interessant auch, dass die angezeigte Anfangszeit
des ersten Timers 3 Minuten früher als die tatsächlich programmierte
ist. In der Timerliste ist aber alles richtig eingetragen. Wieder 3 Minuten.
Zufall?