Posts by pinky666

    Quote

    Original von geronimo
    Gibt es einen sinnvollen Weg, die Dateien zu finden, ohne den Benutzer zu fragen?


    Quote

    Original von geronimo

    • epg.data - liegt in der ramdisk ( /ramdisk )


    Code
    1. -E FILE, --epgfile=FILE write the EPG data into the given FILE (default is
    2. 'epg.data' in the video directory)
    3. '-E-' disables this
    4. if FILE is a directory, the default EPG file will be
    5. created in that directory


    Quote

    Original von geronimo

    • channel.conf - liegt unter /etc/vdr
    • timers.conf - liegt unter /etc/vdr


    Code
    1. -c DIR, --config=DIR read config files from DIR (default: /video)


    Man sollte also durch Prüfung der VDR Start Optionen herausfinden können wo die Files liegen.

    Quote

    Original von hotzenplotz5
    pinky666 wenn das reicht, bau ich das ein.


    also in die -> vdr-plugin-atmo 0.1.3-15yavdr1


    Generell funktioniert die V13 mit vdr-atmo und xine bei mir gar nicht.
    V13, vdr-atmo und xinelibout funktioniert hier bestens.
    Der Patch am vdr-atmo behebt bei mir das Abstüzen des sxfe nachdem man das atmo wieder ausschaltet.


    Also in Kurzform:


    V13 + vdr-atmo + xine -> gent nicht
    V13 + vdr-atmo + xinelibout + o.g. patch -> funktioniert


    Edit:

    Quote

    Original von hotzenplotz5
    also in die -> vdr-plugin-atmo 0.1.3-15yavdr1


    Keine Ahnung. Hab kein yavdr ;)

    Ich habe hier mit dem vdr-atmo und dem xine plugin im Zusammenspiel mit den DF-Patch vom xine-lib V13 auch so meine Probleme. Bin deshalb auf xinelibout umgestiegen.
    Damit geht das ganze.
    Zusätzlich noch folgender Patch am vdr-atmo plugin:


    vgl. http://www.vdrportal.de/board/…?postid=928316#post928316

    Quote

    Original von schmirl
    Insgesamt verlangsamt dies das Umschaltprozedere, da bei jedem Umschaltvorgang jeder Server über das Netzwerk befragt wird.


    Hier würde ich schon ansetzen.
    Es muss ja nur gefragt werden wenn die primäre Karte nicht verfügbar ist.
    Im "normalfall" sollte diese genutzt werden.
    Quasi sollte der VDR dafür sorgen, dass wenn er eine Aufnahme macht und es kein Timer gesteuerter VDR start war, schon ein zweiter VDR zur Verfügung steht.


    Quote

    Mit ausgeschalteten VDRs gibt das aktuell Stress, da streamdev-client in jedem Fall einen Verbindungsversuch startet bis dieser auf einen Timeout läuft. Da könnte ich Dir aber was einbauen.


    Mhhh. Mit meinem obigen Kommentar kennt der Client-VDR ja schon den Server-VDR den er aufgeweckt hat. Somit sollte sich das ja vermeiden lassen.

    Quote

    Das Wecken anderer VDRs müsste man wohl in streamdev verankern, da ein bereits laufender VDR einem nicht laufenden vorzuziehen ist. Nur im Notfall müsste ein schlafender geweckt werden.


    Sehe ich auch so. U.U. müsste er beim hochfahren alle mal broadcasten, um zu gucken wer da ist. Generell sollte ein VDR immer Wissen, welchen anderen er gerade erreichen kann.
    Das kollidiert aber mit dem mehrfach Aufruf des streamdev-clients, denke ich.

    Quote


    Unschön wird es dann in meinen Augen beim Thema Aufnahmen. Da es keine Instanz gibt, die alle Timer aller VDRs kennt, lässt sich auch nicht planen, welcher VDR am besten welche Aufnahme übernimmt bzw. von welchem anderen VDR streamt.


    Die Frage die ich mir hier stelle, ist ob es in so einer Kombination überhaupt gewünscht ist, das alle die gleichen Timer und Aufnahmen haben.


    Quote

    Den Ansatz hat wohl mal das VIDEGOR Projekt verfolgt, das Projekt ist meines Wissens aber schon länger tot. Mit streamdev dürfte das mitunter ziemlich ineffizient werden.


    Sehe ich ähnlich.


    Quote

    Ich persönlich würde den zentralen Server in jedem Fall bevorzugen. Und wenn es ohnehin noch an der Netzwerkverkabelung fehlen sollte, dann lieber SAT-Kabel raus und Netzwerkkabel rein. Ansonsten käme es wohl auf einen Versuch an. Die eine oder andere Kleinigkeit kann ich dazu gerne in Streamdev einbauen, sollten größere Änderungen anfallen wird es aber schwierig. Meine Zeit ist sehr knapp bemessen und in streamdev gibt es dringendere Baustellen. Wäre also nicht verkehrt, wenn Du oder ein anderer Interessent über Programmierkenntnisse verfügt.


    Keine Angst. Ich wollte, wie ich schon sagte, nur mal die Oprion hier diskutieren.
    Also keine langen Programmiernächte für Dich, .... noch nicht ;)

    Eine Frage über die ich schon seit längerem nachdenke, möchte ich hier mal zu Diskussion stellen.
    Nicht, das dies im Moment aktiv vor hätte, nur möchte ich mal die Möglichkeiten diskutieren.


    Ausgangssituation:


    In einem Haus oder Wohnunung sind die einzelnen Zimmer in der Regel jeweils mit einem Satkabel angebunden.
    Es sei denn man baut gerade selber oder hat irgendwie Einfluss auf die Planung und Durchführung.
    Da eine Karte für einen VDR eher unbefriedigent ist, wird aktuell folgender Weg beschritten.
    Verlagerung der Sat Kabel in den Keller. Dort wird ein Zentraler VDR-Server eingerichtet der seine
    Karten den über Netzwerk angeschlossenen reinen Streaming Clients zur Verfügung stellt.
    Dies führt z.B. zum Problem, dass der Server von nun an ein single point of failure ist.


    Idee:


    Jeder VDR wird mit einer eigenen Sat Karte ausgestattet.
    Er ist nun sein eigener single point of failure.
    Die Satkabel müssen nicht neu verlegt werden.
    Dieser VDR agiert von nun an selber als steamdev-server sowie client und
    holt sich im Falle einer fehlenden Karte den Stream von einem anderen VDR.


    Fragen:


    - Welche Probleme stellen sich hier, die ich im Moment nicht sehe ?
    - Gibt streamdev das im Moment her ?
    - Die anderen VDRs müssten entweder ebenfalls gerade angeschaltet sein oder werden per Netz geweckt.
    Wie ist das zu realisieren, z.B. in Bezug auf die Auswahl des zu Nutzenden VDR-Servers.

    Quote

    Original von pinky666
    So. Ich bin jetzt mal von xine auf xinelibout mit lokalem frontend umgestiegen.
    Damit funktioniert das grabben wieder wunderbar.
    Muss also irgendwie an xine liegen.


    Wenn ich jedoch das nun funktionieredne vdr-atmo plugin wieder aus schalte, passiert folgendes:


    Ich zitiere mich mal selber. Mit folgendem Patch am vdr-atmo plugin scheints, in obiger Kombination zu gehen.

    So. Ich bin jetzt mal von xine auf xinelibout mit lokalem frontend umgestiegen.
    Damit funktioniert das grabben wieder wunderbar.
    Muss also irgendwie an xine liegen.


    Wenn ich jedoch das nun funktionieredne vdr-atmo plugin wieder aus schalte, passiert folgendes:


    Ich habe das Problem, dass ich wen ich mein Atmo einschalte nur noch Standbilder sehe. Das Bild wird nur noch ab und zu aktualisiert. Ton ist gar nicht mehr vorhanden.
    Das Atmo an sich scheint die korrekten Farben zu zeigen, der Grab an sich funktioniert augenscheinlich.


    Noch was:
    Ich verwende das native Atmo Plugin, nicht das xine-post Plugin.


    "Atmo on" kommt von mir.
    Hab per echo "Atmo on" >> xine.log den Zeitpunkt im log markiert, bevor ich das atmo eingeschaltet habe.

    Quote

    Original von durchflieger
    Zeigt doch mal wie dein xine log aussieht.


    Bitte


    Edit:

    Code
    1. hd-vdr:/usr/src/xine-lib-1.2# hg log|head
    2. changeset: 11552:609066b321de
    3. tag: tip
    4. user: Reinhard Nißl <rnissl@gmx.de>
    5. date: Sun Jul 18 23:33:46 2010 +0200
    6. summary: Fix input_vdr to use the best match when choosing zoom factors


    gepatched mit xine-lib-1.2-r11543-vdpau-extensions-v13-stream-start-v100614.diff.
    xine-0.9.3 gepatched mit xine-plugin-0.9.3-vdpau-extensions-v13.diff



    edit 2:
    Irgendwie vermisse ich in V13 die VDPAU-Grab Funktion.

    Files

    • xine.log.gz

      (5.5 kB, downloaded 141 times, last: )
    Quote

    Original von NemoN
    wobei man das auch als 1.1.90 lesen könnte :)


    Ist mit schon klar. Was willst Du damit sagen ?


    Ich habe mir gerade mal xine-plugin-0.9.3-grab.patch.gz und xine-plugin-0.9.3-vdpau-extensions-v13.diff.gz angesehen.
    Nach meinem Verständniss müssen beide ins xine-Plugin gepatched werden.
    Wenn ich das aber tue, fehlt ein Struct:

    Code
    1. g++ -g -O2 -Wall -Woverloaded-virtual -Wno-parentheses -fPIC -c -DUSE_DDEPGENTRY -DUSE_LIEMIEXT -DUSE_MAINMENUHOOKS -DUSE_NOEPG -DUSE_PLUGINMISSING -DUSE_SORTRECORDS -DUSE_WAREAGLEICON -DUSE_YAEPG -D_GNU_SOURCE -DPLUGIN_NAME_I18N='"xine"' -DFIFO_DIR=\"/tmp/vdr-xine\" -DVERIFY_BITMAP_DIRTY=0 -I/usr/src/v4l-dvb/linux/include `pkg-config --cflags libxine` -I../../../include xineLib.c
    2. xineLib.c: In member function ‘uchar* PluginXine::cXineLib::execFuncGrabImage(const char*, int&, bool, int, int, int)’:
    3. xineLib.c:4029: error: ‘data_grab_image_vdpau_t’ was not declared in this scope
    4. xineLib.c:4029: error: expected `;' before ‘data’
    5. xineLib.c:4030: error: ‘data’ was not declared in this scope
    6. xineLib.c:4030: error: ‘func_grab_image_vdpau’ was not declared in this scope
    7. make[1]: *** [xineLib.o] Fehler 1
    8. make[1]: Leaving directory `/usr/src/vdr-1.7.14/PLUGINS/src/xine-0.9.3'


    Des weitern gibt es einen Reject, der aber ignoriert werden kann.

    Quote

    Original von iNOB
    Bist du dir sicher, dass du xine-lib-1.2 verwendest?


    Das sieht bei mir auch so aus, bin mir aber ziehmlich sicher, dass ich die 1.2er Version verwende.
    Wenn ich das richtig sehe, kommt das aus der version.sh von xine 1.2.
    Dort steht:

    Code
    1. ...
    2. XINE_VERSION_MAJOR=1
    3. XINE_VERSION_MINOR=1
    4. XINE_VERSION_SUB=90
    5. XINE_VERSION_PATCH=
    6. # Release series number (usually $XINE_MAJOR.$XINE_MINOR)
    7. XINE_VERSION_SERIES=1.2
    8. ...


    Ich habe mit der V13 fast die gleichen Probleme wie mit V12.
    Das Bild ist nach der Aktivierung vom atmo quasi in Zeitlupe.

    Quote

    Original von durchflieger
    wbreu


    in der Tat gibt es Probleme mit der grab Funktion mit dem xine vdr plugin wenn das grabben zu lange auf ein Bild warten muss. Dann kommt genau dein Fehler.
    Bin gerade die Funktion am überarbeiten.


    Gruss
    durchflieger


    Super. Hab das gleiche Verhalten wie webru.
    Buffer Usage steigt sofort auf 100 %. Dann schlägt der Watchdog zu.
    Mein Atmo ist damit im Moment still gelegt. :angst
    Warte aber auf deinen Patch und teste den Rest weiter. Keine Lust wieder down zu graden.

    Quote

    Original von Razorblade
    pinky : Wenn DU die Alsa/JAck Filter meinst: ja, man kann aber in der Xine config definieren, dass per A52 selbst DD dekodiert wird und dann liegt das ganze ja in PCM vor...


    Schon klar. Wie kommen die 5 einzelnen PCM Spuren dann wieder zusammen und per Toslink in meinen DD-Receiver ?
    Ich will ja nicht auf 5.1 Sound verzichten.

    Quote

    Original von Mreimer
    Wie viel echtes Bildungsfernsehen ist denn tatsächlich noch übrig geblieben?


    Schau Dir mal das Angebot z.B. des ZDF an.
    Dort finde ich fast ausschließlich hochkarätige, unabhänginge, interessante, gute gemachte Formate aller Sparten.


    Ich verstehe wirklich nicht warum die ÖR immer so schlecht gemacht werden. imho erfüllen sie ihren Auftrag vollumfänglich !

    oh ha !
    So ganz stimmt da nochwas nicht.
    z.B.:


    nachher : Scrubs/1.12-Mein_Date_aus_der_Röhre
    nachher : Scrubs/1.13-Meine_zweite_Chance
    nachher : Scrubs/1.14-Meine_Alex
    nachher : Scrubs/1.14-Meine_clevere_Idee
    nachher : Scrubs/1.14-Meine_Hexe
    nachher : Scrubs/1.14-Meine_sexistischen_Kollegen
    nachher : Scrubs/1.15-Meine_Beziehung
    nachher : Scrubs/1.16-Meine_Melone
    nachher : Scrubs/1.17-Mein_Student
    nachher : Scrubs/1.19-Mein_alter_Herr
    nachher : Scrubs/1.1-Mein_erster_Schritt


    How_I_Met_Your_Mother wird gar nicht erkannt.


    Tipps ?