Posts by SHF

    Nachtrag:

    Seit damals läuft mein VDR mit den beiden Patches aus Beitrag 49 und 51 im täglichen Betrieb.

    Irgendwelche Probleme konnte ich nicht feststellen.

    Gefühlt ist die Menge an zu kurz geratenen Aufnahmen aber zurück gegangen.


    Ich halte die Transponderbindung fürs EPG inzwischen für sicher und meine, man sollte die generell einführen, um derartige EPG-Probleme in Zukunft auszuschliessen.

    Das Problem mit der FrameRate hatten schon andere. Eigentlich müsste es mehrere Themen dazu geben.

    Auf die Schnelle konnte ich aber nur das folgende finden:

    RTL: Anzeige der Aufnahmedauer falsch, info / index falsch, 50fps statt 25fps

    (leider nicht wirklich hilfreich)


    Warum erfordern Aufnahmen mit doppelter Frame-Rate nicht doppelt so viel Speicherplatz wie anderer Aufnahmen?

    Der Platzbedarf wird hauptsächlich durch die Veränderungen zwischen den Bildern bestimmt.

    Für den Platzbedarf der unveränderten Bildteil mach die Framerate praktisch fast keinen Unterschied.

    Habe bemerkt, dass ich einige Aufnahmen nicht abspielen kann und der VDR ohne weitere Fehlermeldung beendet wird:

    Seit dem Umstieg von VDR 1.4.x auf 2.0.x ist mir das auch ein paar mal passiert.

    Ob der VDR dann neu startet oder nur eine Weile hängt, kann ich aber nicht sagen.


    Geholfen hat bislang immer das Löschen der Index-Datei der Aufnahme.

    Nach dem der VDR den Index neu erstellt hat, ging die dann wieder einwandfrei.


    Wenn möglich Index-Datei umbenennen, so dass man die nachher vergleichen kann. Mir ist das leider immer zu spät eingefallen.



    Mein Eindruck ist, dass diese Macken bei der Umstellung auf .ts rein gekommen sind.

    Seit dem läuft bei mir der Ton oft nicht mehr ganz synchron und es gibt gelegentlich Störgeräusche bei Sprüngen.

    Dann scheint bei der Wiedergabe von Aufnahmen die Fieldorder durcheinander zu geraten, was zu ausgefransten Laufschriften führt.

    Und dann noch das o.g. Problem.


    Ich hatte anfangs einige "Problemfälle" mal mit Project-X angeschaut, aber keine Fehler gefunden.

    Dies Thema bringt mich aber auf die Idee, ob das Problem etwa in der Index-Datei liegen könnte? Da fallen Fehler praktisch kaum auf. Vdr-checkts testet die Index-Datei AFAIK ja auch nicht.

    Die Index-Datei ist ja irgendwie für die Zugriffe auf die TS-Pakete zuständig, damit indirekt auch fürs timing. Wäre es denkbar, dass die o.g. Fehler an einem defekten Index liegen?

    Mit der Ton Synchronität, bin ich ja nicht der einzige, dem das aufgefallen ist.

    Hmmmm..... da gibt es ein Problem mit dem Lüfter, wenn man die "WakeUp" Funktion aktiviert hat. Der Lüfter läuft natürlich weiter wenn der Pi aus ist....

    Was passiert, wenn du den PWM-Eingang vom Lüfter mit Masse verbindest? (Wichtig: natürlich ohne PI dran!)

    Ich bin nicht sicher, ob der Lüfter dann überhaupt anhält.

    Wenn nicht, muss man ihn wirklich vom Strom trennen.

    Die meisten Beamer kann man inzwischen umgedreht an der Decke montieren, das ist vom Hersteller so vorgesehen. Dass dann der Lüfter, ausgelöst durch das Umdrehen des Bildes, lauter wird höre ich aber zum ersten mal.

    Man könnte mal den Gegenversuch machen und den Beamer richtig herum hinstellen und das Bild umdrehen lassen. Wenn es dann laut wird liegt es sicher nicht an der Einbaulage.


    Ich würde als Zuspieler einen mini PC empfehlen. Intel NUC oder was in der Art.
    Die brauchen heute kaum mehr als 10W und man ist frei in der Software-Auswahl.

    Nach dem, was ich gelesen habe, soll auch die Intel-Grafikeinheit soll das Bild beschleunigt drehen können. Probiert habe ich das aber noch nicht ausgiebig.

    Woran liegt das? Kennt jemand das Problem?

    Fehlermeldungen gibt es keine, es spult nur einfach nicht, oder mal spult es schnell vor, dann kann man es aber nicht mehr stoppen und muss den

    Film abbrechen. Alles sehr unschön und ärgerlich, da bei SD es ohne Probleme geht.

    Xine zeigt ohne Hardwarebeschleunigung hier auch dieses Verhalten.


    Probier mal mit Xine direkt eine HD-Datei abzuspielen, ob es da auch auftritt.


    installiert ist mesa-vdpau-drivers 10.3.2-1+deb8u bzw. vdpau-va-driver 0.7.4-dmo5

    Die gehören beide nicht zum NVIDIA-Driver. -> weg damit!

    Der korrekte sollte "nvidia-legacy-304xx-vdpau-driver" heissen. Versionsnummer muss identisch mit der des NVIDIA-Drivers sein.


    Dann sicherstellen, dass auch wirklich VDPAU benutzt wird.

    Dazu zB. vdr-sxfe mit --verbose=2 aus einer Konsole starten, da wird das angezeigt. (Ich verwende Xine nicht vdr-sxfe, da kann die Option evtl. anders heissen)

    Ich verstehe das Problem mit dem Tacho Signal noch nicht ganz. Dort wird auf die Möglichkeit einer Beschädigung des Pi's hingewiesen...

    Man könnte den Ausgang des Pi durch Kurzschluss oder Überspannung beschädigen.


    Ein Widerstand von 1...5 kOhm in der Leitung sollte IMHO als Schutz aber ausreichen.

    Am Lüfter wird ja nicht rum gebastelt, Elektrostatische Aufladungen sind nicht zu erwarten.

    Interessanter finde ich dieses Schaltbild aus dem User guides:

    Da sieht man ganz gut, wie die Netzteile zusammen geschaltet werden.


    SHARE +/- Pin 6 und 7 sollte vermutlich zu den Ausgangspins 5VShare +/- bzw 12VShare+/- auf den Leiterplattenverbinder gehen.

    Denke ich auch.


    Sense Pin 2 wäre auch noch interessant.

    Der IC misst damit aber den Strom, das kann nach hinten los gehen.


    Ich würde es eher einen Widerstand von Pin 3 (ADJ) gegen Masse versuchen.

    Aber wie geschrieben, das wäre ein Versuch.

    ganz so trivial ist die Sache leider nicht. Ich habe 12 ICs gezählt, alle mow. niedrig integriert. Ein hochintgrieter IC und dann die Herstellerapllikation wäre zu schön gewesen.

    Das sind deutlich mehr ICs, als ich erwartet habe. Üblich ist etwa ein drittel davon.


    mit viel Mut zum Risiko könnte man folgendes angehen. Beim TDA 16888 --> http://dalincom.ru/datasheet/TDA16888.pdf


    und der Appl. Note dazu --> http://cdn14.21dianyuan.com/download.php?id=80683 Seite 6 ist eine Standard Applikation zu sehen. Dort sind Optokoppler als Feedbackpfad zu sehen, die die Rückführung von der Sekundär zur Primärseite ermöglichen.

    In der App Note sollten die Widerstände um IC2 interessant sein.

    Die wird es aber in diesem Netzteil nicht geben.


    Auf meinem letzten Bild sind zwei Stück Load Share Controller UC3902 zusehen

    Daran, dass man die NTs parallel schalten kann, hatte ich nicht gedacht.

    Aber da die aus irgendwelchen professionellen Servern stammen, ist es natürlich logisch, dass sowas geht.


    Die Ausgangsspannung muss also irgendwo im Bereich dieser Controller definiert werden.

    Das erklärt auch, warum die nichts einstellen kann.


    Im Datenblatt steht was vom Masterunit, die die Spannung definiert, ich denke da müsste man ansetzen.

    Zum UC3902 gibt es ausser diesem Datenblatt noch eine Anleitung und eine App-Note, wo der Aufbau so einer Schaltung recht ausführlich beschrieben ist. Inklusive Schaltplänen.

    Ich denke damit wird man was anfangen können. Der Interessante Punkt ist am Ausgang dieser Controller, da von da aus die Spannung beeinflusst wird. Bei dem Haufen von Bauteilen, die auf dem NT verbaut sind, kann das da auch schon kniffelig werden.

    oder wenigstens einen Schaltplan

    Wenn man die Bezeichnung den verbauten Steuer-ICs hat, könnte dessen Datenblatt weiter helfen. Da sind eigentlich immer Schaltungsvorschläge drin und die Netzteil-Hersteller orientieren sich meist daran.


    All zu viele Spannungsteiler wird es am 12V Ausgang doch nicht geben..

    Spannungen werden üblicherweise möglichst nahe an der Last gemessen um die Leitung auszuschliessen.


    In dem Bild weiter oben sieht man derartige Leiterbahnen direkt beim Stecker abzweigen:

    43562-astec-aa21660-4-jpg

    Die beiden dünnen Leiter an den dicken +5V und +12V Bahnen meine ich.

    Der Jumper bei +12V könnte auch interessant sein.


    Vielleicht ist es aber noch viel einfacher.

    Eigentlich alle PC-Netzteile haben innen ein Poti mit dem die Ausgangsspannung im Werk fein justiert wird.

    Irgendwas im Bereich +-2V sollte damit möglich sein.

    Ein Blick in das Gehäuse kann also lohnen.


    Und ich würde nicht so sehr darauf bauen das das Ding wirklich dauerhaft bei Maximallast ohne Kühlung läuft.

    Bei (optimistisch) angenommen 90% Wirkungsgrad kommt man auf ~40W Abwärme.

    Das ist schon einiges für den kleinen Karton.

    Wenn man dauerhaft grössere Leistung raus zieht, sollte man die Temperatur im Auge behalten, sonst machen das die Elkos nicht lange mit.

    Der aktuelle von hg.code.sf.net/p/xine?

    Nein, original Debian-Paket.

    Das Problem besteht aber seit Jahren kenne. Ehrlich gesagt, kann ich mich nicht erinnern, das es jemals nicht existierte.

    Dann schicke mal einen backtrace an Torsten.

    Backtrace müsste ich wirklich mal machen.


    Da es immer beim Umschalten oder bei einem öffnen eines neuen Video-Files passiert, könnte es durchaus die gleiche Stelle sein.


    Die anderen Player (Mplayer. MPV, VLC und ffplay) steigen bei mir aktuell beim ersten Umschalten aus. Ich könnte schwören, dass es früher zumindest mit einem von denen ging.

    Nach meinem Verständnis bedeutet headless die Verwendung vom VDR ohne Ausgabeplugin. => kein Zugriff auf das OSD

    In dem Moment, wo vdr-sxfe verwendet wird wäre dann nicht mehr headless.


    Auch ich verwende das xineliboutput-Plugin und habe bislang keine wirkliche Alternative dafür gefunden.


    Ich verwende aber Xine als player, kann aber auch da bestätigen, dass sich der Player gelegentlich aufhängt.

    Es liegt aber IMHO nicht auf der VDR-Seite im xineliboutput-Plugin, sondern auf der des Players.

    Xine neigt auch beim abspielen von längeren Playlisten dazu sich derartig aufzuhängen.


    Man kann den RTP-Stream kann man auch mit anderen Playern wiedergeben, leider ohne OSD (siehe Readme).

    Ich hatte ein wenig mit VLC experimentiert und das schien robuster.

    Mit der aktuellen Version (heute), steigen VLC als auch Mplayer beim ersten Umschalten aus. Beim Zurückschalten auf den Ausgangskanal, läuft es aber weiter.


    Das Abspielen den Video-Streams ist / war (warum auch immer das jetzt nicht mehr geht) kein Problem. Es fehlt nur das OSD.

    Ich hatte schon daran gedacht, ob man nicht einen einfachen, xine-freien Client basteln könnte. Wirklich kümmern müsste man sich ja nur ums OSD, den Videoteil kann man ja mit ffmpeg oder einem anderen Player machen.

    Leider ist OSD-Teil von dem xvdr-Protokoll nicht wirklich dokumentiert. Die Informationen im Quellcode zusammen zu suchen und zu interpretieren, ist auch nicht mal eben gemacht, ich habe aus Zeitgründen dann irgendwann aufhört.

    In find kann man mit -exexdir auch direkt Aktionen auf gefundene Dateien in einem Verzeichnisses ausführen.

    find -type f -a \( -iname "*.mp3" -o -iname "*.loss" -o -iname "*.aiff" -o -iname "*.m4a" \) -execdir echo {} +

    {} liefert alle gefundenen Dateien dem Verzeichnis.

    In dem Beispiel muss das echo dann noch durch den eigentlichen Befehl ersetzt werden.


    Ob es in diesem Fall was ausmacht ist fraglich, aber bei grösseren Datenmengen läuft es so deutlich schneller als mit der Shell.

    Ich möchte eine Gleichspannungsversorgung schützen. Hier sind die Serienwiderstände natürlich nicht so toll, weil ständig Verlustleistung anfällt.
    Wie sollte die Schaltung sinnvollerweise geändert werden?

    Spulen an Stelle der Widerstände einbauen. (Ging hier aber nicht, da da kein DSL-Signal mehr durchkommen würde.)

    Die Induktivität der Spulen lässt die Spannung dahinter nur langsam ansteigen und schützt so die Cera Dioden.

    Vor und hinter den Spulen baut man dann noch Kondensatoren (MKP oder Keramik) zwischen die Leitungen, das dämpft HF-Störungen.

    Netzfilter werden eigentlich immer so aufgebaut, da gibt es auch einige Beispiele im Netz.

    Da durch den Filter kein HF-Signal durchkommen soll, ist das alles unproblematisch.

    Netzfundstück:

    Das sagt der Marktführer bei Routern dazu:

    AVM: So schützen Sie Ihre Geräte vor Blitzschäden

    Wo wir gerade beim Thema sind, wollte ich euch das nicht vorenthalten. :hat2


    Was ich mich im Zusammenhang mit dem ISDN-Überspannungsableiter vor allem frage: Bräuchte ich denn Sicherungen?

    Da ist anscheinend nicht mal die Telekom sicher.

    Ich habe hier 3 unterschiedliche Splitter liegen. Alle haben Gasableiter verbaut, aber nur einer Sicherungen davor.

    In den älteren DSL-Modems waren auch Gasableiter verbaut und das ohne Sicherung davor.


    Darf ich denn auf "Kundenseite" einfach so eine eventuell auftretende Überspannung kurzschließen oder besteht dann Gefahr für die Zuleitung?

    Wie sieht es denn mit Brandgefahr aus? Besteht das Risiko das mein ISDN-Überspannungsschutz, direkt am ins Haus führende Kabel, bei ausreichend "Energie" aus dem Netz einfach abbrennt?

    Wenn die Überspannung in den relevanten Bereich geht, würde ich mir eher Sorgen machen, was alles ohne Überspannungableiter passieren kann.