Beiträge von stefan4812

    Hallo allerseits,
    bei meiner Duo Flex S2 mit 6 Tunern treten auf allen Kanälen TS Fehler auf, die sich durch nerviges Klötzeln bemerkbar machen.


    Das passiert bei mit in folgenden Konfigurationen:
    i) Ubuntu Trusty, mit Kernel 3.13 oder kernel 3.16 mit dem media_build_experimental gebaut nach Anleitung. Dabei ist es egal, ob ich msi= 0 oder 1 gesetzt habe.


    ii) Ubuntu Trusty mit Kernel 3.13 oder Kernel 3.16 mit dem standard upstream dvb Treiber.



    Das Problem tritt nicht auf, wenn ich:
    Ubuntu Trusty mit Kernel 3.13 und ein altes media_build benutze, dass ich zufällig von der dvbsky Seite nutze (media_build-bst-13-140619.tar.gz heisst das dort) nutze.


    Um meine Aufnahmen zu untersuchen nutze ich das vdr-checkts program von e-tobi. (http://projects.vdr-developer.org/git/vdr-checkts.git/tree/)
    Meine Hardware ist ein H87 Board mit einer i3-4330 CPU. Ich nutze die fnu Pakete für ubuntu Trusty.


    Nun die Frage an Euch: Habt Ihr auch diese TS Errors? Eventuell könnt Ihr ja mal ein paar Eurer letzten Aufnahmen einfach mal checken!


    UFO sag mir, was ich an Daten liefern soll, ich helfe gerne mit, das Problem, wenn es ein allgemeines sein sollte, einzugrenzen.


    Ich vermute, dass sich durch eine Treiberänderung das Problem bei mir eingeschlichen hat. Da ich ja eine funktionierende Konfiguration habe, würde ich ein HW Problem eher ausschliessen wollen. Im übrigen wenn ich die Digital Devices Karte durch zwei DVB Sky Karten ersetze (was ich nur zur Testzwecken gemacht habe) haben ich auch keine TS Fehler.


    Stefan

    Ich habe MSI-X deactiviert mit:
    options ddbridge msi=0
    in einem File unter /etc/modprobe.d
    Default ist, dass MSI-X aktiviert ist.


    Ich habe heute Abend übrigens (vor dem Gewitter) noch mal getestet, auch mit deaktiviertem MSI gab es jede Menge ts Errors.


    Blöderweise treten diese Fehler mit dem uralt Stand des Treibers nicht auf (der aus MSI deaktiviert)
    Ich nutze zum testen die Version, die von DVBSky zur Verfügung gestellt wird, dort ist ein alter Stand für ddbridge enthalten.

    Hallo allerseits,


    ich habe noch etwas rumprobiert, um meine ts Errors einzugrenzen.
    Als Programm nutze ich vdr-checkts von e-tobi, um die Aufnahmen zu prüfen.


    Meine Konfiguration:
    Digital Devices Karte v6; Trusty Kernel (3.13); media_build_experimental; vdr 2.1.6.


    MSI Board (H87M-G43) mit H87 Chipsatz, neustes BIOS, Standard Einstellungen.

    Bei mir sieht es so aus, dass ich Errors bekomme, wenn MSI-X enabled ist, keine Errors mehr, wenn ich MSI-X disable!
    Die Fehler treten bei mir etwa alle 10 Minuten auf.
    Eventuell bleiben die bei vielen unbemerkt!?

    Hat jemand eventuell auch ein H87 Board und probiert das mal aus?
    Das vdr-checkts bekommt man von hier: http://projects.vdr-developer.org/git/vdr-checkts.git/

    Hallo allerseits,
    ich habe folgendes beobachtet:
    Nutze ich eine alte version des ddbridge Treibers (bei mir ist das die Version 0.5) läuft alles gut.
    modinfo
    Als Frontendtreiber habe ich den stv090x, da ich eine Digital Devices Karte V. 6. habe.


    Nutze ich die des aktuellen Trusty Kernels 3.13 (Version ist auch mit 0.5 bezeichnet) , oder die Version von mediabuild-experimental (Version 0.9.14) habe ich sporadisch (alle 10 Minuten) klötzeln.
    Ich habe mal das alte vdr-checkts program über die Aufnahmen laufen lassen und entsprechend viele Errors bekommen.
    Unabhängig, ob ich MSI aktiviert oder deaktiviert habe.


    Ansonsten ist die Konfiguration Identisch: 3.13 Kernel, vdr 2.1.6 von fnu, mein Mainbord ist ein MSI H87 board.


    Hat jemand einen Tip. Was kann ich liefern, um den Fehler konkreter einkreisen zu können?
    Im Syslog habe ich übrigens nichts gefunden.

    Hallo,
    bei mir kam das tearing durch das fehlerhafte eingeschaltete backingstore.


    Wenn man den X Server mit -bs startet ist das tearing verschwunden.
    Hatte ich im anderen Post schon geschrieben. Hätte vermutlich hier besser gepasst.



    Hier das conf file von lightdm:
    cat /usr/share/lightdm/lightdm.conf.d/50-xserver-command.conf
    [SeatDefaults]
    # Dump core
    xserver-command=X -bs -core



    Ich habe das bei https://bugs.launchpad.net/ubuntu/+sourc…er/+bug/1278012 gefunden.




    Stefan

    Hallo allerseits,


    Ich habe ein Trusty mit fnus ppa für meinen VDR genommen.


    fnu: Danke für Dein PPA es läuft bei mir sehr gut.



    Ärgerlicherweise hatte ich nerviges tearing mit vdr-sxfe auf meinem zweiten Monitor. Grund ist nicht der nvidia Treiber sondern eine neue version von Xorg: 1.15, die fehlerhafterweise backingstore enabled hat. Bei 1.14 war das noch nicht der Fall. Abhilfe schafft das backingstore wieder abzuschalten und zwar nicht im xorg.conf file sondern beim starten von X selber:
    Make sure you have the "-bs" option in lightdm config file:
    cat /usr/share/lightdm/lightdm.conf.d/50-xserver-command.conf
    [SeatDefaults]
    # Dump core
    xserver-command=X -bs -core



    Ich habe das bei https://bugs.launchpad.net/ubu…/xorg-server/+bug/1278012 gefunden.


    Stefan

    Hallo allerseits,
    hier die Version von EasyStream für MacOSX.


    Das ist die fertige App, die die USB, QT, libvlc enthält und auf 10.8 laufen sollte.
    Attached die Files, die ich anpassen musste.
    Falls jemand das selber komplieren möchte, geht das nur als ObjectiveC++ (wegen des Video Fensters)
    Eine Anpassung bezieht sich eher auf libvlc von VLC 2.1 (in player.cpp)
    Ich habe leider keine Diffs gebaut, sorry dafür, aber die Änderungen sind minmal und einfach zu verstehen.


    Stefan


    Hier die Version für 10.8:


    https://www.dropbox.com/s/9s4imwf5l8i9bu5/EasyStreamMac.zip



    Hier die Version für MacOSX 10.7:
    https://www.dropbox.com/s/dkm0…r8/EasyStreamMac-10.7.zip

    Hallo,

    nach 3 Wochen Urlaub (ohne Computer/Smartphone/Internet) kann es jetzt mit dem EasyStream Projekt weiter gehen.

    stefan
    Danke für die Infos zu MacOSX.
    1. Die USB libs sind für EasyStream nicht zwingend notwendig (in der Windowsversion sind die nicht eingebaut) damit läuft nur ein Eigenbau-USB-IR-Receiver.
    2. Welche Änderungen müsste ich im Quellcode einbauen, damit EasyStream auch unter OSX gebaut werden kann.
    3. EasyStream.app kann ich als Link oder direkt in die EasyStream Seite übernehmen.

    Gruß Sig

    Da ich auf dem Desktop in der Mac Welt zuhause bin: Wäre auch eine Mac OSX Version technisch möglich bzw. denkbar?

    Hallo allerseits,
    ich habe EasyStream auch unter MacOSX zum laufen gebracht.
    Grob gesehen habe ich folgendes gemacht:
    i) Qt 4.8 installiert
    ii) dann die Include/Library Files im easystream.pro file angepasst
    iii) mit qmake ein Xcode Projekt generiert (dabei isa = PBXFrameworkReference ersetzt durch: lastKnownFileType = wrapper.framework; , scheint ein Qt 4.8 /Xcode Problem zu sein)


    iv) Die USB lib besorgen und für den Mac compilieren, dabei die alte und die neue compilieren (die alte wird durch die neue emuliert, der default geht dann nach /usr/local/lib)
    iv) dann im player.cpp ein paar Änderungen gemacht:
    a) bei Eingabe der MRL "libvlc_media_new_path" durch "libvlc_media_new_location" ersetzt (das scheint aber eher ein Thema der VLC Version zu sein, ich habe die nighthly builds der 2.1 genommen)
    b) bei der Definiton des Video Fensters ein NSObject eingefügt (ebenso entsprechendes include im Header Bereich)
    v) Das ganze dann als ObjectiveC++ übersetzt (im Xcode kann man einstellen, dass auch .cpp files als ObjectiveC++ compiliert werden.


    Die Hexerei mit den dylibs (BSD....):
    a) die USB libs baue ich ein (habe ich aber nicht getestet, obs läuft).
    b) ebenso die libvlc (Ich werde die 2.1 daily builds nehmen)
    Beide Libs sind dann in dem Applikation Ordner EasyStream.apps enthalten.
    Ebenso habe ich die Qt....Framworks eingebunden, damit man nicht Qt installieren muss, wenn man das Programm nur laufen lassen möchte.





    Offen für mich:
    i) USB Support zwar eingebaut, aber nicht getestet
    ii) die Graphik HW Beschleunigung auf dem Mac einschalten



    Bei Interesse (deshalb schreibe ich das ja) kann ich EasyStream.app gerne posten, die File Änderungen (easystream.pro, player.cpp) sowieso.



    Stefan

    Hallo allerseits,
    nachdem ich massive Probleme mit VDPAU hatte (Ich benutzte immer die 260.* Treiber von Nvidia):
    z.B. Tonaussetzer nach ein paar Sekunden;
    Oder noch schlimmer:
    Wenn ich ein vdr-sxfe Fenster offen hatten, konnte ich keine weiteren Fenster mehr auf dem Desktop öffnen, bis sich vdr-sxfe verabschiedet hatte.


    Möchte ich heute etwas positives vermelden:


    Mit dem neuen Treiber:


    nvidia-current aus der unstable version von yavdr in der Version 260.19.29


    treten obige Probleme nicht mehr auf!


    Meine Konfiguration:
    GTX 460
    Lucid (up to date)
    Aktuelles yavdr 0.3 mit xinelib 1.2 (mit DF patch V16).
    xineliboutputplugin von yavdr 0.3
    nvidia 260.19.29.


    Für mich stellt das einen Durchbruch dar und ich kann X-Mas auf HD umsteigen.


    Ein herzliches Dank and DF und natürlich an die yavdr Entwickler!
    Ich finde Eure Arbeit super!


    Stefan

    Hallo Durchflieger,
    ich benutze via yavdr 0.3 Deinen patch in der Version 16.


    (Edited: Das Problem ist UNABHÄNGIG vom DF patch, ich schreibe das hier nur der Vollständigkeit halber noch mal in den Thread)


    Folgendes Phänomen:
    Ich habe ein vdr-sxfe Fenster geöffnet (fullscreen oder nicht ist egal) und nutze via xineliboutputplugin VDPAU zum rendern des VDR Bildes.



    Wenn ich die xinelib 1.2 mit VDPAU benutze,
    friert mir fast immer der ganze Desktop ein, sobald ich ein oder zwei neue Fenster aufmache (egal, ob Browser, oder Terminal oder...).


    Ich habe das Problem jetzt auch mit der ungepatchten Version der xinelib 1.2.


    Daher gehe ich jetzt wieder davon aus, dass bei mir die Kombination Treiber (Nvidia latest via yavdr 0.3, X org via lucid, und HW GTX460) mir einen Streich spielt.


    Blöderweise tritt das Problem "manchmal" nicht auf. Ich habe nicht experimental informatisch rausfinden können, was die Ursachen sein können. Sieht nach einem initialisierungs Problem o.ä. aus.



    Erst ist der Ton weg, dann hängen alle Fenster, keine Manipulation ist mehr möglich.
    Dann stürzt vdr-sxfe ab, und der Desktop ist wieder responsive.


    Es sieht so aus, als ob der Fokus vom vdr-sxfe Fenster nicht freigegeben wird, und dadurch der ganze X Server/Window manager hängt, da die neuen Fenster nicht angezeigt werden können.


    Das Phänomen tritt bei der Standard Installation von yavdr 0.3 auf, das gleiche bei einem standard ubuntu lucid mit dem xinelib 1.2 paket von yavdr.



    Meine Konfiguration ist simpel:
    Intel P35 Mainboard mit GTX460 Karte, Nova HD2 DVB Karte, Ubuntu lucid und/oder yavdr 0.3.



    Grüße Stefan