Sinn und Unsinn von "emergency exit"

Moin!

Zitat von geronimo

Dass die unterschiedlichen Eigenschaften von Sender und Karte nicht richtig berücksichtigt werden, war mir schon immer ein Dorn im Auge.
... aber Ok, das betrifft ja nur die Minderheit mit unterschiedlichen Karten

Das ließe sich über ein Plugin und die DeviceHooks realisieren, denke ich.
Das Schöne daran ist, dass der Code dann nur bei den Leuten zum Tragen kommt, die es brauchen.

Lars.

Zitat von geronimo

Ich verstehe trotzdem nicht, warum die Frontends nicht wie ein Recorder aufgebaut sind?
Der Recorder ist ein Thread mit eigener Queue und Receive übermittelt nur ein Paket. Also schnell und genau so, wie man es erwarten würde.
Warum muss der VDR-core sich mit Transfer-Problemen rumschlagen?
Ich sehe darin weder eine Vereinfachung noch eine Verbesserung.
Wenn ich johns richtig verstanden habe, arbeitet sein Frontend eher wie ein Recorder - also richtig nach meiner Einschätzung.

Alles anzeigen

Und so sollten alle Ausgabedevices arbeiten! Sie sollten die angebotenen TS-Pakete sofort entgegennehmen und aus PlayTs() zurückkehren. Wenn ein Ausgabedevice das nicht tut, dann sollte es entsprechend geändert werden. Und wenn es sich an für es nicht verständlichen Paketen "verschluckt", dann sollte es die angebotenen Pakete halt ignorieren.
Ein Ausgabedevice muß ja sowieso erstmal die TS-Pakete aufsammeln und die entsprechenden Payloads puffern, bis es dann mal einen kompletten Frame zusammen hat, den es darstellen kann.

Klaus

Zitat von geronimo

Hm, vielleicht verstehe ich ja wieder mal was nicht, aber meiner Ansicht nach arbeitet das SdFfDevice nicht so - und das ist ja vom VDR-Core, also von Dir.

Moment, die eigentliche Verarbeitung der Daten findet ja im Treiber (bzw. der Firmware) für die SD-FF-Karte statt. Dort müssen die TS-Pakete im Live-Modus quasi in "Echtzeit" angenommen werden.

Zitat

Die cTransfer-Klasse soll doch eine Abstraktion zwischen Sender und Anzeiger sein.
Meiner Ansicht nach wäre das der richtige Platz, um einen Ringpuffer zu verwalten (so wie es im Recorder passiert).

Du wirst lachen, so war es früher mal. Aber auch dieser Puffer ist ab und zu übergelaufen, wenn die Karte "gesponnen" hat.
Nicht jedes Problem läßt sich dadurch beheben, daß man einfach nur Speicher "draufschmeisst".

Zitat

Es gibt doch für jeden Wiedergabe-Weg eine cTransfer-Instanz, somit wären auch die entsprechenden Puffer redundant.
Eigentlich™ gibt es keinen Grund, warum jeder Player einen Ringpuffer anlegen müsste.

Überleg doch mal: die Daten kommen in einzelnen, kleinen TS-Paketen beim Ausgabedevice an. Dieses muß die Payload der TS-Pakete erstmal auspacken und zwischenspeichern, bis es ein vollständiges Video- bzw. Audio-Paket beisammen hat. Erst dann kann es das Paket abspielen. Im Ausgabedevice (sei es im Plugin oder in der Hard- bzw. Firmware) muß also bereits gepuffert werden. Und das Device muß die Daten im Mittel in der Geschwindigkeit annehmen, wie sie vom Sender kommen. Wäre es zu langsam, würde irgendwann jeder Puffer überlaufen, und sei er noch so groß.

Zitat

Selbst wenn die Puffer unterschiedlich groß sein sollten, könnte das in der cTransfer-Klasse gekapselt werden.
Die Recorder sind ja schon Threads, dann fehlt nur noch die Aufteilung von cTransfer in eine Thread/Puffer-Klasse, bei der Receive() den Puffer füllt und PlayTS in einem eigenständigen Thread läuft, welcher aus dem Puffer liest und die Player-Wiedergabe-Methode aufruft.

