Wie wäre es damit...lautloser VDR-Streaming-Client+DVB-Receiver für 39 Euro (+60 Euro PremiereStart)

JuNuVDR

Ich habe nun den Patch ausprobiert (sei doch nicht sooo ungeduldig ;))
Bei mir existieren nun auch keine Fehlermeldungen mehr.
Die dbox holpert zwar immer noch, aber nicht mehr so stark.
Und jetzt kommts!! einen mit netcat aufgezeichneten Stream kann die dbox nun ohne Probleme abspielen!!!

Zitat

Sollte der aufgezeichnete Stream via NFS-Mount mit der Dbox fehlerfrei (oder nahezu fehlerfrei) funktionieren, - was ich durchaus für denkbar halte, könnte ich erst mal im DBOX-Plugin einen Ringbuffer, eine zentrale Config-Datei und das OSD-Fading einbauen.

Nix wie los! Freue mich schon.
Vergesse bitte nicht auch noch die Stabilität des Plugins zu erhöhen

JuNuVDR

bei der dbox kann ich dir (außer Test) nicht helfen. Ich bin froh, dass ich den VDR compilieren und dort (ein bissl) mitmischen kann. Für das Aufsetzen der Compileumgebung für die dbox fehlt mir eindeutig die Zeit, obwohl die Lust schon da wäre.

@all
Ich habe beim ffnetdev noch ein Problem. Wenn ich den vdr(devel) über init.d neu starte, dann meldet sich das ffnetdev immer mit "remote control ffnetdev - learning keys". D.h. ich muss immer die Keys neu anlernen. Ich dachte, dass das bei mir schon mal geklappt hatte und ffnetdev sich die Keys gemerkt hatte.
Wenn sich der vdr neu startet (über runvdr), dann kennt das Plugin die Keys.
Was mach ich da noch falsch?

Danke
DonMarti

P.S: gerade ist mir noch eine Sache im syslog aufgefallen. Wenn ich über netcat den TS auf die Platte streame, dann sehe ich folgende Einträge:
vdr[11699]: buffer usage: 70% (tid=131081)
vdr[11699]: buffer usage: 80% (tid=131081)
vdr[11699]: buffer usage: 70% (tid=131081)
vdr[11699]: buffer usage: 80% (tid=131081)
vdr[11699]: buffer usage: 90% (tid=131081)
vdr[11698]: clearing transfer buffer to avoid overflows
vdr[11699]: buffer usage: 0% (tid=131081)

Was bedeutet das?
Kann das auch noch ein Problem im ffnetdev sein?
oder ist mein Rechner überfordert?

Moin Leute,

schön von den aktuellen Fortschritten zu hören.

Im Moment hab ich das Problem, daß ich mit dem ffnetdev 0.0.4 keinerlei TS-Connects hinbekomme. Das war zwar auch bei der Version 0.0.3 etwas hakelig, aber geklappt hat es da noch meistens. Möglicherweise hängt es auch damit zusammen, daß ich als Test-VDR die Version 1.3.31 verwende.

Nano:

Dein neuer pes2ts Code ist für die aktuelle Version 0.0.4, oder?

Den ringbuffer einzubauen, waäre jetzt natürlich erstmal der nächste logische Schritt.

Das mit dem OSD-Fade würde ich mir aber nochmal überlegen. Mein Vorschlag wäre, sich mal genauer mit dem RFB-Zeugs zu beschäftigen und 'echte' Alpha-Transparenz einzubauen. Dauert zwar deutlich länger, ist dann aber auch gleich die endgültige Lösung. Nano hat ja gesagt, daß ffnetdev Alpha-Informationen liefern kann.

@DonMartin:

Füge in Deiner remote.conf mal die Einträge aus meiner readme ein. Danach sollte kein neuer Anlernvorgang mehr erfolgen.

Ciao,

pacemaker

Hallo,

nochmal zu meiner Frage:

Zitat

Füge in Deiner remote.conf mal die Einträge aus meiner readme ein. Danach sollte kein neuer Anlernvorgang mehr erfolgen.

Irgendwie verstehe ich das ganze noch nicht richtig oder bei mir geht noch was schief:
Ich lerne die Keys an und diese werden in die remote.conf eingetragen. Dort sehe ich sie auch. Doch egal ob die Keys vorher angelernt wurden oder ich die remote.conf von Hand bearbeitet habe, beim nächsten Start (mit /etc/init.d/vdrdevel (re)start) werde ich wieder nach den Keys gefragt!
Wenn ich nun die remote.conf ansehe fehlen die Einträge für ffnetdev wieder?! Wer löscht mir die neuen Einträge?

@DonMartin:

Ja, bei Dir geht irgendwas schief. Sobald die erste Zeile für ffnetdev in der remote.conf steht, sollte kein neuer Anlernvorgang erfolgen. Eine Erklärung dafür bzw. was die Einträge löscht, kann ich Dir leider auch nicht sagen.

JuNuVDR:

Experimintier erstmal damit, die Transparenz manuell zu setzen und zu beobacht, wie sich das Ganze am Bildschirm auswirkt.

Den fest eingetragenen Wert 3 ( Zeile: int nTransparency = 3; ) habe ich auch nur exprimentell herausgefunden. Schau mal, ob wirklich alle Werte zwischen 0 und 8 Sinn machen.

Apropos debugging: Das war zuerst auch mein Problem.

