Timer
Was soll denn daran ein Bug sein ? Wenn die Endzeit kleiner als die Startzeit ist, wird einfach Endzeit+ 1 Day. Klaro ? Ist so gewollt, damit auch Sendungen von 23.35 - 0.50 Uhr vernünftig aufgenommen werden können...
Levi
Levi
SAGEM black 2xI aktuelles JtG Team Image
SAGEM grey 2xI aktuelles JtG Team Image
Software: Gentoo stage1, KDE 3.4
Hardware: P4-3 GHz@3,2, Asus P4P800E-Deluxe, GF-6800LE@400:850:16/6,2048 MB RAM, NEC 1300A (gepatcht)
Warum ich gegen SuSE bin
-----------------
SAGEM grey 2xI aktuelles JtG Team Image
Software: Gentoo stage1, KDE 3.4
Hardware: P4-3 GHz@3,2, Asus P4P800E-Deluxe, GF-6800LE@400:850:16/6,2048 MB RAM, NEC 1300A (gepatcht)
Warum ich gegen SuSE bin
-----------------
DAS meinte ich,midreyer hat geschrieben:4. Kein Eintrag in das Feld Endzeit bzw. ein Wert (0) oder so geht nicht.
das andere ist schon klar dass bei endzeit kleiner anfangszeit vom nächsten tag ausgegangen wird ...
über 24h wird vohl kaum einer streamen wollen
Joe
never change a running system
NOKIA DBox2 2xI JtG Image 10.1.2004
NOKIA DBox2 2xI JtG Image 10.1.2004
Dann sag, was Du meinst 
Das habe ich wohl vergessen zu überprüfen.