Naja - wie auch immer.
Beim SD-FF-Device erfolgt die Wiedergabe synchron in der device-Schleife des Empängers, denn das PlayTS ruft beim SD-FF-Device die Methode WriteAllOrNothing auf, welche höchtswahrscheinlich die Probleme verursacht. Habe jetzt nicht verfolgt, für was der erste Parameter beim SD-FF-Device steht, aber ein Puffer würde wahrscheinlich nicht per Dateioperationen gefüllt werden. Oder?
Hier fehlt also die Entkoppelung zwischen Empfänger und Wiedergabe.

Alles anzeigen

Das Problem liegt im Treiber bzw. der Firmware der SD-FF-Karte. Anscheinend verschluckt sich diese an Daten, mit denen sie nichts anfangen kann und blockiert dann zu lange, anstatt die Daten einfach zu verwerfen. Das müsste sich vielleicht mal jemand im Treiber bzw. der Firmware anschauen, aber ich vermute stark, daß das heutzutage niemanden mehr interessiert...

Hast du die Version 1.7.36 schon mal ausprobiert, oder ist diese ganze Diskussion nur noch theoretischer Natur?

Klaus

Moin!

Zitat von geronimo

Das waage ich mal zu bezweifeln.
Schließlich muss die Information ja auch irgendwo gehalten/abgelegt werden und das gibt die bisherige Channels-Struktur nicht her (. Es gab ja schon mehrfach den Wunsch, die Channelsstruktur aufzubohren).
Aber ich lasse mich gerne vom Gegenteil überzeugen

Naja, das Plugin muss sich natürlich schon merken, welche Kanäle es für welches Device sperren/zulassen soll, ich hab nicht gesagt, dass es automatisch und nur mit der channels.conf geht...
In anderen Programmen muss es ja auch erst mal konfiguriert werden.

Lars.

Ich hatte letztens auch Probleme mit der SD-FF. Ob hier Tuner oder Ausgabe die Ursache waren kann ich aber nicht sagen. Ergebnis war aber, dass auf dem Schirm nur ein buntes Muster zu sehen war. Aufnahme im Hintergrund natürlich unbrauchbar.

Was spricht denn dagegen in so einem Fall wirklich einen Buffer vorzuhalten und wenn der volläuft, dann halt anfangen den Rest einfach wegzuwerfen? Muss ja nicht generell im VDR so gehandhabt werden, aber vielleicht im dvbsddevice-Plugin? Wenn der VDR automatisch startet um eine Aufnahme zu machen, dann ist mir total egal was auf dem Bildschirm zu sehen ist. Nach der Aufnahme fährt der VDR dann ja wieder runter und beim nächsten Boot kann die Welt schon wieder ganz anders aussehen. Im besten Fall wird nie jemandem auffallen, dass die Ausgabe ein Problem hatte.

Zitat von mini73

Moin!

Naja, das Plugin muss sich natürlich schon merken, welche Kanäle es für welches Device sperren/zulassen soll, ich hab nicht gesagt, dass es automatisch und nur mit der channels.conf geht...
In anderen Programmen muss es ja auch erst mal konfiguriert werden.

Das, was du da meinst, gilt nur für die Empfangsseite.

Klaus

Zitat von Mreimer

Ich hatte letztens auch Probleme mit der SD-FF. Ob hier Tuner oder Ausgabe die Ursache waren kann ich aber nicht sagen. Ergebnis war aber, dass auf dem Schirm nur ein buntes Muster zu sehen war. Aufnahme im Hintergrund natürlich unbrauchbar.

War das eine Aufnahme, die vom Tuner der SD-FF kam, oder von einer anderen (Budget-) Karte?
Falls ersteres der Fall war, dann hätte auch ein zusätzlicher Puffer wohl nichts gebracht, denn wenn der ARM abgestürzt ist, ist alles zu spät.

Zitat

Was spricht denn dagegen in so einem Fall wirklich einen Buffer vorzuhalten...

Probiert doch einfach mal aus, ob der Ansatz in der Version 1.7.36 eine Verbesserung bringt. Bevor nicht jemand nachweist, daß das nichts bringt, werde ich mich an dieser Diskussion nicht mehr beteiligen - reine Zeitverschwendung!

Klaus

Moin!

Zitat von kls

Das, was du da meinst, gilt nur für die Empfangsseite.

Ja. Post 29 hatte ich so verstanden, dass man bestimmte Kanäle bei bestimmten Karten verbietet, weil die "das nicht zuverlässig aufnehmen können".
Das ändert nichts an dem SD-FF-Ausgabe-Problem, es wurden hier parallel zwei verschiedene Dinge besprochen.

Lars.

Zitat von kls

