BPanther's Neutrino Forum

thc09 hat geschrieben:...wie kann man nur auf sone blöde IDEE kommen, das Systemdatum abzuprüfen.

Geht ja nicht anders bei den Timern, wenn man es richtig abfragen will. Es muß ja irgendwo ein Vergleich stattfinden, ansonsten geht die Box ja immer davon aus, die wäre wg. dem Timer neu gestartet worden und nicht manuell. Bei oscam allerdings fand ich das, als es überhaupt eingebaut wurde, schon Blödsinn, es bestand keine Notwendigkeit dafür, denn andere können das auch ohne gleich oder überhaupt das aktuelle Datum zu haben.

Hi

BPanther hat geschrieben:

thc09 hat geschrieben:...wie kann man nur auf sone blöde IDEE kommen, das Systemdatum abzuprüfen.

Geht ja nicht anders bei den Timern, wenn man es richtig abfragen will. Es muß ja irgendwo ein Vergleich stattfinden, ansonsten geht die Box ja immer davon aus, die wäre wg. dem Timer neu gestartet worden und nicht manuell. Bei oscam allerdings fand ich das, als es überhaupt eingebaut wurde, schon Blödsinn, es bestand keine Notwendigkeit dafür, denn andere können das auch ohne gleich oder überhaupt das aktuelle Datum zu haben.

Grins, das mit der OsCam meinte ich, wozu muss das Ding nen aktuelles (bzw = > ) als Erstellungsdatum haben.

Nun, man soll sich ja nicht beschweren. Aber am Anfang ging das ja auch ohne, was einfach besser war. Auf der Coolie bin ich angewiesen auf das Cam. Auf der 910 läuft die Mgcam.

Arbeite nicht so viel

Gruss!

Morgen gehts wieder in Spät.

Man kann die Zeitabfrage wohl per Parameter abschalten soweit ich weiß, aber dann gabs wieder andere Probleme, daher habe ich das nicht eingebaut beim Start. Naja, eben ne buckel-cam...

Ja das ist absoluter Quatsch was die oscam da macht....
Im Endeffekt startet die nur etwas zu spät und dadurch ist dann kein Bild wenn man auf einen codierten startet.
Ich streu einfach ein pzapit -rz 20 sek. nach Neutrino Start ein, dann klappt das immer das ein Bild kommt..

Hi

DboxOldie hat geschrieben:Ja das ist absoluter Quatsch was die oscam da macht....
Im Endeffekt startet die nur etwas zu spät und dadurch ist dann kein Bild wenn man auf einen codierten startet.
Ich streu einfach ein pzapit -rz 20 sek. nach Neutrino Start ein, dann klappt das immer das ein Bild kommt..

Quatsch, bringt es auf den Punkt (oscam). 20 Sekunden können auch zuwenig sein, und du musst (meinen Fall vorausgesetzt) auch sicherstellen das die Mgcam nicht startet bevor die Oscam einsatzbereit ist. Das geht schief und du hast eine versaute Aufnahme. Der Reconnect funktioniert nicht zuverlässig in der Kombi. Zumindest gilt das für die Coolie, und ich glaube das die anderen compilate da nicht besser sind. Und ob DVBApi ne alternative ist, weiss ich noch nicht. Ich teste das gerade auf einer Coolie.

Gruss!

Ja OK den pzapit braucht man ja nur bei DVBapi, Du musst dann den mg Start verzögern.

Hi

DboxOldie hat geschrieben:Ja OK den pzapit braucht man ja nur bei DVBapi, Du musst dann den mg Start verzögern.

Das mit dem pzapit würde ich so garnicht stehen lassen, das funktioniert teilweise schon so wie du sagst, auch in der os/mg Kombi. Also zumindest wenn der Feed zwischendurch wegfällt.

Ich kenn mich da allerdings auch nicht wirklich aus.

Gruss!

Na geht doch!

Nachdem ich die Funktion checkWakeUpTimer angepasst habe
Funktioniert alles so wie es soll.

Danke BPanther.

Die neue rev4688 (v1) bzw. rev5671 (NMP) hat das ebenfalls bereits eingebaut für alle Boxen. Damit ist das auch erledigt.

Nach Update auf rev6045 habe ich jetzt das gleiche Problem wieder.

Gruß schelm61

Seltsam, wurde ja nichts dran gemacht.

Ja, find ich auch seltsam.

Wollte mir mal die Datei rcS ansehen, die kann man aber jetzt nicht mehr bearbeiten,
da die jetzt ein Binär Format hat.

Hat sich da was geändert?

Bei mir macht die 910 auch kein Neustart, hängst sich weg, hilft nur Netzschalter.

@Logiman: Nach fast 19 Tagen Betriebszeit habe ich mal nen Neustart der Box gemacht, lief ganz normal - auch ein weiterer danach. Da hilft wohl nur ein serielles Log um zu sehen, wo sie bei Dir festhängt.

@schelm61: Da ich os selbst mit benutze, konnte ich das bisher nicht mehr nachvollziehen, zumal ja auch nichts mehr dran geändert wurde seitdem es funktioniert hatte. Zudem ist der damalige Fix aus Beitrag 14 weiterhin aktiv.

Flogendes wird auf der Console angezeigt, wenn die Aufnahme zu Ende ist:

[dvb-sub] ***************************************** start, stopped 1 pid 0
TuxTxt subtitle unpause, running 0 pid 0 page 0
NeutrinoMessages::RECORD_STOP: eventID 3 channel_id b9b0044d00016dca
Stop: eventID 3 channel_id b9b0044d00016dca
MOVIE INFO: apid 102 type 0 name stereo selected 1
MOVIE INFO: apid 106 type 1 name Dolby Digital 2.0 (AC3) selected 0
[ConfigFile] saving /var/tuxbox/config/timerd.conf
Stop: channel b9b0044d00016dca recording_id 3
[LT:31459e20:record] Stop
[LT:31459e20:record] RecordThread: end
[LT:3144b218:demux ] Close dmx_tp_count < 0!!
[frontend.cpp:Unlock:310] [fe0] usecount 0 tp 2e3c00c0044d0001
[femanager.cpp:getFrontend:565] live fe 0 on the same TP
[LT:00000000:demux ] SetSource(1, 0) => 0 to 0
[femanager.cpp:getFrontend:565] live fe 0 on the same TP
[capmt.cpp:SetMode:236] RECORD/STREAM(1): fe_num 0 rec_dmx 0
[capmt.cpp:SetMode:262] channel b9b0044d00016dca [Das Erste] mode 1 STOP src 0 mask 1 -> 1 update 0
[femanager.cpp:getFrontend:565] live fe 0 on the same TP
[ca.cpp] GetInstance
[ca.cpp]:SendCAPMT
TPID: B9B0044D00016DCA
SOURCE_DEMUX: 0
CA_MASK: 1
CALEN: 0
Scrambled: 0
Mode: 1
Enabled: STOP
[ca.cpp] GetInstance
[LT:31459e20:record] ~cRecord: calling ::Stop()
[LT:31459e20:record] Stop
[LT:31459e20:record] Stop: status not RUNNING? (1)
[LT:31459e20:record] Stop: dmx == NULL?
[LT:31459e20:record] Stop: file_fd not open??
[LT:31459e20:record] ~cRecord: end
StartNextRecording: pending count 0
[neutrino.cpp] executing /var/tuxbox/config/recording.end.
[zapit] recording mode: 0
NeutrinoMessages::EVT_RECORDMODE: off

Aber er fährt nicht herunter.