Das habe ich wohl vergessen zu überprüfen.
SAGEM black 2xI aktuelles JtG Team Image
SAGEM grey 2xI aktuelles JtG Team Image
Software: Gentoo stage1, KDE 3.4
Hardware: P4-3 GHz@3,2, Asus P4P800E-Deluxe, GF-6800LE@400:850:16/6,2048 MB RAM, NEC 1300A (gepatcht)
Warum ich gegen SuSE bin
-----------------
SAGEM grey 2xI aktuelles JtG Team Image
Software: Gentoo stage1, KDE 3.4
Hardware: P4-3 GHz@3,2, Asus P4P800E-Deluxe, GF-6800LE@400:850:16/6,2048 MB RAM, NEC 1300A (gepatcht)
Warum ich gegen SuSE bin
-----------------
Hallo,
muß jetzt auch mal meinen Senf dazu abgeben.
Mal allgemein:
Es gibt drei Infos zur Aufnahmezeit: Start, Ende und Dauer. Nur zwei Infos sind zur Eindeutigkeit notwendig, dabei ist es egal welche beiden. Werden alle drei manuell eingegeben oder verändert, können sie sich wiedersprechen. Deswegen ist es Notwendig, dass einer aufpasst, entweder der User oder das Programm.
(In der intern.mdb werden nur Start und Ende gespeichert.)
Wunschdenken:
Das eleganteste wäre, wenn die Felder sich schon bei der Eingabe abgleichen.
1. "Programm, Doppelklick zu Timer" -> Start und Ende wird vom EPG übernommen, Dauer wird berechnet.
2. Neuer Timer manuell, zwei Felder werden ausgefüllt -> das dritte wird berechnet.
3. Alle drei Werte sind schon da, Start wird verändert -> Ende bleibt Dauer wird neu berechnet.
4. Alle drei Werte sind schon da, Ende wird verändert -> Start bleibt und Dauer wird neu berechnet.
5. Alle drei Werte sind schon da, Dauer wird verändert -> Start bleibt und Ende wird neu berechnet.
Damit ergibt sich eine Hirachie wie folgt: Start, Ende, Dauer.
Stand:
Im Moment findet eine Berechnung auch schon in etwa so statt, aber leider nicht schon bei der Eingabe, sondern beim Speichern.
zu 1. Funktioniert genau so.
zu 2. Nur die Dauer wird berechnet, Start und Ende müssen angegeben werden.
zu 3.-5. Ist auch so, wobei bei 5. beim Speichern aktualisiert wird, bei 3.+ 4. ist noch ein Deselektieren und erneutes Selektieren des Timereintrags nötig.
Bitte an Levi:
Das liebste wäre mir, wenn Du die Brechnung schon bei der Eingabe machen könntest, wenn der Aufwand nicht dafür steht, wäre es schön, wenn die Aktualisierung direkt beim Speichern passiert und nicht erst beim Neueinlesen eines Timereintrages.
Zusätzlich:
Wenn man an einem Timereintrag nachträglich die Zeiten variiert und dann speichert, wird der markierte Eintrag entsprechend geändert, aber der Fokus geht verloren (die graue Markierung ist weg) und bei erneutem Ändern und Speichern wird ein neuer Eintrag erzeugt, statt dass der ehemals angewählte weiter geändert wird.
Absturz:
Habe mal 24:00 als Start eingetragen und gespeichert. Wurde auch so übernommen, aber nach ein paar Sekunden kam ein Error-Popup:
An unhandled exception has occurred...
String was not recognized as a valid DateTime
Ist auch beliebig wiederholbar und bei unsinnigen Zeiten (45:65) ist es auch so. Gibt man aber 1245 statt 12:45 ein, schimpft Jack. Prüfst Du nur das Format und nicht auch den Wertebereich, oder ist die Prüfung fehlerhaft?
Gruß Frank
muß jetzt auch mal meinen Senf dazu abgeben.
Mal allgemein:
Es gibt drei Infos zur Aufnahmezeit: Start, Ende und Dauer. Nur zwei Infos sind zur Eindeutigkeit notwendig, dabei ist es egal welche beiden. Werden alle drei manuell eingegeben oder verändert, können sie sich wiedersprechen. Deswegen ist es Notwendig, dass einer aufpasst, entweder der User oder das Programm.
(In der intern.mdb werden nur Start und Ende gespeichert.)
Wunschdenken:
Das eleganteste wäre, wenn die Felder sich schon bei der Eingabe abgleichen.
1. "Programm, Doppelklick zu Timer" -> Start und Ende wird vom EPG übernommen, Dauer wird berechnet.
2. Neuer Timer manuell, zwei Felder werden ausgefüllt -> das dritte wird berechnet.
3. Alle drei Werte sind schon da, Start wird verändert -> Ende bleibt Dauer wird neu berechnet.
4. Alle drei Werte sind schon da, Ende wird verändert -> Start bleibt und Dauer wird neu berechnet.
5. Alle drei Werte sind schon da, Dauer wird verändert -> Start bleibt und Ende wird neu berechnet.
Damit ergibt sich eine Hirachie wie folgt: Start, Ende, Dauer.
Stand:
Im Moment findet eine Berechnung auch schon in etwa so statt, aber leider nicht schon bei der Eingabe, sondern beim Speichern.
zu 1. Funktioniert genau so.
zu 2. Nur die Dauer wird berechnet, Start und Ende müssen angegeben werden.
zu 3.-5. Ist auch so, wobei bei 5. beim Speichern aktualisiert wird, bei 3.+ 4. ist noch ein Deselektieren und erneutes Selektieren des Timereintrags nötig.
Bitte an Levi:
Das liebste wäre mir, wenn Du die Brechnung schon bei der Eingabe machen könntest, wenn der Aufwand nicht dafür steht, wäre es schön, wenn die Aktualisierung direkt beim Speichern passiert und nicht erst beim Neueinlesen eines Timereintrages.
Zusätzlich:
Wenn man an einem Timereintrag nachträglich die Zeiten variiert und dann speichert, wird der markierte Eintrag entsprechend geändert, aber der Fokus geht verloren (die graue Markierung ist weg) und bei erneutem Ändern und Speichern wird ein neuer Eintrag erzeugt, statt dass der ehemals angewählte weiter geändert wird.
Absturz:
Habe mal 24:00 als Start eingetragen und gespeichert. Wurde auch so übernommen, aber nach ein paar Sekunden kam ein Error-Popup:
An unhandled exception has occurred...
String was not recognized as a valid DateTime
Ist auch beliebig wiederholbar und bei unsinnigen Zeiten (45:65) ist es auch so. Gibt man aber 1245 statt 12:45 ein, schimpft Jack. Prüfst Du nur das Format und nicht auch den Wertebereich, oder ist die Prüfung fehlerhaft?
Gruß Frank
Sagem 1xi + HDD Kabel, JtG-Team Image v2.4.6 (19.12.2015), avia600vb028, ucode int., cam_01_02_105D
Coolstream Neo, FW 2.10 (leider kaputt)
Win 10 Pro x64, i7 920, 12 GB, SSD
u-Grabber 0.2.7.6-> TS -> PX 0.91.0.08 -> IfoEdit 0.971 -> ImgBurn 2.5.0.0 -> DVD-R
Coolstream Neo, FW 2.10 (leider kaputt)
Win 10 Pro x64, i7 920, 12 GB, SSD
u-Grabber 0.2.7.6-> TS -> PX 0.91.0.08 -> IfoEdit 0.971 -> ImgBurn 2.5.0.0 -> DVD-R
Naja, ich teste das nachher nochmal direkt in ACCESS. Ich kann mir nicht vorstellen, dass das am ACCESS liegt.
Levi
Levi
SAGEM black 2xI aktuelles JtG Team Image
SAGEM grey 2xI aktuelles JtG Team Image
Software: Gentoo stage1, KDE 3.4
Hardware: P4-3 GHz@3,2, Asus P4P800E-Deluxe, GF-6800LE@400:850:16/6,2048 MB RAM, NEC 1300A (gepatcht)
Warum ich gegen SuSE bin
-----------------
SAGEM grey 2xI aktuelles JtG Team Image
Software: Gentoo stage1, KDE 3.4
Hardware: P4-3 GHz@3,2, Asus P4P800E-Deluxe, GF-6800LE@400:850:16/6,2048 MB RAM, NEC 1300A (gepatcht)
Warum ich gegen SuSE bin
-----------------