OSD Fehler mit aktivierten streamdev-Client [ erledigt ]

lancs · 11. Mai 2013

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?

Code

vdr (2.0.0/2.0.0) - The Video Disk Recorder
svccli (2.0.0) - Service demo client
epgsync (0.0.4) - Import EPG of an other VDR
svdrpservice (0.0.4) - SVDRP client
pictures (2.0.0) - A simple picture viewer
xine (0.9.4) - Software based playback using xine
epgtableid0 (2.0.0) - EPG handler for events with table id 0x00
rcu (2.0.0) - Remote Control Unit
nordlichtsepg (0.9) - Extended EPG
svdrpdemo (2.0.0) - How to add SVDRP support to a plugin
dummydevice (1.0.3) - Output device that does nothing
skincurses (2.0.0) - A text only skin
osddemo (2.0.0) - Demo of arbitrary OSD setup
dvbsddevice (2.0.0) - SD Full Featured DVB device
hello (2.0.0) - A friendly greeting
osdteletext (0.9.3) - Displays teletext on the OSD
svcsvr (2.0.0) - Service demo server
streamdev-client (0.6.0) - VTP Streaming Client
status (2.0.0) - Status monitor test
dvbhddevice (2.0.0) - HD Full Featured DVB device
music (0.9.3-testing) - MP3-/Audioplayer

Alles anzeigen

Frank

kls · 11. Mai 2013

Zitat von gandalf247

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

lancs · 11. Mai 2013

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

schmirl · 13. Mai 2013

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".

lancs · 14. Mai 2013

schmirl

mach ich sehr gerne, bin aber momentan auf Dienstreise.... poste den Mitschnitt wenn ich wieder zuhause ( Samstag ) bin...

Frank

mentox · 1. Juni 2013

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

schmirl · 3. Juni 2013

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.…ff/server/connectionVTP.c

mentox · 3. Juni 2013

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/gen…vdr-streamdev-9999.ebuild

Code

LINGUAS="de es fi fr it lt ru sk "
>>> Source prepared.
>>> Configuring source in /var/tmp/portage/media-plugins/vdr-streamdev-9999/work/streamdev ...
>>> Source configured.
>>> Compiling source in /var/tmp/portage/media-plugins/vdr-streamdev-9999/work/streamdev ...
make -j3 all LOCALEDIR=/var/tmp/portage/media-plugins/vdr-streamdev-9999/work/tmp-locale LOCDIR=/var/tmp/portage/media-plugins/vdr-streamdev-9999/work/tmp-locale LIBDIR=/var/tmp/portage/media-plugins/vdr-streamdev-9999/work/streamdev TMPDIR=/var/tmp/portage/media-plugins/vdr-streamdev-9999/temp
make -C ./tools
make[1]: Entering directory `/var/tmp/portage/media-plugins/vdr-streamdev-9999/work/streamdev/tools'
make[1]: Leaving directory `/var/tmp/portage/media-plugins/vdr-streamdev-9999/work/streamdev/tools'
make[1]: Entering directory `/var/tmp/portage/media-plugins/vdr-streamdev-9999/work/streamdev/tools'
make[1]: *** Keine Regel vorhanden, um das Target »tools/select.h«,
  benötigt von »select.o«, zu erstellen.  Schluss.
make[1]: Leaving directory `/var/tmp/portage/media-plugins/vdr-streamdev-9999/work/streamdev/tools'
make: *** [server] Fehler 2

Alles anzeigen

vg mentox

lancs · 4. Juni 2013

Moin, Moin,

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

so zum Thema:

Habe das ganze nochmals am Bastelrechner durchgespielt:

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

tcpdump:

Code

04:17:48.496102 IP (tos 0x0, ttl 64, id 48557, offset 0, flags [DF], proto TCP (6), length 68)
    192.168.1.11.40854 > 192.168.1.1.2004: tcp 16
E..D..@.@................p~....d...\.......
..I.v@*EDELF 100 2 255


04:17:48.496672 IP (tos 0x0, ttl 64, id 42241, offset 0, flags [DF], proto TCP (6), length 84)
    192.168.1.1.2004 > 192.168.1.11.40854: tcp 32
E..T..@.@..F...............d.p~.....&......
v@*...I.220 Filter -1250955316 stopped


04:17:48.496683 IP (tos 0x0, ttl 64, id 48558, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.1.11.40854 > 192.168.1.1.2004: tcp 0
E..4..@.@................p~........\?......
..I.v@*.
04:17:48.496891 IP (tos 0x0, ttl 64, id 48559, offset 0, flags [DF], proto TCP (6), length 67)
    192.168.1.11.40854 > 192.168.1.1.2004: tcp 15
E..C..@.@................p~........\.......
..I.v@*.ADDF 96 2 255


04:17:48.497614 IP (tos 0x0, ttl 64, id 42242, offset 0, flags [DF], proto TCP (6), length 89)
    192.168.1.1.2004 > 192.168.1.11.40854: tcp 37
E..Y..@.@..@.................p~............
v@*...I.220 Filter -1250955316 transferring


04:17:48.534829 IP (tos 0x0, ttl 64, id 48560, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.1.11.40854 > 192.168.1.1.2004: tcp 0
E..4..@.@................p~........\?......
..I.v@*.
04:17:48.827397 IP (tos 0x0, ttl 64, id 48561, offset 0, flags [DF], proto TCP (6), length 67)
    192.168.1.11.40854 > 192.168.1.1.2004: tcp 15
E..C..@.@................p~........\.......
..J.v@*.ADDF 97 2 255


04:17:48.831286 IP (tos 0x0, ttl 64, id 42243, offset 0, flags [DF], proto TCP (6), length 89)
    192.168.1.1.2004 > 192.168.1.11.40854: tcp 37
E..Y..@.@..?.................p~............

Alles anzeigen

Frank

schmirl · 4. Juni 2013

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);

mentox · 4. Juni 2013

moin moin

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

danke fuer deine hilfe

Diff

cat files/connectionVTP.c.diff
diff -uNr streamdev-0.6.0.orig/server/connectionVTP.c streamdev-0.6.0/server/connectionVTP.c
--- streamdev-0.6.0.orig/server/connectionVTP.c 2012-05-29 01:27:05.000000000 +0200
+++ streamdev-0.6.0/server/connectionVTP.c      2013-06-04 21:16:26.662387993 +0200
@@ -1815,7 +1815,19 @@
 {
        va_list ap;
        va_start(ap, Message);
-       cString str = cString::sprintf(Message, ap);
+
+
+
+ #if APIVERSNUM >= 10728
+        cString str = cString::vsprintf(Message, ap);
+ #else
+ #error APIVERSNUM fehlt
+        cString str = cString::sprintf(Message, ap);
+ #endif
+
+
+
+
        va_end(ap);


        if (Code >= 0 && m_LastCommand != NULL) {

Alles anzeigen

vg mentox

lancs · 5. Juni 2013

Moin, Moin,

danke euch beiden...

Frank

OSD Fehler mit aktivierten streamdev-Client [ erledigt ]

Jetzt mitmachen!

Teilen

Benutzer online in diesem Thema