War das eine Aufnahme, die vom Tuner der SD-FF kam, oder von einer anderen (Budget-) Karte?
Falls ersteres der Fall war, dann hätte auch ein zusätzlicher Puffer wohl nichts gebracht, denn wenn der ARM abgestürzt ist, ist alles zu spät.

Aufnahme wurde mit dem Tuner der FF-Karte gemacht. Ob der ARM abgestürzt war weiß ich nicht. Ich konnte den VDR "retten" durch Öffnen des OSD und Wiedergeben einer Aufnahme. Die Ausgabe hat sich dabei wieder "gefangen".

Ich werde aber mal auf 1.7.36 upgraden und weiter beobachten.

johns:
Damit die neue Schleife in transfer.c auch mit softhddevice funktioniert, sollte dort in PlayTsAudio und PlayVideo3 immer dann wenn ein TS-Puffer nicht angenommen werden kann, nur dann 0 zurückgegeben werden, wenn wirklich ein Retry gewünscht. Ich denke zumindest beim Erreichen von Soft- oder Hardlimits wolltest Du lieber die Pakete wegwerfen? Dann braucht der vdr aber ein return size.

Zitat von geronimo

Was mich stört ist einfach die Tatsache, dass ein Problem bei der Wiedergabe zu defekten Aufnahmen führen kann. Das kann und darf nicht sein.

Und wir wissen immer noch nicht, ob dieses Problem in Version 1.7.36 noch auftritt oder nicht...

Klaus

Zitat von geronimo

Wenn der VDR mit dem Klaus nimmer gepflegt werden kann, sollte man vielleicht über einen Fork nachdenken.
Es macht keinen Spaß mehr, sich für Produktqualität einzusetzen.Gero

Du bist ja noch schlimmer als unsere Politiker. Die zitieren auch nur genau das, was sich marktschreierisch vermarkten laesst, und lassen den Teil, welcher zum richtigen Verstendnis fuehrt, einfach weg.
Klaus hat gesagt was gemacht werden muss, damit die Diskussion weiter Sinn macht.
Aber Du scheinst ja nicht in der Lage dazu zu sein, eine aktuelle Version zu installieren

Zitat von TomJoad

Damit die neue Schleife in transfer.c auch mit softhddevice funktioniert, sollte dort in PlayTsAudio und PlayVideo3 immer dann wenn ein TS-Puffer nicht angenommen werden kann, nur dann 0 zurückgegeben werden, wenn wirklich ein Retry gewünscht. Ich denke zumindest beim Erreichen von Soft- oder Hardlimits wolltest Du lieber die Pakete wegwerfen? Dann braucht der vdr aber ein return size.

PlayTsAudio muß ich mir noch mal ansehen.

PlayAudio + PlayVideo(3) stimmen, da die über den PES Parser von VDR aufgerufen werden
und der hat seinen eignen Puffer bzw. Ringpuffer.

bzw. PlayVideo(3) wird auch über einen cReceiver aufgerufen, der schmeißt dann ein ganzes
PES Packet weg, wenn mein Video PES Ringpuffer voll ist.

Johns

So ich habe leider noch 1.7.35; ist aber nicht so wichtig.

Wenn ich jetzt in cDevice::PlayVideo bzw. cDevice::PlayAudio bzw. cDevice::PlayTsAudio
(ich meine meine abgeleitetete Klasse) die Pakete wegwerfe, wenn mein interner Puffer
voll ist, dann habe ich Artefakte bei der Wiedergabe von Aufnahmen.

Die Ursache ist, daß cDevice::Poll nicht richtig ausgewertet wird.

In dvbplayer.c wird DevicePoll(Poller, 10); mit 10ms aufgerufen, der Return Wert aber
nicht ausgewertet.

Mein Ausgabedevice schläft nur 10ms und damit werden meine Internen Puffer
natürlich sehr schnell bis zum erbrechen voll.

Entweder darf ich in cDevice::Poll länger schlafen oder der VDR sollte den Rückgabewert
auswerten.

Johns

Zitat von geronimo

Ich bin weder Politiker noch Marktschreier, habe nur eine andere Sichtweise auf Qualität - und somit bin ich überzeugt, dass das, was theoretisch falsch ist, praktisch niemals richtig sein kann.

Theoretiker: Nichts geht aber alle wissen warum
Praktiker: Alles geht und keiner weiss warum.
Auf welcher Seite Du stehst wissen wir nun ja
SCNR ...

Back to Topic, bitte, und nicht wieder abdriften, das hilft niemandem!

Lars.