Aufhängen beim Beenden der Aufnahme

[Sepp776]

Moin Moin!
Ich habe festgestellt, dass die Box sich nicht aufhängt, wenn man den sectionsd nach der Aufnahme nicht wieder startet.

vcrcontrol.cpp:

Code: Alles auswählen

bool CVCRControl::CServerDevice::Stop()
{
	printf("Stop\n"); 
	if(!g_Zapit->isPlayBackActive() && 
		CNeutrinoApp::getInstance()->getMode() != NeutrinoMessages::mode_standby)
		g_Zapit->startPlayBack();

	//--- sectionsd nicht wieder einschalten ---
	//g_Sectionsd->setPauseScanning(false);

	g_Zapit->setRecordMode( false );
	// alten mode wieder herstellen (ausser wenn zwischenzeitlich auf oder aus sb geschaltet wurde)
	if(CNeutrinoApp::getInstance()->getMode() != last_mode && 
		CNeutrinoApp::getInstance()->getMode() != NeutrinoMessages::mode_standby &&
		last_mode != NeutrinoMessages::mode_standby)
		g_RCInput->postMsg( NeutrinoMessages::CHANGEMODE , last_mode);

/*	if(last_mode == NeutrinoMessages::mode_standby &&
		CNeutrinoApp::getInstance()->getMode() == NeutrinoMessages::mode_standby )
	{
		//Wenn vorher und jetzt standby, dann die zapit wieder auf sb schalten
		g_Zapit->setStandby(true);
	}*/
	if(sendCommand(CMD_VCR_STOP))
		return true;
	else
		return false;
}

Allerdings reicht es nicht, das Starten des sectionsd einfach ans Ende der Funktion zu schieben oder ein kurzes Delay einzubauen. Warten auf (!g_Zapit->isRecordModeActive()) bringt auch nix.
Was könnte man noch überprüfen um zu wissen wann der sectionsd wieder eingeschaltet werden darf?

Ciao,
Sepp.

[Zwen]

IMHO bringt es nix hier an Neutrino rumzudoktorn.
Es ist und bleibt ein Treiber-Problem und da jetzt verzweifelt nach nem Workaround zu suchen halte ich für Zeitverschwendung...
Zumal der Kernel ja auch Oopst wenn man während des Streamens zappt.

Zwen

[kerlimann]

IMHO bringt es nix hier an Neutrino rumzudoktorn.

sagst du sowas eigentlich allen neuen devs?
seine frage war:"Was könnte man noch überprüfen um zu wissen wann der sectionsd wieder eingeschaltet werden darf?"

[Zwen]

sagst du sowas eigentlich allen neuen devs?

Wenn ich ihm damit viel Zeit ersparen kann, JA !
Wo ist da überhaupt dein Problem ???

seine frage war:"Was könnte man noch überprüfen um zu wissen wann der sectionsd wieder eingeschaltet werden darf?"

Meine Antwort (nochmals ausführlicher, damit es alle verstehen...):
Wieso sollte der sectionsd nur zu bestimmten Zeiten das "sections scanning" (ab/zu geschaltet wird er ja gar nicht) ein/ausschalten dürfen ? Das ist Quatsch. Der Sectionsd muss sogar während der Aufnahme funktionieren, das "sections scanning" wird ja während der Aufnahme nicht abgeschaltet, weil "es nicht erlaubt" ist, sondern weil die CPU-Power sonst für Streaming nicht reicht. Und selbst wenn es zu bestimmten Zeiten "verboten" sein sollte, wäre das kein Grund das der Kernel da hops geht.
Wenn es denn überhaupt ein Timing gibt , das bei dieser Problematik, den Treiber-Bug umschifft, so wird es viel Zeit kosten das rauszufinden und das eingentliche Problem, das auch in anderen Fällen zum tragen kommt, nicht beheben. Wenn Sepp... trotzdem nach dem besagten "Workaround" suchen will halt ich ihn nicht davon ab. Es bringt uns aber IMHO hier nicht weiter, denn unser größtes Problem hier im Projekt ist nun einmal, dass sich kaum jemand um die neuen Treiber, die noch einiger "Pflege" bedürfen, kümmert. Für jedem Treiber-Bug ein workaround in der userspace app ist einfach nicht das Konzept, mit dem ich mich anfreunden kann.

Zwen

[Sepp776]

Hallöle!
Habe mittlerweile festgestellt, dass es gar nicht am sectionsd hapert, sondern am g_Zapit->startPlayBack().

Das Problem ist, dass ich von den Treibern 0 Plan habe und der Code auch ziemlich schwer verständlich ist. Aber die Ursache dieses Fehlers so weit wie möglich einzugrenzen könnte ja schon helfen, den Fehler im Treiber zu finden. Das muss dann halt jemand anders machen

Ich finde, ein reproduzierbarer Fehler ist doch immer die beste Möglichkeit, um die Ursache zu finden.

Ciao,
Sepp.

PS: Wäre cool, wenn bei der neuen Source-Code Doku die Treiber-Sourcen mal halbwegs erklärt würden