OSD Fehler mit aktivierten streamdev-Client [ erledigt ]

  • Hallo Leute,

    ich habe da einen Fehler im Channel_OSD mit aktivierten streamdev-Client, ohne Streamdev tritt das nicht auf. Ist es möglich die Signalstärke am OSD zu deaktivieren ... oder gibt es da evtl. eine andere Lösung?


    Frank

  • Hallo Leute,

    ich habe da einen Fehler im Channel_OSD mit aktivierten streamdev-Client, ohne Streamdev tritt das nicht auf. Ist es möglich die Signalstärke am OSD zu deaktivieren ... oder gibt es da evtl. eine andere Lösung?


    Ich vermute mal, der streamdev-Client implementiert ein eigenes cDevice. Kann es sein, daß das unbrauchbare Werte bei SignalStrength() bzw. SignalQuality() liefert?
    Die Default-Implementierung liefert ja in beiden Fällen -1, so daß da bei einem Device, das diese Werte nicht liefert, eigentlich nichts dargestellt werden sollte.

    Du könntest mal in cSkinSTTNGDisplayChannel::Flush() an den entsprechendne StellenAusgaben einbauen um zu sehen, was da genau passiert.

    Klaus

  • Hallo Klaus,

    Zitat

    Du könntest mal in cSkinSTTNGDisplayChannel::Flush() an den entsprechendne StellenAusgaben einbauen um zu sehen, was da genau passiert.

    Da fehlt mir leider das Verständnis zu, bin leider nur Anwender.. :(

    Frank

  • Streamdev überträgt die Werte von der DVB-Karte auf dem Server über das Netzwerk an den Client. Kannst Du mit einem Netzwerk-Sniffer wie wireshark oder tcpdump die Kommunikation über Port 2004 mitschneiden? Die Signal-Qualität wird mit dem Befehl SGNL angefordert. Als Antwort gibt es entweder eine Fehlermeldung oder "220 DEVICENUMMER SIGNALSTÄRKE:SIGNALQUALITÄT".

  • huhu
    hier ist das selbe problem

    Code
    tcpdump -v -A -q -n port 2004 >> tcp.log
    Code
    12:08:10.440172 IP (tos 0x0, ttl 64, id 22064, offset 0, flags [DF], proto TCP (6), length 58)
        192.168.42.43.37400 > 192.168.42.2.2004: tcp 6
    E..:V0@.@.....*+..*.........1wf....s.......
    ...h,.4.SGNL
    
    
    12:08:10.465287 IP (tos 0x0, ttl 64, id 3039, offset 0, flags [DF], proto TCP (6), length 89)
        192.168.42.2.2004 > 192.168.42.43.37400: tcp 37
    E..Y..@.@.YB..*...*+....1wf........r.t.....
    ,.5Y...h220 -1309683828 134986918:137039232

    lg mentox

    VDR Hardware

    [size=8]
    VDR Server: 1,8 core2 Duo, CineStar (4x), Gentoo, VDR 2.2
    VDR Client 1: Zotac ION (D2550ITXS-B-BE, Intel Atom D2550), MLD 4
    VDR Client 2: Zotac ION (IONITX-A-E, Intel Atom N330), MLD 4
    VDR Client 3: Raspberry Pi 2, MLD 5

  • Sogar als Devicenummer wird völliger Quark ( -1309683828 ) gemeldet :wow. Im Code kann ich beim besten Willen kein Problem erkennen. Damit bleiben für mich zur zwei Möglichkeiten: Ich habe Tomaten auf den Augen oder euer Streamdev ist nicht aktuell. Folgender im Februar gefixter Bug könnte die falschen Werte verursachen, sofern die VDR-Version mindesten 1.7.28 ist und streamdev von vor Februar:

    http://projects.vdr-developer.org/projects/plg-s…connectionVTP.c

  • hi

    ja in der tat .. vdr 2.0.2 und streamdev 0.6

    leider baut das streamdev git ebuild nicht.

    kommt denn eine 0.7 demnaechst?


    das ebuild habe ich von hier
    https://github.com/lucianm/gen2ov…dev-9999.ebuild

    vg mentox

    VDR Hardware

    [size=8]
    VDR Server: 1,8 core2 Duo, CineStar (4x), Gentoo, VDR 2.2
    VDR Client 1: Zotac ION (D2550ITXS-B-BE, Intel Atom D2550), MLD 4
    VDR Client 2: Zotac ION (IONITX-A-E, Intel Atom N330), MLD 4
    VDR Client 3: Raspberry Pi 2, MLD 5

  • Moin, Moin,


    sorry das ich mich jetzt erst melde...aber wenn stress kommt dann richtig..... jetzt erst mal paar Tage frei. :D

    so zum Thema:

    Habe das ganze nochmals am Bastelrechner durchgespielt:

    VDR 2.0.0 + streamdev-git von Heute..... keine Veränderung....

    tcpdump:

    Frank

  • Irgendetwas geht da gehörig schief:

    Code
    DELF 100 2 255
    220 Filter -1250955316 stopped
    ADDF 96 2 255
    220 Filter -1250955316 transferring

    Anstelle von -1250955316 sollte da die PID stehen, also 100 bzw. 96. Ich habe immer noch den falschen Aufruf von cString::sprintf im Verdacht. Evtl. ist die APIVERSNUM nicht verfügbar? Kommen beim Kompilieren von connectionVTP.c irgendwelche Warnungen?

    Bitte mal mit folgender Änderung kompilieren. Wäre tatsächlich APIVERSNUM undefiniert, ließe sich das Plugin dann nicht mehr bauen.

    Diff
    --- a/server/connectionVTP.c
    +++ b/server/connectionVTP.c
    @@ -1818,6 +1818,7 @@ bool cConnectionVTP::Respond(int Code, const char *Message, ...)
     #if APIVERSNUM >= 10728
            cString str = cString::vsprintf(Message, ap);
     #else
    +#error APIVERSNUM fehlt
            cString str = cString::sprintf(Message, ap);
     #endif
            va_end(ap);
  • moin moin

    soooo ich habe einen patch gebaut der mit 0.6.0 kompatibel ist. jetzt sind die balken huebsch :)

    danke fuer deine hilfe


    vg mentox

    VDR Hardware

    [size=8]
    VDR Server: 1,8 core2 Duo, CineStar (4x), Gentoo, VDR 2.2
    VDR Client 1: Zotac ION (D2550ITXS-B-BE, Intel Atom D2550), MLD 4
    VDR Client 2: Zotac ION (IONITX-A-E, Intel Atom N330), MLD 4
    VDR Client 3: Raspberry Pi 2, MLD 5

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!