Beiträge von the_freestyler

    Code
    vdr-frontend stop/killed, process 1412
    toggle start/running, process 3749


    und xbmc startet wie gewohnt. Strange.


    hier mal die menuorg.xml:

    Hallo,


    probiere ich xbmc aus dem Menü aufzurufen passiert anschließend nix. Leider ist auch nichts aus dem Log ersichtlich.


    Code
    Dec  7 21:19:17 vdr: [2684] Text2Skin: menu display update thread started (pid=1367, tid=2684)
    Dec  7 21:19:22 vdr: [1367] executing command '/usr/share/vdr/menuorg-appswitcher standalone=yes app=xbmc &> /dev/null '
    Dec  7 21:19:22 vdr: [2684] Text2Skin: menu display update thread ended (pid=1367, tid=2684)


    Jemand eine Idee, ich das debuggen kann?
    Stelle ich xbmc als default Frontend ein läuft es ohne Probleme.


    Ergänzung:
    nicht nur xbmc ist betroffen, sondern auch alle anderen "Apps".

    Leider setzt 1000MBit voraus, dass autoneg eingeschaltet ist, anders wird "speed 1000 duplex full autoneg off" nicht akzeptiert.


    Code
    ethtool -s eth0 speed 1000 duplex full autoneg off
    Cannot set new settings: Invalid argument
      not setting speed
      not setting duplex
      not setting autoneg


    Mit 100Mbit ob half oder full ist es auf jedenfall stabiler. Ein Abbruch des Stream nach gewisser Zeit hat eine andere Ursache, vermute ich.

    hey,


    hab diese hier im VDR verbaut:


    Code
    00:0a.0 Ethernet controller [0200]: nVidia Corporation MCP79 Ethernet [10de:0ab0] (rev b1)


    Also Paketverluste sind da, wie man an dem Stream sieht, aber nur im UDP Protokoll. TCP habe ich einen super Durchsatz, der mein Gbit Netzwerk auslastet und IGMP funktioniert auch.
    Ich probiere es mal auf 100Mbit, sollte immer noch locker für einen Stream reichen und berichte.


    Edit:


    Tatsache, mit festen Einstellungen auf 100Mbit/ half duplex ist der Stream nahezu fehlerfrei.

    sieht so aus. Mich wunderts nur, dass es erst seit dem Update des tbs Treibers auftritt.


    Harmony:


    orig. FB:


    Code
    Event: time 1321466538.880668, type 4 (Misc), code 4 (ScanCode), value 99
    Event: time 1321466538.880675, type 1 (Key), code 352 (Ok), value 1
    Event: time 1321466538.880678, -------------- Report Sync ------------
    Event: time 1321466539.127389, type 1 (Key), code 352 (Ok), value 0
    Event: time 1321466539.127393, -------------- Report Sync ------------


    Code
    1321466515.859517: event MSC: scancode = 99
    1321466515.859527: event key down: KEY_OK (0x0160)
    1321466515.859529: event sync
    1321466516.107392: event key up: KEY_OK (0x0160)
    1321466516.107398: event sync


    Hm, was macht die Harmony falsch...?

    Weder auf evtest /dev/input/event3, evtest /dev/input/event4, noch auf ir-keytabe -t bekomme ich irgendwelche Ausgaben angezeigt.
    Mit irw bekomme ich eine Ausgabe.


    Mit Harmony:


    Code
    2 0 KEY_1 devinput
    2 1 KEY_1 devinput


    Mit der orig. FB:


    Code
    2 0 KEY_1 devinput


    ps -A Ausgabe:

    wobei mir das schon doppelt aussieht:


    Code
    [   19.010041] Registered IR keymap rc-tbs-nec
    [   19.010124] input: cx23885 IR (TurboSight TBS 6981) as /devices/pci0000:00/0000:00:0c.0/0000:02:00.0/rc/rc0/input3
    [   19.013581] rc0: cx23885 IR (TurboSight TBS 6981) as /devices/pci0000:00/0000:00:0c.0/0000:02:00.0/rc/rc0
    [   19.013676] input: MCE IR Keyboard/Mouse (cx23885) as /devices/virtual/input/input4
    [   19.013778] rc rc0: lirc_dev: lirc_register_driver: sample_rate: 0
    [   19.013826] rc rc0: lirc_dev: driver ir-lirc-codec (cx23885) registered at minor = 0


    Input 3 und 4.


    Grüße!

    Klar, kann ich machen. Entweder heute am späten Abend oder morgen im Laufe des Tages.
    Mein Gbit Lan ist nicht am Anschlag ;).


    Edit:


    Ein kurzes Stück Multicast RTL liegt nun auf Sigis FTP Server. Problem tritt also auch bei der Wiedergabe des aufgenommenen Streams auf :(.
    In der Statisk im VLC erkennt man, dass einige Pakete verworfen werden, weil fehlerhaft.


    Schon mal vielen Dank fürs Angucken.

    Hallo,


    bei mir ist der Multicast Stream des streamdev-servers unter yaVDR 0.4 leider sehr abgehackt; Ton und Bild mit Störungen. Zwischen 720p HD und SD kein Unterschied. Probiert habe ich bereits mehrere Rechner win7 64bit Rechner mit LAN und WLAN. Schwer zu sagen, woran es liegt. Http Stream ist einwandfrei. Als Client nehme ich den aktuellen VLC. Im Syslog ist nix zu sehen.


    Was mir aufgefallen ist, die Verzögerung zwischen Live Bild über HDMI und Multicast ist viel kleiner als zwischen Live und http. Anscheinend kleinerer Buffer? Vllt zu klein, um einen einwandfreien Stream hinzukriegen?


    LG,
    Micha