Ich hab bei meiner DBox die Start-Files so modifiziert, daß er Neutrino nur dann automatisch startet, wenn ich NICHT per FTP eingeloggt bin. Dadurch kann ich dann neutrino im der Telnet-Shell manuell starten. Alle Debug-Ausgaben hat man dann im Telnet-Fenster. Logfiles gibt's auf der Dbox logischerweise nicht.

Einfacher wäre natürlich eine Yadd zu verwenden und vom Netzwerk zu booten.

Wenn Du willst, schick ich die mal meine Modifikationen im Startfile. Macht vieles einfacher und Debugging erst möglich.

Ciao,

pacemaker

In einem Script in /etc/init.d wird neutrino gestartet.

Dort baust Du dann vor dem Neutrino-Aufruf (nachdem die Dämonen gestartet wurden) ein sleep 10000000 ein.

Nach einem Neustart verbindest Du Dich dann per Telnet mit der DBox und startest Neutrino einfach per Hand (/bin/neutrino -u -f), so wie es halt im Script gemacht wird.

Die Logausgaben erscheinen dann in dieser Telnet-Console.

Auf Deine Frage hab ich absichtlich nicht geantwortet. Dachte, Du merkst es nicht
Möchte mich eigentlich derzeit nicht festlegen. Aber wie Du gemerkt hast, verfolge ich den Thread (auch die anderen) natürlich noch mit Interesse.

Der Hauptgrund, weshalb ich nicht so recht mitziehe ist, daß ich mir mittlerweile meinen VDR in den Keller gestellt habe und eine SVideo-Leitung im Wohnzimmer habe. Zudem fehlt mit wie immer dir Zeit.

Bis bald.

Pacemaker

Hallo DonMarti,

zu Deiner Frage:

Zitat

Irgendwie verstehe ich das ganze noch nicht richtig oder bei mir geht noch was schief:
Ich lerne die Keys an und diese werden in die remote.conf eingetragen. Dort sehe ich sie auch. Doch egal ob die Keys vorher angelernt wurden oder ich die remote.conf von Hand bearbeitet habe, beim nächsten Start (mit /etc/init.d/vdrdevel (re)start) werde ich wieder nach den Keys gefragt!
Wenn ich nun die remote.conf ansehe fehlen die Einträge für ffnetdev wieder?! Wer löscht mir die neuen Einträge?

Ich weiß nicht, wie die Datei /etc/init.d/vdrdevel bei Dir aussieht, bei mir (c't VDR) wird darin die remote.conf immer neu zusammengebaut. Damit die Änderungen erhalten blieben, musste ich eine Zeile

REMOTES="$REMOTES ffnetdev"

am Ende der Funktion activeremotes einfügen. Wie sieht's bei Dir aus?

Bis demnächst,
Armin

ARK

vielen Dank!!
Genau da lag der Hund begraben. Bei mir läuft auch der c't-VDR.
Ich hätte da noch Tage mit dem Problem verbracht.

Danke
DonMarti

hi

Super Arbeit bis jetzt.
habe vdrviewer jetzt auch am laufen, mit bild und ton aber natürlich stotert alles. Habt ihr daran weiter gearbeitet oder ruht das Projekt gerade ?

Edit: Naja jetzt stotert, nur bei ARD und wenn man die aufnahmen schaut ist es wie ob man spuhlt

PS: Fals ihr noch weiter macht ich bin gehrne ein betatester kann auch bei bedarf logs schicken

Hi JuNuVDR,

geb bitte nicht auf!
Wir brauchen dich!

DonMarti

Hallo,

hab mir auch mal die CDK aufgesetzt und etwas an dem Plugin rumprobiert. Ich habe festgestellt, dass nach dem auskommentieren von folgender Zeile in fbvnc.cpp beim mir das Bild ein paar Minute flüssig läuft.

dprintf("Puffergroesse %d, Gelesene Bytes: %d\n",rSize, rd);

Vermutlich können die Daten über die serielle Schnittstelle nicht schnell genug übertragen werden.

Kann fielleicht jemad testen ob es bei euch auch so ist.

Hi Zwer2k,

leider fehlt mir die Muse mir das Plugin selbst zu bauen bzw. mir das System entsprechend aufzubauen. Aber wenn du ein fertiges Plugin zur Verfügung stellt, dann werde ich es natürlich gerne testen.

ciao
DonMarti

Versuch es mal damit
http://vdr.computer-wiki.de/dbox/dbox.tar.bz2
ich kann aber nicht garantieren das es geht, da die Datei wie es aussieht Debuginformationen enthält. Ist um einiges grösser als die Datei von pacemaker.

Hi Zwer2k,

hatte es gestern versucht, aber leider dabei (fast) meine dbox "zerschossen".
Das File war einfach zu groß :(. Fast hätte es drauf gepasst. Leider hat das jffs ein Problem mit dem Freigeben von Dateien, wenn das Dateisystem voll ist. Jetzt kann ich leider nichts mehr auf der dbox löschen, kopieren, umbenennen, ...
Werde die dbox neu flashen müssen. Leider werde ich es vermutlich diese Woche nicht mehr schaffen :(.
Wenn du es schaffen solltest einen Release-Build hinzubekommen (damit die Filegröße wieder schön klein ist), werde ich es aber sobald wie möglich wieder versuchen.

bis denn
DonMarti

Hier mal ein Release. Es verlangt aber nach libstdc++.so.6, Image das ich vorzugsweise benutze enthält aber libstdc++.so.5, bei neueren Images sollte es aber gehen. Wenn jemand eine Idee hat, wie ich es mit meinem Image laufen lassen kann, lasst es mich wissen.