Posts by stmeyer

    Hallo kay123,
    wahrscheinlich lohnt sich das nicht mehr wirklich, da steffen_b vom yavdr-Team ja angekündigt hat, demnächst einen aktualisierten Treiber bereitstellen zu wollen.


    Falls Du nicht solange warten kannst, hier der Ablauf:
    1. Hier wird beschrieben, wie man den v4l-Treiber kompiliert. Du mußt natürlich das repository von Ufo nehmen also

    Code
    hg clone http://linuxtv.org/hg/~endriss/ngene-test2


    2. siehe oben

    Quote

    Ich vermute Ihr nutzt yavdr bzw. Ihr hattet damit den dkms-Treiber installiert. Die Kernel-Module liegen dann unter /lib/modules/linux.xxx/updates/dkms.
    Das "make install" kopiert die woanders hin.


    Kopiert einfach alle .ko-Files vom ngene-test2/v4l-Verzeichnis in obengenanntes und startet neu.


    3. Nicht vergessen die neue Firmware (ngene_18.fw) einzuspielen...


    Gruß
    Stefan

    Hallo zusammen,

    Quote

    Da sagst Du was. Da habe ich auch noch nicht drauf geachtet.
    Bei mir wird auch immer nur die 15 geladen.


    Ich vermute Ihr nutzt yavdr bzw. Ihr hattet damit den dkms-Treiber installiert. Die Kernel-Module liegen dann unter /lib/modules/linux.xxx/updates/dkms.
    Das "make install" kopiert die woanders hin.


    Kopiert einfach alle .ko-Files vom ngene-test2/v4l-Verzeichnis in obengenanntes und startet neu.


    Irgendwann gibt's bestimmt ein aktuelles, fertiges Paket vom yavdr-Team...


    Gruß
    Stefan

    Hallo zusammen,
    nach dem update auf die Version 0.3 tut die OK-Taste unter XBMC nicht mehr.
    In einen anderen Thread wurde das Problem auch schon von stepp64 angesprochen:

    Quote

    Hab gestern auch auf die 0.3 geupgradet. Nun geht bei mir im XBMC die OK Taste der Fernbedienung nicht mehr. Alle anderen Tasten klappen, auch im VDR. Die lircd.conf,remote.conf und Lircmap.xml sind genau die selben wie bei 0.2. Jemand eine Idee woran das liegen könnte?


    Gruß
    Sven


    Bei mir ist's genauso. Unter V0.2 funktionierte das prima, die genannten Files sind bei mir ebenfalls die Gleichen.


    Hat dafür jemand eine Lösung???


    Gruß
    Stefan

    Hi,
    nun hatte ich doch wieder einen Hänger: :(


    Also ganz ok ist doch noch nicht.


    Gruß
    Stefan

    Hi,
    bei mir stirbt der vdr eigentlich nie, im log sieht das folgendermassen aus:

    Code
    Oct 17 15:41:36 vdr vdr: [1503] ERROR: skipped 9024 bytes to sync on TS packet on device 2
    Oct 17 15:41:38 vdr vdr: [1503] ERROR: skipped 52452 bytes to sync on TS packet on device 2
    Oct 17 15:41:40 vdr vdr: [1503] [xine..put] cXinelibServer::Play Buffer overflow (TCP/PIPE)
    Oct 17 15:41:41 vdr vdr: last message repeated 89 times
    Oct 17 15:41:41 vdr vdr: [1503] ERROR: skipped 90428 bytes to sync on TS packet on device 2
    Oct 17 15:41:45 vdr vdr: [1504] buffer usage: 70% (tid=1503)
    Oct 17 15:41:45 vdr vdr: [1504] buffer usage: 80% (tid=1503)
    Oct 17 15:41:46 vdr vdr: [1504] buffer usage: 90% (tid=1503)
    Oct 17 15:41:46 vdr vdr: [1504] buffer usage: 100% (tid=1503)


    Die "TS continuity errors" habe ich seither noch nie gesehen. Außerdem habe ich das Problem nur ab und zu bei ARD/ZDF HD, aber eigentlich immer auf Pro7 HD.


    Ich habe den ngene-test2 Treiber gestern Abend noch kompiliert und installiert mußte dann aber leider gleich weg. Testen werde ich also erst heute Abend.


    @all: Was für Mainboards habt Ihr mit den Karten im Einsatz? Nachdem ja einige keine Probleme haben, liegt es vielleicht doch irgendwie an der Hardware-Kombination.


    Ich nutze ein ASUS P5N7A-VM...


    Gruß
    Stefan

    Hi F_L,
    auch meine Sat-Hardware schließe ich aus. Mit zig anderen HD-Geräten habe ich keinerlei Probleme.


    Die Firmware von UFO ist bereits da, vielen Dank dafür!, jetzt muß ich nur schauen, wie ich den Treiber übersetzt bekomme.
    Was Fertiges scheint's ja nicht zu geben, sonst hätte sich hier schon jemand auch dem yavdr-Team gemeldet, nehme ich an.


    Gruß
    Stefan

    Hallo,
    habt Ihr den obengenannten Treiber von UFO in einem (unstable)-ppa?


    Hintergrund ist folgender: Ich habe mehrere Cine2-Sat-Karten (V5.4 und V5.5) mit denen (zumindest unter yavdr) kein störungsfreier HD-Betrieb möglich ist. Da bei allen Karten der gleiche Effekt auftritt schließe ich einen oft genannten Hardware-Defekt der Karten aus.


    Ich habe bei allen 3 Karten nach kurzer Zeit Pixelmüll bis in zu stehendem Bild. Alle möglichen (und unmöglichen) geposteten Lösungsansätze wie
    - kleine channels.conf
    - Kernelparameter noapic nosmp numcpus=1
    - verschiedene nVidia-Treiber
    - EPG-Scan abschalten


    habe ich durch, keiner bringt bei mir nur die geringste Verbesserung.
    Nun gibt es mehrere Aussagen, dass der ngene-test2-Treiber von UFO mit der Firmware 18 endlich diese Probleme behebt.


    Das würde ich sehr gerne testen, die Mail an UFO wegen der Firmware ist schon raus.


    Wenn es das Paket in keinem Eurer ppas gibt, habt Ihr ne Anleitung wie ich mir den selbst bauen kann, ohne bei einem Eurer Updates auf der Strecke zu bleiben?


    Vielen Dank.


    Gruß
    Stefan

    Hi,
    danke, aber das habe ich bereits:

    Code
    boot.cfg
    ...
    linux   /boot/vmlinuz-2.6.32-25-generic root=UUID=29be7e34-ab33-45f5-aa9d-23c4ae3abade ro   vmalloc=256m quiet noresume noapic nosmp numcpus=1 nohz=off acpi_enforce_resources=lax
    ...


    Hilft mir leider nicht... :(


    Gruß
    Stefan

    Hi,

    Quote

    Bei mir ist es auch wieder aufgetrteten,aber bei weitem nicht mehr so oft wie zuvor mit 0.2!!


    Kann ich nicht bestätigen, ich habe hier alle paar min einen Hänger... :(


    Quote


    also seitdem ich den Xine-SD-Deinterlacer: von temporal auf bob umgestellt habe, sind mir die overflows nicht mehr aufgefallen! kann natürlich sein, das sie immer noch da sind, aber dann habe ich sie noch nicht bemerkt


    Also bei SD hatte ich noch nie ein Problem!


    Gruß
    Stefan

    Hi,
    ja update hat prima geklappt. Wollte ja eigentlich noch ein paar Tage warten, aber nachdem hier Meldungen aufgetaucht sind, dass es nun keine Buffer-Overflows mehr geben soll, hab ich's doch gleich gemacht. :)


    Leider:

    Code
    Oct 17 15:41:36 vdr vdr: [1503] ERROR: skipped 9024 bytes to sync on TS packet on device 2
    Oct 17 15:41:38 vdr vdr: [1503] ERROR: skipped 52452 bytes to sync on TS packet on device 2
    Oct 17 15:41:40 vdr vdr: [1503] [xine..put] cXinelibServer::Play Buffer overflow (TCP/PIPE)
    Oct 17 15:41:41 vdr vdr: last message repeated 89 times
    Oct 17 15:41:41 vdr vdr: [1503] ERROR: skipped 90428 bytes to sync on TS packet on device 2
    Oct 17 15:41:45 vdr vdr: [1504] buffer usage: 70% (tid=1503)
    Oct 17 15:41:45 vdr vdr: [1504] buffer usage: 80% (tid=1503)
    Oct 17 15:41:46 vdr vdr: [1504] buffer usage: 90% (tid=1503)
    Oct 17 15:41:46 vdr vdr: [1504] buffer usage: 100% (tid=1503)


    Das Update bringt zumindest mir diesbezüglich nix... :(


    Gruß
    Stefan

    Hi,
    ich hab's nun doch hinbekommen:


    Ich habe einfach in /etc/init/vdr.conf bei shutdown den vdr-shutdown.wrapper entfernt und das extb-poweroff.pl eingetragen. Und im extb-poweroff.pl als shutdown-Befehl den vdr-shutdown.wrapper. (Und das S91.extb-shutdown-hook-script gelöscht)


    Tut nun prima. :)


    Gruß
    Stefan

    Hi,
    im log steht dazu leider nix. Das sieht exakt so aus wie die logs auf Seite 1 des Threads.
    Ich habe mittlerweile das Originale (yavdr) S91.extb shutdown-hook-script gegen das ausgetauscht, das beim extb-plugin dabei ist (shutdown99.extb.sh)

    und dieses wieder in S91.extb umbenannt. Den Pfad auf das extb-poweroff-script angepasst dann "chmod +x S91.extb". Wenn ich das dann ausführe kommt folgender Fehler:

    Code
    root@vdr:/usr/share/vdr/shutdown-hooks# ./S91.extb
    ./S91.extb: Zeile 2: EXT_POWEROFF: Kommado nicht gefunden.
    ./S91.extb: Zeile 6: : Kommando nicht gefunden.


    Wenn ich "/usr/bin/extb-poweroff.pl" auf der Kommandozeile ausführe tut es wie es soll.


    Bin echt ratlos.
    Gruß
    Stefan

    Hallo,
    g3joker: Tut das jetzt bei Dir? Ich habe auch das extb-Board bei mir verbaut, es wird aber nie ein Timer ins extb-Board geschrieben. :(


    Wenn ich dem extb-poweroff.pl Skript auf der Kommandozeile einen Aufwachtermin mitgebe, funktioniert das prima. Leider interessiert das den VDR null...


    Gruß
    Stefan