Posts by sbontadi

    Hallo Oliver

    Quote

    Dieser Commit repariert den cxd2843-Treiber aus dddvb-0.9.14, sonst nix:
    Die dvbdev-Änderung (100_dvbdev.c.diff) ist dagegen 5(!) Monate alt:

    Das Missverständnis stammt aus folgendem Link http://linuxtv.org/hg/~endriss…patch.d/100_dvbdev.c.diff


    Wenn man bei Mercurial eine Datei auswählt und changeset anklickt, erhält man generell den letzten changeset, nicht den letzten Changeset von der Datei.
    Damit habe ich natürlich die zwei Changes als Eins angesehen.


    Eindeutiger ist: hg log --stat



    Quote

    Dieser Commit repariert den cxd2843-Treiber aus dddvb-0.9.14, sonst nix:

    Ich bin aus einem anderen Thread aufmerksam gemacht, dass das dddvb von hier stammt: http://download.digital-devices.de/download/linux/

    Quote

    dddvb 0.9.14
    dddvb Paket auf Version 0.9.14 aktualisiert.

    Das Zusammenspiel zwischen dddvb und media-build-experimental und die Versionierung ist mir noch nicht ganz klar.


    Aus deinen obigen Quote habe ich abgeleitet, dass Du media-build-experimental tagst.
    dddvb wird von DD entwickelt (oder mindestens das Changemanagement betrieben), Ihr verwendet gegenseitig Patches.
    Mit obigen Quote, wolltest Du eher sagen, dass deine Änderungen, die von dddvb erstellte Patches (insofern relevant) beinhalten.


    Vielleicht kannst Du hier noch einige klärende Worten dazu sagen, vielleicht eine Info für Beitrag 1.



    Da Du die Änderung von dddvb, welche nur DD Tuner unterstütz, übernohmen hast, und media-build-experimental alle Tuner kompiliert, stellte sich die Frage bei mir, welchen Einfluss dies bei einem gemischten Hersteller Tuner einsatz hat.
    Der dvbloopback Patch ist in etwa gleichzustellen, wie obigen ddvb Patch. In Upstream media-build gab es letztes Jahr eine Diskussion, bezügl einer dvbloopback mutex Patch Einbindung, welche von Mauro abgelehnt wurde, mit in etwa die gleiche Begründung, welche Du bezügl. den open call gemacht hast. Aus diesem Zusammenhang stammt meine Frage.


    Quote

    Ralph ist der DVB-Experte überhaupt, denn
    von ihm stammt ein großer Teil des DVB-Codes. Wenn er einen Lock
    entfernt, gehe ich davon aus, daß er weiß, was er tut

    Wie und wo kann man Ralph erreichen.

    Ist mir in Nachhinein in Sinn gekommen, dass ich den dvbloopback Treiber verwende, und dafür ein "media" brauche.
    Beide DKMS kann ich nicht verwenden, da experimental einen fixes datum media herunterladet.
    Der dvbloopback DKMS, das letzte media, was nachher zu unknown symbols führt.
    Weiter liefern Eure beide DKMS und den dvbloopback DKMS dvb-core.ko, was unschön ist.


    Ich kompiliere experimental und dvbloopback wieder selber, und werde dafür die Kernel Version fixieren um nicht bei jedem Kernel Update kompilieren zu müssen.


    Alles läuft bei mir, werde darum den dddvb DKMS nicht mehr testen. Trotzdem vielen Dank für Eure Hilfe.


    Ich habe gesehen, dddvb-dkms wurde in dkms umbennennt. Schwer zu verstehen, was im Paket drin ist, auch da für die PPAs keine Releasenotes angehängt werden.
    Gibt es für yavdr ein Wiki, welche grob die PPAs und die verschiedene Plugins beschreibt?


    The original media dvbdev.c looks like:

    Code
    1. static int dvb_device_open(struct inode *inode, struct file *file){ struct dvb_device *dvbdev; mutex_lock(&dvbdev_mutex); down_read(&minor_rwsem); dvbdev = dvb_minors[iminor(inode)]; if (dvbdev && dvbdev->fops) { int err = 0; const struct file_operations *new_fops; new_fops = fops_get(dvbdev->fops); if (!new_fops) goto fail; file->private_data = dvbdev; replace_fops(file, new_fops); if (file->f_op->open) err = file->f_op->open(inode,file); up_read(&minor_rwsem); mutex_unlock(&dvbdev_mutex); return err; }fail: up_read(&minor_rwsem); mutex_unlock(&dvbdev_mutex); return -ENODEV;}


    Experimental after patching looks like:

    Code
    1. static int dvb_device_open(struct inode *inode, struct file *file){ struct dvb_device *dvbdev; //mutex_lock(&dvbdev_mutex); down_read(&minor_rwsem); dvbdev = dvb_minors[iminor(inode)]; if (dvbdev && dvbdev->fops) { int err = 0; const struct file_operations *new_fops; new_fops = fops_get(dvbdev->fops); if (!new_fops) goto fail; file->private_data = dvbdev; replace_fops(file, new_fops); if (file->f_op->open) err = file->f_op->open(inode,file); up_read(&minor_rwsem); //mutex_unlock(&dvbdev_mutex); return err; }fail: up_read(&minor_rwsem); //mutex_unlock(&dvbdev_mutex); return -ENODEV;}


    Oben beschriebenen Patch wird für dvbloopback in Verbindung mit zB. Oscam um CAM/Smartcards zu lesen/entschlüsseln, verwendet.

    Code
    1. + mutex_unlock(&dvbdev_mutex);err = file->f_op->open(inode,file);+ mutex_lock(&dvbdev_mutex);



    Abgesehen von den Verbindungszweck, erkenne ich hier einen gewissen Wiederspruch (sollte kein Vorwurf sein).
    Bezügl. den dvbloopback patch erwähnst Du (UFO), dass der mutex_unlock schlecht wäre. Das original dvbdev hat am Anfang der Routine ein mutex_lock, welche im experimental auskommentiert wurde.


    Commit http://linuxtv.org/hg/~endriss…atch.d/100_dvbdev.c.diff: experimental: Fix deadlock in cxd2843 driver


    Macht das auskommentieren im experimental nicht eher etwas kaputt, vorallem für Benutzer mit gemischte Hersteller-Tuner?


    Ich habe folgenden Setup:

    Code
    1. cxd2099 17427 1 ddbridgeddbridge 61160 3drxk 63461 2dvb_core 126666 2 ddbridge,dvbloopbackdvbloopback 24184 9stv0367dd 21874 2tda18212dd 17180 2tda18271c2dd 22003 2



    Ich habe keinen cxd2843, wäre es für mich besser, die experimental auskommentierte mutex_lock/unlock patch zu deaktivieren und dafür die original dvbdev aus media zu verwenden?


    Simon

    Ich habe nur ein ddbridge mit drxk und stv0367 frontend.


    media-build-experimental: geht.


    Mit der bevorzugte dddvb-dkms erhalte ich folgende Fehlermeldung:


    Preparing to unpack .../dddvb-dkms_0.9.14.1yavdr0~trusty_all.deb ...
    Unpacking dddvb-dkms (0.9.14.1yavdr0~trusty) ...
    Setting up dddvb-dkms (0.9.14.1yavdr0~trusty) ...
    First Installation: checking all kernels...
    Building only for 3.13.0-24-generic
    Building for architecture x86_64
    This package appears to be a binaries-only package
    you will not be able to build against kernel 3.13.0-24-generic
    since the package source was not provided


    Was ist die Fehlerursache?

    Bis anhin habe ich media-build-experimental für ddbridge selbst kompiliert mit einem eigenen fixen Kernel.


    Mit einem bevorstehenden Upgrade nach Trusty, welche kernel updates erhält, möchte ich auf ein DKMS wechseln.
    Ich sehe das media-build-experimental-dkms für Trusty ein älteres Datum als Precise hat unter:


    https://launchpad.net/~yavdr/+…48/+listing-archive-extra


    Ist dies der korrekte Link?
    Bekommt Trusty nicht alle Bugfixes?
    Wann kann man mit aktuelle Updates rechnen?


    Gruss Simon


    Ich habe DVB-C und es gibt über 80 NetworkIDs, einige der Services haben unterschiedliche Multiplexes und PIDs für die verschiedene NetworkIDs. Unter DVB Settings solltest du keine "neue Transponders", etc. eingestellt haben.


    VDR sollte die Möglichkeit haben die NIT/PAT nur von einem NetworkID auszulesen.


    Gruss


    Simon

    Hat wunderbar funktioniert.


    Nach einem refresh rate wechsel verliert man zwar das treiber scaling, es wird vermütlich anders gescaled.


    Code
    1. DISPLAY=:1 nvidia-settings --query CurrentMetaMode
    2. Attribute 'CurrentMetaMode' (minerva11:1.0): id=50, switchable=no, source=RandR :: DPY-3: 1920x1080_60i_0 @1920x1080 +0+0


    Die settings findet man unter System Einstellungen/System/Video Output. Trickreich ist allerdings, dass man die refresh rate muss wählen und weiter mit linke pfeiltaste dann auch tatsächlich den refresh rate wechseln (Bestätigungsbox).
    Nachher das scaling im "Video Calibrations" durchführen.
    Und dies für alle refresh rates, welche man benötigt.


    Erstaunlich, nach dem Beenden von XBMC (und auch mit einem kill -9) liefen MythTV und VDR wieder mit den voreingestellten NVIDIA scalings.


    Weiter habe ich System Einstellungen/Video/Playback - Pause during refresh rate change, von 2 sec auf off gesetzt ohne bemerkliche problemen (10 Minuten getestet). Ist dies OK oder eher nicht zu empfehlen ? Was wäre ein guter wert ?


    Vielen Dank für den Hinweis
    Simon

    Wenn XBMC die Displayfrequenz ändert, wird das Scaling aufgehoben und Overscan tritt auf.


    Habe folgende drei Settings:

    Code
    1. DISPLAY=:1 nvidia-settings --assign CurrentMetaMode="HDMI-0: 1920x1080 { ViewPortOut=1808x1013+48+34, ViewPortIn=1920x1080 }"
    2. DISPLAY=:1 nvidia-settings --assign CurrentMetaMode="HDMI-0: 1920x1080_60i { ViewPortOut=1808x1013+48+34, ViewPortIn=1920x1080 }"
    3. DISPLAY=:1 nvidia-settings --assign CurrentMetaMode="HDMI-0: 1920x1080_60i_0 { ViewPortOut=1808x1013+48+34, ViewPortIn=1920x1080 }"


    Im XBMC Menu stehend

    Code
    1. # DISPLAY=:1 xrandr -q
    2. 1920x1080 25.0 + 30.0* 30.0
    3. # DISPLAY=:1 nvidia-settings --query CurrentMetaMode
    4. Attribute 'CurrentMetaMode' (minerva11:1.0): id=50, switchable=no, source=nv-control :: DPY-3: 1920x1080_60i @1920x1080 +0+0 {ViewPortIn=1920x1080, ViewPortOut=1808x1013+48+34}


    Rufe ich ein Youtube video (oder VDR LiveTV abhängig von der Auflösung) änder XBMC die Frequenz und Overscan tritt auf:


    Code
    1. # DISPLAY=:1 xrandr -q
    2. 1920x1080 25.0 + 30.0 30.0*
    3. # DISPLAY=:1 nvidia-settings --query CurrentMetaMode
    4. Attribute 'CurrentMetaMode' (minerva11:1.0): id=50, switchable=no, source=RandR :: DPY-3: 1920x1080_60i_0 @1920x1080 +0+0


    Wenn ich im Menu stehend bereits die für das Youtube Video benötigte Frequenz setze

    Code
    1. DISPLAY=:1 nvidia-settings --assign CurrentMetaMode="HDMI-0:
    2. 1920x1080_60i_0 { ViewPortOut=1808x1013+48+34, ViewPortIn=1920x1080 }"
    3. # DISPLAY=:1 xrandr -q
    4. 1920x1080 25.0 + 30.0 30.0*
    5. # DISPLAY=:1 nvidia-settings --query CurrentMetaMode
    6. Attribute 'CurrentMetaMode' (minerva11:1.0): id=50, switchable=no, source=RandR :: DPY-3: 1920x1080_60i_0 @1920x1080 +0+0


    und das Youtube Video starte, tritt kein Overscan auf, da die Frequenz nicht geändert muss wurden

    Code
    1. # DISPLAY=:1 xrandr -q
    2. 1920x1080 25.0 + 30.0 30.0*
    3. # DISPLAY=:1 nvidia-settings --query CurrentMetaMode
    4. Attribute 'CurrentMetaMode' (minerva11:1.0): id=50, switchable=no, source=RandR :: DPY-3: 1920x1080_60i_0 @1920x1080 +0+0



    MythTV und VDR LiveTV ändern die Overscan/Scaling Settings nicht, nur XBMC. Gibt es eine Einstellung in XBMC, sodass das Scaling nicht mehr verändert/resetted wird ?


    Simon

    Vielen Dank für die Hinweise. Ich habe erst später gesehen, dass es ein separates yaVDR Forum gibt und meine Frage eventuell mit einem speziellen VDR Release in yaVDR 0.5 zu tun haben konnte.


    Ich habe einen Eintrag in der channels.conf eingefügt und den Kanal angezeigt, die andere Kanäle auf dem Transponder werden übernommen. Normalerweise startet VDR mit der Anzeige eines Kanals. Wie kann man VDR einstellen, sodass neue Transponder mit Ihre Kanäle gefunden werden ? Ich nehme mal an, dass das Mitsenden von andere Transpondern im aktuellen Transponder voraussetzung sind, ist dies eher die Regel oder eher nicht ? Wo müsste man mittels dvbsnoop schauen ? Habe DVB-C, UPC Cablecom Schweiz.


    Ich bemerkte, dass im VDR neue Kanäle gefunden wurden, aber das channels.conf noch nicht gesynced wurde. Wann synct VDR ?

    Hallo zusammen
    Ich bemerke beim zappen, dass Sender die funktionierten aufsmal nicht mehr funktionieren. Im Log sieht man das VDR den Transponder wechselt.


    Code
    1. Mar 13 21:01:55 minerva11 vdr: [5351] switching to channel 4
    2. Alles OK
    3. Mar 13 21:02:07 minerva11 vdr: [5411] changing transponder data of channel 4 from 410000:C0M64:C:6900 to 506000:C0M64:C:6900
    4. Mar 13 21:03:55 minerva11 vdr: [5351] switching to channel 4
    5. Mar 13 21:04:04 minerva11 vdr: [5410] frontend 0/0 timed out while tuning to channel 4, tp 506


    Habe DVB-C und die channels mit wirbelscan erstellt.


    Warum ändert VDR funktionierende Sender ?
    Was ist das beste Rezept eine korrekte channels.conf zu erhalten und zu fixieren ?


    Vielen Dank
    Simon

    Hallo zusammen
    Ich bemerke beim zappen, dass Sender die funktionierten aufsmal nicht mehr funktionieren.
    Im Log sieht man das VDR den Transponder wechselt.

    Code
    1. Mar 13 21:01:55 minerva11 vdr: [5351] switching to channel 4
    2. Alles OK
    3. Mar 13 21:02:07 minerva11 vdr: [5411] changing transponder data of channel 4 from 410000:C0M64:C:6900 to 506000:C0M64:C:6900
    4. Mar 13 21:03:55 minerva11 vdr: [5351] switching to channel 4
    5. Mar 13 21:04:04 minerva11 vdr: [5410] frontend 0/0 timed out while tuning to channel 4, tp 506


    Habe DVB-C und die channels mit wirbelscan erstellt.


    Warum ändert VDR funktionierende Sender ?
    Was ist das beste Rezept eine korrekte channels.conf zu erhalten und zu fixieren ?


    Vielen Dank
    Simon

    Hallo Oliver
    Noch eine weitere Frage. Ich habe manchmal hänger und glaube es liegt am cxd2099, da dieses Modul sich nicht mehr mit rmmod löschen läst.
    In cxd2099 gab es viele in den vergangene 3 Monate viele Änderungen, auch bezügl. Stabilität, was ein ein diff von experimental mit der linux-media Version auch zeigt.
    Wäre es Möglich einen rebase zu machen.
    Vielen Dank
    Simon

    I used http://linuxtv.org/downloads/d…-media-2011-07-02.tar.bz2 and the instructions on page 5.


    make gives the following errors:


    CC [M] /usr/src/media_build_experimental/v4l/ddbridge-core.o
    /usr/src/media_build_experimental/v4l/ddbridge-core.c: In function 'demod_attach_drxk':
    /usr/src/media_build_experimental/v4l/ddbridge-core.c:576:2: warning: passing argument 1 of '__a' from incompatible pointer type
    /usr/src/media_build_experimental/v4l/ddbridge-core.c:576:2: note: expected 'const struct drxk_config *' but argument is of type 'struct i2c_adapter *'
    /usr/src/media_build_experimental/v4l/ddbridge-core.c:576:2: warning: passing argument 2 of '__a' makes pointer from integer without a cast
    /usr/src/media_build_experimental/v4l/ddbridge-core.c:576:2: note: expected 'struct i2c_adapter *' but argument is of type 'u32'
    /usr/src/media_build_experimental/v4l/ddbridge-core.c: In function 'ts_poll':
    /usr/src/media_build_experimental/v4l/ddbridge-core.c:947:20: warning: unused variable 'input'
    /usr/src/media_build_experimental/v4l/ddbridge-core.c: At top level:
    /usr/src/media_build_experimental/v4l/ddbridge-core.c:220:13: warning: 'set_table' defined but not used


    Are these errors seen be others and the ddbridge is still fine ?

    Hallo


    Ich habe nach Anleitung den Octopus Treiber installiert und alles funktioniert. Ich habe ein Duoflex-CT angeschlossen.Ich verwende sasc-ng/cccam um meine Cam zu verwenden, welche über dvbloopback zwei Adapter generiert.
    Die Installation ist die Gleiche als mit meiner Technisat Skystar S2.


    Ein Zugriff ist nicht möglich. In folgende Thread is das Problem beschrieben, welche mit zwei Tuner auftritt:
    http://www.dvbn.happysat.org/viewtopic.php?p=341894#p341894


    Mir fällt auf das innerhalb media_build_experimental das dvbdev.c angepasst wurde, aber out of sync ist für 2.6.38
    diff ./media_build_experimental/experimental/ngene-octopus-test/linux/drivers/media/dvb/dvb-core/dvbdev.c ./media_build_experimental/linux/drivers/media/dvb/dvb-core/dvbdev.c


    Dazu kommen folgende Beiträge wegen ein Locking Problem, welche in 2.6.38 gegenwärtig ist:
    http://static.loping.net/bcode…fore-opening-driver.patch
    https://aur.archlinux.org/packages.php?ID=48512


    Sind die viele Änderungen in dvbdev.c, welche für den Octupus gemacht wurden, für 2.6.38 relevant ? Kann ich die Distribution Version nehmen, sodass ich das Mutex Problem hinzufügen kann ?
    Auf linuxtv.org Maillingliste, gab es am 3 Juli Patches Meldungen: http://www.spinics.net/lists/linux-media/msg34918.html
    http://linuxtv.org/hg/~endriss/media_build_experimental/ sehe ich das die letzte Änderungen for 3 Wochen stattfanden.
    In welche Hg sind die Patches reingekommen ?
    Gibt es Anstrebungen, die Sources in Linux einzubinden, Version ? unverbindliches Datum ?


    Gruss
    Simon