Posts by Razorblade

    Hat mal jemand ein sources.conf Beispiel für mehrere Sats per DiseqC?
    Ich nutze im Moment:

    Code
    1. S19.2E 1 Astra 1H/1KR/1L/1M/2C
    2. S13E 2 Hotbird 6/8/9


    Aber ich befürchte damit hängen die Tuner fest am jeweiligen Sat (was ja im Prinzip unnötig ist)

    Code
    1. The recvmmsg() system call was added in Linux 2.6.33. Support in glibc was added in version 2.12.


    Debian Squeeze uses 2.11, so I'm on a dead-end here. For now I'd suggest to update the requirements to demand 2.6.33 and glibc 2.12


    I tried to upgrade to a later glibc (using a backported package for MX/Mepis which is also Squeeze-based) but that horribly broke my dependencies and I had to switch back. The next option would be to eliminate recvmmsg from the plugin for older GLIBCs (something like http://lists.linaro.org/piperm…odp/2014-June/001156.html ) but since this a complete rewrite of the function cSatipSocket::ReadVideo to cSatipSocket::ReadMulti I'm a bit lost. Does anyone else have an idea? This will be a problem for all Squeeze users that want to use satip-plugin 1.0.0 as well as some (still supported) LTS distros like CentOS/RHEL 5 and Ubuntu Lucid.


    Aber selbstverständlich lese ich *diesen* Thread ganz. Der andere interessiert mich nicht, da ich kein Inverto Device habe und bei einigen Äußerungen von Inverto-Users (und auch hier spreche ich niemanden direkt an) keine Lust verspüre, Zeit für das Problem anderer zu investieren.


    Du hast allerdings in *diesem* Thread (als Teil Deiner Rechtfertigung obwohl Du selber nicht wußtest warum) nochmal erwähnt, dass Du nur helfen möchtest, also habe ich Dir freundlicherweise nochmal geantwortet. Wenn Du das schon tust dann ist ja gut, aber wenn *Dein* Problem jetzt in einem anderen Thread behandelt wird, dann brauchen wir das ja auch hier nicht mehr zu thematisieren...

    Ich weiß zwar nicht warum ich mich vor Dir rechtfertige


    Ich auch nicht.


    Ich habe mit meiner Kritik niemanden persönlich angesprochen, da Du Dich jedoch anscheinend angesprochen gefühlt hast, habe ich mir die Mühe gemacht unpassende Bemerkungen herauszusuchen. Mir ist völlig schnuppe ob Du das Plugin jetzt benutzt oder nicht, aber falsche Behauptungen aufzustellen "1.0.0 is more buggy" oder durch ein auftreten außerhalb jeder Netiquette den Maintainer zu vergrätzen stört mich in der Tat, da dies u.U. Auswirkungen auf die weitere Entwicklung des Plugins hat.


    P.S.: Wie Du vielleicht gesehen hast, funktioniert 1.0.0 bei mir auch nicht, aber anstatt zu meckern habe ich Daten gesammelt, Infos geliefert, Fragen des Maintainers beantwortet und wir sind zu einem Ergebnis gekommen. Leider keins was mich weiterbringt (das Plugin läuft nicht auf Debian Squeeze) aber deswegen (oder wegen der mangelnden Unterstützung für nicht konforme Geräte) ist etwas noch lange nicht "buggy"...


    Also wenn Du helfen willst (aber nicht selber coden kannst), dann zieh die entsprechenden Traces. Oder auch mit tcpdump den RTSP Verkehr mit 0.3.3 und 1.0.0 beobachten damit sich das evtl jemand angucken kann.

    zwick der agent wrote:

    Somehow 1.0.0 is more buggy.


    Wenn Ihr ein Plugin bietet [...]



    Hier "bietet" jemand ein OpenSource Projekt. Lies Dir die Lizenzbedingungen durch und verhalte Dich danach.


    Die restlichen Lizenzbedingungen erlauben es Dir aber freundlicher alles selber zu reparieren wenn etwas nicht funktioniert... super, oder?!

    Ich finde es unverschämt hier derart über ein *kostenfreies Open-Source Projekt* zu schimpfen. Imho gibt es genau drei Möglichkeiten:
    1. Benutze es und wenn Du einen Fehler findest, fixe ihn (notfalls forke das Projekt wenn der Maintainer den Fix nicht akzeptiert)
    2. Benutze es und wenn Du einen Fehler findest ihn aber nicht selber beheben kannst, suche jemanden der hilft (das funktioniert in der Regel mit klaren Fehlerbeschreibungen und eindeutigen Bug-Reports, wieso sollte Dir sonst jemand freiwillig und kostenlos helfen???)
    3. Benutze es nicht


    Please, verify that you'll have kernel version 2.6.33 or greater and a proper header file (sys/socket.h) for it containing the recvmmsg() syscall.


    I'm running Kernel 3.4.6 (as per supplied "uname -a" output) and have the appropriate Kernel sources as well as some standard Debian header packages (2.6.32 and 3.2.0). But wouldn't <sys/socket.h> include /usr/include/sys/socket.h which is supplied by libc6 rather than kernel headers?


    Edit: /usr/include/sys/socket.h contains recvmsg

    Code
    1. extern ssize_t recvmsg (int __fd, struct msghdr *__message, int __flags);

    but not recvmmsg.


    Edit2:

    Code
    1. The recvmmsg() system call was added in Linux 2.6.33. Support in glibc was added in version 2.12.


    Debian Squeeze uses 2.11, so I'm on a dead-end here. For now I'd suggest to update the requirements to demand 2.6.33 and glibc 2.12

    Just tried to build 1.0.0 against vdr-2.1.6 but get an error when compiling:

    Code
    1. g++ -g -O3 -Wall -Werror=overloaded-virtual -Wno-parentheses -fPIC -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -c -DPLUGIN_NAME_I18N='"satip"' -DUSE_TINYXML -I/usr/local/src/vdr-2.1.6/include -o socket.o socket.c
    2. socket.c: In member function ‘int cSatipSocket::ReadMulti(unsigned char*, unsigned int*, unsigned int, unsigned int)’:
    3. socket.c:145: error: elements of array ‘mmsghdr mmsgh [(((unsigned int)(((int)elementCountP) + -0x00000000000000001)) + 1)]’ have incomplete type
    4. socket.c:145: error: storage size of ‘mmsgh’ isn't known
    5. socket.c:158: error: ‘recvmmsg’ was not declared in this scope
    6. make[1]: *** [socket.o] Fehler 1


    Did anyone else get this error? Might be related to TinyXML, I'll try with PugiXML next...


    EDIT:
    Not related to TinyXML, getting the same error with PugiXML. Here some additional info, next guess: building 32bit on a 64bit system?

    Code
    1. # gcc -v
    2. Using built-in specs.
    3. Target: i486-linux-gnu
    4. Configured with: ../src/configure -v --with-pkgversion='Debian 4.4.5-8' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.4 --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-targets=all --with-arch-32=i586 --with-tune=generic --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu
    5. Thread model: posix
    6. gcc version 4.4.5 (Debian 4.4.5-8)
    7. # uname -a
    8. Linux nas 3.4.6 #1 SMP Sat Nov 1 00:24:36 CST 2014 x86_64 GNU/Linux

    Also mit den Schlüsseldiensten habe ich das geringste Problem, das geht über die in vdr > 2.1.4 vorhandenen Möglichkeiten mit dem entsprechenden Plugin super. AU-seitig ist man etwas eingeschränkt (z.B. freischalten einer noch nicht aktivierten oder deaktivierten Karte geht nicht), aber am Start 5 Sek schwarz, danach alles flüssig.

    Arbeitet überhaupt noch jemand am SAT-IP Plugin? Oder bin ich jetzt nach dem Netceiver in der nächsten Sackgasse gelandet?
    Wie hier beschrieben und anschließend bestätigt funktioniert mit vdr 2.1.6 und dem sat-ip plugin kein epg scan mehr: http://www.vdr-portal.de/board…iver-updated/#post1211361 (der ursprünglich Thread war ein Announce, da kann man nichts mehr posten, falls es hier im Thread falsch ist, kann ein Mod das gern in einen eigenen Thread verschieben.)

    Das wird jetzt wirklich OT, aber USB zu PCI kann es nicht geben. Die niedrigen Latenzen die man auf dem PCI braucht lassen sich niemals über USB abbilden.
    Siehe auch: http://www.heise.de/ct/hotline/PCI-Karte-am-USB-319162.html
    Dazu macht es natürlich heutzutage keinen Sinn mehr *irgendetwas* für PCI zu entwickeln (sondern höchstens PCIe)


    Thunderbolt (2) transportiert übrigens native PCIe-Lanes, die müssen also tatsächlich nur wieder "auf den Sockel" gebracht werden, eine Protokollumwandlung (wie sie zwischen USB und PCI nötig wäre) findet nicht statt.

    [*]Wichtig: Um VDPAU zum Laufen zu bringen, Installation von ffmpeg-2.4.1
    aus den Sourcen http://ffmpeg.org/releases/ffmpeg-2.4.1.tar.bz2 [2]:
    [...]
    [2] Im originalen Raspian-ffmpeg fehlt offenbar die VDPAU-Unterstützung. Folglich gab es HD-Ausgabe nur in Zeitlupe, auch wenn der VDPAU-Treiber installiert war...


    Bei meinem Ubuntu ist laut Buildlog vdpau enabled, aber seit der Einführung von "hwaccel" kann man ja mit einem einfachen "avconv -codecs" nicht mehr sehen, wie es kompiliert wurde...
    Mit einem avconv auf eine (h264 yuv420p) Testdatei bekomme ich trotzdem die Ausgabe:

    Code
    1. No supported VDPAU format for retrieving the data.


    Da ich eine Diashow bei der (HD-)Wiedergabe habe, vermute ich, dass es auch am fehlenden VDPAU im LIBAV liegt, aber nachvollziehen kann ich es nicht so ganz...

    Ich habe noch massive Probleme mit dem Sound, musste da jemand (speziell CT) etwas manuell machen? Habe nur "schnarren" über HDMI.
    Habe hdmi.audio=1 gesetzt (weil zum Boot-Zeitpunkt nicht zwangsläufig was per EDID erkennbar ist), und wenn ich softhddevice per "-a hw:3,0" starte oder mir auch die Karte "3" per asoundrc als default setze kommt nur besagtes schnarren.

    Wenn du CMA aktiviert hast, sehe ich keinen Eintrag, der das loggt.


    Mein Kernel (danand latest) scheint CMA deaktiviert zu haben, damit zieht auch die Änderungen von ve_size nach dem #ifdef CONFIG_CMA nicht.
    Man erkennt es übrigens im dmesg, war nur blind:


    Hat jemand eine Idee wo man ve_size ändern kann wenn CMA deaktiviert ist? sehe sonst keine Definition in den Sourcen...


    EDIT: Selbst gefunden, 2 Einträge für ve_size in arch/arm/plat-sunxi/core.c probiere es jetzt mal mit 144M (SZ_128M + SZ_16M)

    Ich habe nicht ve_mem in der Kernel cmd_line geändert sondern in den Kernel-Sourcen, wenn das nicht wirkt, was dann? ;-)


    Habe inzwischen mal Deine script.fex (von https://raw.githubusercontent.…bie2vdr/master/script.fex) mit der Referenz fex (https://github.com/linux-sunxi…onfig/a20/cubieboard2.fex) vergleichen und der Diff offenbart, dass einige Bereiche übertaktet werden. Die CPU um ca. 10%, PLL4 drastisch (aus PLL4 wird die Clock-Rate des Mali abgeleitet). Weiß nicht, ob das nur zum Booten gemacht wird und dann nachher vom Kernel oder Userspace höher gezogen wird, aber es ist mir erstmal aufgefallen.
    Muss erstmal ein diff zwischen Referenz CB2 und CT Configs durchgehen, bevor ich diese Änderungen auch mal beim CT probiere.


    Das disablen des VGA-Ports habe ich nocht nicht probiert, werde ich gleich mal machen...