Beiträge von spitzb

    Zitat

    Ich gebe das HDMI Signal über SPDIF an einem Reciever weiter. Hier kommt dann nur noch PCM an.

    Vom VDR per HDMI zum TV und dann per SPDIF zum Receiver? Dann gibt deine Glotze nur PCM weiter! Du musst nicht glauben, dass ein TV den Ton-Anteil aus dem HDMI nimmt und den ungefiltert wieder ausgibt.


    Der korrekte Weg wäre eigentlich VDR -> Receiver -> TV. Dann greift der Reiceiver den Ton ab und gibt nur das Bild an den TV weiter.


    Falk

    jo, das hab ich mir auch schon gedacht, dass das blöd ist...ist im Git gefixt.

    Jetzt kann man den schnellen Vor/Rücklauf von der Zeitlupe unterscheiden. Super!


    Und gleich noch einen Glückwunsch und ein dickes Danke für die schicke Oberfläche :tup


    Falk

    Hmm. Jetzt sieht das natürlich bei Zeitlupe genauso aus wie bei schnellem vor/Rücklauf. Könntest du vielleicht Pause zusätzlich aktiv lassen? Dann sieht man das es Zeitlupe ist.


    Falk

    Moin!


    Ich schlage vor, einfach mal wieder ein update & dist-upgrade zu machen, damit wir sehen können, ob das Problem mit dem aktuellen Paket noch existiert.
    Wenn nicht, dann ist es gelöst. :)


    Lars.

    Habe ich gemacht und es läuft weiterhin alles, jetzt sogar mit nOpacity 0.1.1


    Ich war mir keines Fehlers bewusst, besonders, weil das System noch recht frisch war und ich noch keinerlei Experimente damit gemacht hatte.


    Ich wollte nur auf das Problem hinweisen.


    Falk

    eben beim 2. punkt ist es immer interessant zu wissen, was und wie das kompiliert/installiert wurde. eben weil 99% aller fehler da gemacht werden.

    Was ich da installiert habe, darf ich hier nicht schreiben. Es war aber vorher auch schon vorhanden und wurde nur neu übersetzt. Deshalb vermute ich da keinen Zusammenhang. Zumal der Fehler auch noch auftrat, nachdem ich das ungenannte plugin vorübergehend herausgenommen hatte.

    gda


    Code
    apt-cache depends vdr-plugin-skinnopacityvdr-plugin-skinnopacity  Hängt ab von: libc6  Hängt ab von: libgcc1  Hängt ab von: libmagick++4  Hängt ab von: libstdc++6  Kollidiert mit: vdr-plugin-skinnopacity:i386



    und


    Code
    ldd /usr/lib/vdr/plugins/libvdr-skinnopacity.so.2.0.0        linux-vdso.so.1 =>  (0x00007fff751bb000)        libMagick++.so.4 => /usr/lib/libMagick++.so.4 (0x00007f949a262000)        libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f9499f62000)        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f9499d4b000)        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f949998c000)        libMagickWand.so.4 => /usr/lib/libMagickWand.so.4 (0x00007f9499677000)        libMagickCore.so.4 => /usr/lib/libMagickCore.so.4 (0x00007f94991f3000)        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f9498ef7000)        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f9498cda000)        /lib64/ld-linux-x86-64.so.2 (0x00007f949a732000)        libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007f94989a5000)        libgomp.so.1 => /usr/lib/x86_64-linux-gnu/libgomp.so.1 (0x00007f9498797000)        liblcms.so.1 => /usr/lib/x86_64-linux-gnu/liblcms.so.1 (0x00007f9498560000)        libfreetype.so.6 => /usr/lib/x86_64-linux-gnu/libfreetype.so.6 (0x00007f94982c3000)        liblqr-1.so.0 => /usr/lib/liblqr-1.so.0 (0x00007f94980af000)        libfontconfig.so.1 => /usr/lib/x86_64-linux-gnu/libfontconfig.so.1 (0x00007f9497e79000)        libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 (0x00007f9497c67000)        libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 (0x00007f9497a57000)        libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f9497840000)        libltdl.so.7 => /usr/lib/x86_64-linux-gnu/libltdl.so.7 (0x00007f9497635000)        libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007f9497417000)        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f9497213000)        librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f949700a000)        libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0 (0x00007f9496d15000)        libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 (0x00007f9496aea000)        libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007f94968e7000)        libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007f94966e1000)        libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007f94964a3000)


    Irgendwie gehen mir in den "code" feldern immer die Zeilenschaltungen verloren.


    Falk

    Außerdem ist doch jetzt endlich Frühling, seit dem Wochenende sind's hier endlich ab und zu über 10°C! Und es scheint sogar ein bisschen die Sonne!

    Hier sind's sogar schon über 20 Grad. Liegt vielleicht an den erhitzten Gemütern. :D


    Zitat

    Letztendlich wollen wir alle doch einfach nur dabei helfen, den Fehler zu finden. Lasst uns das bitte tun

    Gute Idee, hat denn nach meiner nun etwas genaueren Beschreibung eine Idee, wie es dazu gekommen sein könnte. Ich habe das Problem für mich zwar gelöst, aber andre könnten noch drüber stolpern

    Wenn Dein letzter Post Dein Erster gewesen wäre, hätte niemand was gesagt

    Ich kann mich noch gut an meinen ersten Post im yaVDR - Bereich erinnern. Da bekam ich Prügel für ein nett gemeintes Dankeschön.


    Mein zweiter Post in selbigem Bereich, in dem ich höflich gefragt habe, warum man denn einige Meldungen in einer fremden Sprache formuliert habe, wurde ich auch gleich angefahren, nach dem Motto: "Wenn dir das nicht gefällt, mach doch selbst was besseres."


    Ich hatte bei den Vollprofis geglaubt, das yavdr-testing + Plugin-Name + eine kurze Beschreibung dessen, was ich zuletzt gemacht habe und was das für Folgen hatte, ausreicht.


    Ich bin selbst professioneller Entwickler (in einem gaaanz anderen Umfeld), bekomme von meinen Kunden aber auch manchmal Fehlermeldungen wie "es druckt nicht". Da kann ich auch nicht gleich beleidigt um mich hauen. Ihr kriegt zwar kein Geld für Eure Arbeit, aber etwas Höflichkeit und Rücksicht auf nicht ganz so Wissende sollte doch möglich sein.


    Obwohl ich yaVDR immer noch für eine Spitzen Lösung halte, tut mir der Wechsel schon fast leid, weil man bei jeder Frage oder der kleinsten Kritik gleich der Böse ist.


    Ach ja, wenn ich mich auch schon eine Weile hier im Forum herumtreibe und so manchen Post verfasst habe, heißt das noch lange nicht, dass ich mich auskennen muss. Die gesamte Debian - Paketverwaltung (aptitude, dpkg, etc) ist für mich immer noch ein Buch mit sieben Siegeln. Da bin ich blutiger Anfänger.


    Falk

    Wo sind denn die yaVDR Profis?

    Von denen habe ich erst mal Mecker bekommen. Ich hatte im yaVDR - Bereich mal über mein Problem berichtet und dabei leichtsinnigerweise Deine Versionsinfo (0.1.1) übernommen. In yaVDR testing ist aber noch eine 0.1.0 - irgendwas. Aber egal.


    Was mir noch auffiel: Wenn man bei einer Wiedergabe auf Pause stellt, kann man ja mit den Pfeilen rechts/links Zeitlupe vorwärts/rückwärts in 3 Geschwindigkeitsstufen auswählen. Da fehlt dann aber die Anzeige dass Zeitlupe läuft. Es sieht weiterhin aus wie Pause.


    Falk

    Sorry für die falsche Versionsangabe für das Plugin. Ich hatte dem Autor des Plugins einfach geglaubt, dass er weiß, ab welcher Version welche zusätzlichen libs benötigt werden.


    Hier noch mal (genau), wie die Entstehungsgeschichte war:


    - yavdr 0.5.0 installiert
    - testing ppa's hinzugefügt
    - dist-upgrade durchgeführt
    - Plugin skinnopycity installiert
    - ein weiteres Plugin selbst gebaut und installiert
    - VDR einige Tage benutzt
    - nochmals dist-upgrade durchgeführt
    - Plugin nOpacity produziert SEGFAULT
    - Plugin nOpacity de-installiert (apt-get remove)
    - VDR funktioniert


    - Plugin nOpacity neu installiert (apt-get install)
    - wieder SEGFAULT
    - nach Rücksprache mit Plugin Autor paket "curl" installiert (apt-get install curl)
    - nOpacity funktioniert wieder.


    Wenn die Abhängigkeiten alle ok wären, hätte das fehlende Paket ja schon bei der ersten Installation von nOpacity mit installiert werden müssen, oder aber, das Plugin hätte da schon versagt. Scheinbar hat aber bei der ersten Installation nichts gefehlt. Es wurde aber auch definitiv nichts de-installiert. Das Problem trat unmittelbar nach dem 2. dist-upgrade auf, bei dem nOpacity aktualisiert wurde. Unmittelbar danach hat's gekracht, während unmittelbar davor alles ok war.


    Vielleicht hat es ja an genau dieser Vorgehensweise gelegen, dass da irgendwelche Abhängigkeiten durcheinander gekommen sind.