Beiträge von zochi


    Weil Werner damals mit dem "Countdown" angefangen hat. Es nochmal zu ändern, würde nur die Verwirrung vergrößern.


    (älter) ff -> fe -> fd -> fc ->fb -> ... (neuer)


    Aha, ich dachte mir das zwar auch schon, nach dem ich nach anderen Versionen gegooglet hatte. Aber Gewissheit ist besser, Danke :)
    Vielleicht wäre ein Hinweis im Readme hilfreich, da diese Nomenklatur ja gewöhnungsbedürftig ist?
    (Auch wenn niemand readme liest ;-))



    Zitat


    Anhand des Logs kann man erkennen, daß Firmware 2622 lief:

    Code
    dvb-ttpci: info @ card 1: firm f0240009, rtsl b0250018, vid 71010068, app 80002622


    Mit der aktuellen würde dort "app 80fb2624" stehen.


    Mist, ich habe immer nach "firmware" grept. :)
    Wo sind diese parameter beschrieben?



    Zitat


    Was wird auf welcher Karte aufgenommen?
    Stottert der Ton bei Radio-Wiedergabe oder bei TV-Wiedergabe oder beidem?


    Woher weiss ich das, welche Karte was macht? Nur aus dem Logfile?
    Ist es immer dasselbe oder spielt da ne Rolle, was ich zuvor gesehen habe?


    Radio Ton habe ich nicht probiert. Das Radio liegt ja irgendwo im 3 stelligen KanalBereich....
    (Wäre schon nett, wenn (neue) Radio Sender ganz am Ende angezeigt(einsortiert) würden, so das ich von Kanal 1 per wrap-arround
    zu den Radio Kanäle käme. die dann vielleicht "-1" "-2" gingen.)




    Rest folgt...
    (proc/Interrupt während der Aufnahme?)

    Danke für den Hinweis, half nicht.
    Dabei stellten sich 2 folgende Fragen:
    -Warum heisst eigentlich die neuere Version "fb" und die ältere "fc"? Ich hätte es anders rum erwartet?
    So kann ich nur am Dateidatum feststellen welche Version neuer ist.
    -Woher weis ich SICHER das die richtige oder überhaupt welche Firmware Version tatsächlich gerade läuft?
    Im syslog wird ja nur der Dateiname angegeben. Wenn in der Datei nicht drin ist was sein sollte sucht man sich den Wolf.


    Noch mal genauer den Effekt:
    Ich nehme vom WDR um 1.00 Domian als Video auf, und gleichzeitig von 1live als Radio.
    Also 2 Transponder.
    Ich hatte mit diese Kombination "früher" nie merkliche Probleme. (Athon 1200MHz)
    Jetzt neue MoBo mit 2.1GHz (BE3500?) "stuckert" der Ton wenn ich life zusehe.
    Spiele ich aber die Aufnahme ab während noch aufgenommen wird ist dies glasklar.
    Ich habe PCI Lantency mal von 32 auf 128 auf nun 256 verändert. 32 auf 128 scheint etwas gebracht zu haben,
    weil voher das "stuckern" völlig unerträglich war. (Das Struckern sind wohl buffer overflows).


    Irgenwie kann's doch nicht sein. Das hat doch mal alles wunderbar funktioniert.
    Hängt das mit dem Auslagern der ffkarte in ein Plugin zusammen?
    Lesen hier eigentlich auch Entwickler mit, oder ist das hier nur ein user-to-user-board?

    Hab nun die 2. TT FF gegen eine HP nova budget ersetzt da mit einer einzlenen FF v2.1 kein sinnvoller Betireb mehr mögllich scheint.


    Damit geht es! Also klarer Fall von
    "A software with a hardware patch" ;)


    Also
    1 TT FF 2.1 OSD
    1 Hauppage Nova Budget


    Es scheint mit Sqeeze/1.7.18 ein Problem geworden zu sein, wenn 2 FF eingesetzt werden.
    Sehr Schade.


    Was trotz Budget geblieben ist, das es es wohl nicht mehr möglich ist auf einer FF das Video zu sehen und (mehr als?)
    einen Kanal von dieser
    aufzuzeichen:
    Das gibt weiter hin buffer overflows, also Klötzchen und asynchronene Ton...wenn auch nicht soo schlim.


    Das ist keine Frage der CPU Leistung, die dreht die ganze Zeit Däumchen!
    Für mich riecht das nach einem Programmmierfehler der Art:
    Interrupts sperren und dann auf den nächsten Interrupt warten bis einen der Timeout raus boxt. :)
    oder reentrance probleme.
    Das es in diesem Bereich Lösungbedarf gibt, könnte auch davon abgeleitet werden, das vor Multiprozessor
    Betrieb gewarnt wird. Aber da die CPU eh 98% Idle würden 2 PUs eh nicht helfen.



    Schade ist auch, das die Dokumenation so mager ist, gerade im Bereich der Fehler suche oder der Unterschiede zwischen den Versionen.
    ebenson dass der VDR-Wiki kein Schreiben mehr erlaubt, also Fehler darin ewig bestehen
    bleiben?, zumal auch kein Verantwortlicher mehr imVDR-Wiki zu entdecken ist...?
    .

    "20%"? Bei mir kann ich nur die Höhe einstellen. Es geht auch nur darum das FF Karten einen begrenzten OSD Speicher haben und keine so grosse Fläche in Bunt darstellen können.


    cu


    Bei 1.7 kann man bei femon einen resize faktor angeben. Er ist normal 0.
    Leider habe keine Zugriff mehr da meine Frustgrenze überschritten ist
    und ich dann dem Rat folgen werde lenny+1.6 zu nehmen...


    Wieder reicher! :)
    An Erfahrungen...

    Doch kann ich, siehste ja :)
    Aber ich ziehe eine sachliche Diskussion ohne Unterstellungen und persönliche Anmache vor :)


    Die Liste ist ein Beispiel auf welche Probleme ich getroffen bin. Erstaunlich irgendwo, da es für jeden Bereich
    mehrere Spezialisten geben dürfte, die sagen: "Ja, ist doch das das so und so ist, das weiss man doch, und wer es nicht weiss,
    gehört nichtzu uns und sollte die Finger von so einem System wie xyz lassen und besser mit Murmeln spielen".
    Nein, das weiss nicht "man" sondern nur der Entwickler, der Spezialist, dem es darum so leicht fällt.


    Ich komme aus Anwendersicht. Dem Anwender ist erstmal egal woher das Problem rührt: "xyz geht nicht".
    Ich habe z.B. das Problem das die Schnaptolyse nicht tut wie sie soll, nicht so wie ich es erwarte.
    Da möchte ich dann die Möglichkeiten sehen, die zu dieser Fehlfunktion führen können, oder
    Aufklärung, das ne Schnaptolyse ebend nicht zum schrumbrunnsen geeignet ist.
    Ob es der Treiber sein könnte, die Firmware oder der Kern ist doch für den Anwender erstmal egal
    und kein Grund all diese -natrülich völlig- unterschidlichen Ursache in einer Auflistung zusammeln.
    Er muss einen Punkt haben, wo er ansetzen kann, denn niemand kann alles wissen.


    Für den Entwickler ist das natürlich "unstruktiertes Chaos", weil er mehr vom Einzelnen kommt,
    aber für wen wird VDR gemacht? Selbstzweck der Entwickler, oder auch zum Nutzen von Anwendern?
    Sicherlich beides, denn für einen Entwickler ist es sicher schöner, wenn ein Anwender gut mit dem Ergebnis
    zurecht kommt, und nicht nur der Code eine "innere Schönheit" hat, die sich allerdings nur einigen wenigen
    Spezialisten erschliesst und ggü. dem Anwender durch Funktionsmängel auffällt.


    Ihr Auto macht hinten während der Fahrt Geräusche?
    - Differential
    - Radlager
    - Reifendruck
    - Lauffläche
    - Radaufhängung
    - Fremdkörper
    - Radmutter
    - Drehmomentschlüssel
    - Gummimischung
    - Tankwart


    Das sind völlig unterschiedliche Bereiche die zu diesem Fehlerbild führen können. Ich verstehe nicht,
    wieso man diese nicht in eine Liste packen darf, nur weil es unterschieldliche Fachbereiche betrift?
    Ich würde mich freuen wenn Du Dein Sicht näher erläutern würdest, auch wenn Du es ja schon versucht hast.
    Und ganzbesonders darüber, wenn Du zeigst wie Du Dir vorstellst, das eine Fehler-Suche in einem VDR System systematisch erfolgen hat.

    Gibt es irgendwo eine Zusammenstellung wo die -wesentlichen-
    Unterschiede zwischen 1.6 und 1.7 liegen, die bei einer Installation unbedingt zubeachten sind?
    ( ausser implizit in den seitenlangen Readme zu jeder einzelnen Version?)


    Also irgendwie so was:
    Was ist neu bei 1.7.18(squeeze) vs. 1.6.x(lenny)
    1.7.18: UTF-8 Kodierte Zeichensätze (de,en) müssen installiert sein, sonst seltsame Menue
    1.7.18: Neues Format der channels.conf, ((in)kompatible zum 1.6?)(ohne HD: w_scan -fs -s S19E2 -o 7 >> channels.conf)
    1.7.18: Firmware FF TT -fb benötigt, sonst buffer oferflows(?)
    1.7.18: Nur 1 CPU wird unterstützt
    1.7.18: PCI latency timer sollte auf 128 stehen (BIOS)
    1.7.18: FF TT Ausgang nur mit Plugin zum ausgeben verwendbar
    1.7.18: Aufzeichung als TS und nicht PES, ((nicht) mit 1.6 abspielbar?)
    1.7.18: FF TT mod empfohlen
    1.7.18: HD unterstützung
    1.7.18: femon plugin passt sich nicht automatisch der OSD grösse an, sondern bleibt unsichtbar
    1.7.18: osdteletext plugin benutzt irrtümlich die Festplatte anstatt RAM-disk, was zu Klötzchen im Bild und Nicht-Abschalten der Platte führt
    1.7.18: Was noch? setup.conf erweitert um? sources? andere conf?


    Sonstiges:
    1.7.18: Aufzeichungsübersicht ohne Längenangaben(oder ist das ein Patch gewesen?)


    Wo finde ich das?

    Weil der keine Ahnung hast das du die FF Bildausgabe haben möchtest.


    Und vorsichts halber nimmt er an, ich will gar nix sehen? :-))
    Er könnte mich doch fragen, machen andere Installer ja auch, locales weiss ja auch nicht welche Sprachen und Zeichensätze ich möchte. -)


    Zitat


    Und irgendwann bei den 1.7Xers wurde die FF Bildausgabe halt in ein Pluigin ausgelagert.


    Ja habe ich zwischen gemerkt :)


    Zitat

    Installier doch einfach mal Debian lenny, dann gibts von e-tobi den 1.6er VDR. Der 1.7er wird ja ständig umgebastelt.


    lenny ist aber nicht mehr supportet, oder?


    Zitat


    Zu fmon, du musst im Setup von fmon die Bildschirmgrösse verkleinern.
    cu


    Ich habe den OSD so gross wie möglich gemacht und
    Ich habe bei femon 20% eingetragen, mehr geht nicht, dann dreht es wieder auf null.
    Ich habe unter squeeze noch nie einen fussel femon gesehen. Nur, wenn ich ihn starte, wird der Schirm kurz dunkel.


    Ich habe jetzt PCI auf 128, quite n cool ausgeschaltet, high speed AGP(?) mode im BIOS aktiviert.
    Das Mobo ist ein Asus "AM2NF3-VSTA" nForce, evtl. liegt es auch mit daran? (Aber Mobo diskussionen sehe ich hier keine)
    (Wie gesagt: Damit geht kein ACPI wake up)


    Thanks anyway.
    Ich habe "eigentlich" nix gegen die bleeding edge einer ungeraden VDR version, aber wie gesagt, so etwas "klemmendes"
    habe ich in 10 Jahren VDR nicht erlebt.


    Ich habe mir nun ne HP Budget bestellt, und eine HP USB DVB-T, mal sehen ob es damit besser wird....


    Achso:
    Könnte das alles damit zusammenhängen, das das eine Dual Core CPU ist?
    Aber die 2. CPU ist wohl ausgeschaltet, denn cpuinfo zeigt nur eine an.
    Schade.


    Welche Firmware-Version und welcher Treiber laufen?


    Es sollte sich mittlerweile herumgesprochen haben, daß TS-Aufzeichnungen (VDR 1.7.x) gegenüber PES (1.6.x) gewisse Updates erfordern...


    CU
    Oliver


    Nein, bitte erzähle mehr.


    Ich habe ein komplett neues System aufsetzen müssen,
    beginnend mit ctvdr 7.0, dann upgrade auf squeeze mittels tobi, der soweit ich das beurteilen kann, ein sehr gute Arbeit macht.
    Aber:
    Es ist eine total frustieriende Katastophe! (Naja, welche Katastrophe macht einen schon glücklich? :))
    Zunächsteinmal liefen von meinen 3...4 FF DVB-S Karten nur noch eine. 2 2.1, die tagszuvor noch mit 1.6 noch liefen, hatten plötzlich kein Signal
    mehr. Mit einer ungemoddeten 1.3 gingen 2 Aufzeichungen, aber nicht stabil.
    Nun habe ich nur noch eine FF drin, und: Es ist wie ein Alptraum: Es geht wirklich nichts.
    Nach einigem suchen kam ich darauf, das ich für meine FF DVB-S Karten ein Plugin installieren muss, dvbsddevice.
    Warum kann ein Debian paket installer das nichts selbst?
    femon war im Paet installiert, aber es schmiert immer der OSD thread mit einem memory fehler ab (hab das alles gestern hier ausführlich
    gepostet, ohne jede resonanz.)
    Nach weiterem langen suche kam ich drauf das evtl die Firmware "-fc" nicht für squeeze 1.7.18 gut sein könnte, obwohl sie damit installiert wird.
    Also die "fb" geholt (sehr irretierend das "fb" neuer als "fc" ist), aber nirgends ein Hinweis, welche Firmware tatsächlich gebraucht wird
    und welche fw version tatsächlich geladen wurde. Schön fände ich, wenn der Treiber/Das Plugin das checken würde.


    Ich habe den unbestimmten Eindruck, das dvbsddevice einen Griff in die braune Masse beinhalten könnte und das Non-HD keine Rolle mehr spielt?
    Früher(tm) ging das alles. (1.4 1.6)


    Mein Rechner 98,8% idelt und 1% sys und ich habe buffer overflows! Hallo? Da läuft doch irgendwas völlig schief. Dreht da wer die Interrupts ab und nicht wieder an? Gibt es ein multithreading problem?


    Einen stream aufzeichnen und einen zeigen war selbst mit einem 1200MHz Athlon kein Problem, jetzt ist das ein AMD Athlon(tm) X2 Dual Core Processor BE-2350 mit 2,2GHZ und 4GB RAM und 500GB+1,5TB SATA Platte.


    Ich will kein HD und was .ts bringt weiss ich nicht, ich möchte nur einen flexiblen und stabilen Videorecorder.
    ???

    Did not help me.
    Still no femon on OSD, that out of mem error.


    Could it be a problem of the TT Firmware?
    Which is required for 1.7.8 and howto determine which fw version is loaded.
    In the past there was an info string in the syslog, but i can't find any more.
    Anyhints?

    Das Problem beobachte ich auch.
    Bisher der einzige Rat:
    Man solle einen Hardware Patch der FF vornehmen!


    Ich finde, dass klingt irgendwie zynisch, resp. wie "Aufgegegeben".


    Ich weiss, dass man "früher" ohne diese Overruns recorden und guggen konnte,
    ein zeitlang gab's Problem wg. schlechter Pufferung der Versorgungsspannung,
    und mühsamer Firmware kodierung, aber so einen riesen, nicht trivialen Umbau
    um einen Kanal aufzeichnen zu können?


    Das ist nicht euer Ernst, Jungs? :)


    (Bei meinen FF Boards reicht das nachlöten eh nicht, ausserdem funktioniert
    von 3(!) 2.1FF nur noch eine seit dem ich squeeze und 1.7.8 einsetze. Kann irgendwie nicht sein
    oder zerstört neuerdings die 1.7.8 Software die Hardware? (Es wird nix mehr empfangen))

    Hallo


    wer erklärt mir mal warum der Buffer überläuft obwohl die CPU nix zu tun hat?


    Und vorallem:
    Was ich dagegen tun kann :)


    neustart VDR und ein Warmstart des Rechners halfen nichts.


    Es ist eine(!) FF Nexus 2.1 DVB-S, vorher hatte ich vdr 1.6 und zwei FF laufen und so etwas nur beobachten können, wenn ich 3 oder 4 Timer hatte ("soetwas" meint: Klötzchen, pochen und lückenhafter im Ton, z.Zt. asynchron).


    Femon 1.7.18 funktioniert auch nicht, da der Speicher zu klein ist (siehe anderes post)


    Hat es evtl. Sinn die FF Karte wegzuwerfen (es funktioniert mit dem 1.7.18 eh nur die eine FF) und
    eine Nividia mit MPEG und 2 Budget DVBS Karten zu nehmen?




    edit:
    Das Teil ist aumbedienbar:


    [english] You'll need to shrink your OSD size a bit as it seems that your output device cannot handle the current one due to memory limitations. [/english]


    I am running into the same problem.
    I have used the OSD setting which was set by the set up but
    I already reduced the vertical size by few percents to 80% and moved top down some percent
    (nice feature not to have to handle lines and pixels), but i would never have expected that femon
    (and other modules?) ould not work anymore. That's a sursprising side effect.


    But:
    femon seems to be installed by default as femon is of so much use.
    But it's annoying for newbies not get any hint what's wrong with the module on the OSD.
    A single OSD(!) line: "femon: OSD height (461) smaller than required (480), please adjust"
    or "OSD height too small!", "OSD width too small!" or "OSD sizes too small!" in the status line)
    would be very nice for the user.
    Why can*t femon recalulate the OSD by it's own or limit the settings?
    (If i increase OSD height and my LCD is in "zoom", some relevant Information would be lost.)
    Of cause it's nice that femon logs the required valude, but the new setting is in "%", not "lines".
    May I assume "480 lines" are 100%? (Default was 87% IIRC)



    Attention:
    I just set the OSD to 100%x100%.
    Now i don't have no OSD any more, but

    Code
    9:55:40 video2 vdr: [2972] unknown locale: '1'
    9:55:40 video2 vdr: [2972] loading /var/lib/vdr/themes/sttng-default.theme
    9:55:40 video2 vdr: [2972] OSD size changed to 720x576 @ 1.06667
    9:55:40 video2 vdr: [2972] saved setup to /var/lib/vdr/setup.conf
    9:55:40 video2 vdr: [2972] OSD size changed to 720x576 @ 1.06667
    9:55:40 video2 vdr: [2972] ERROR: cOsd::SetAreas returned 6 (out of memory)


    I set it top 100%, why 1,06667?
    Anyway:
    83,333% are 480 lines of 576line
    if femon is installed, less than 83% should not be allowed to be set
    or femon should readjust the OSD to 480 while it is running.



    OK... to revive the OSD;
    /etc/init.d/vdr stop
    vi /var/lib/vdr/setup.conf
    /etc/init.d/vdr start...


    not very user friendly...
    where can i file the bug? :)


    No OSD menu (out of memory):
    OSDAspect = 1.066667
    OSDHeight = 576
    OSDHeightP = 1.000000
    OSDLanguage = 1
    OSDLeft = 58
    OSDLeftP = 0.080000
    OSDMessageTime = 2
    OSDSkin = sttng
    OSDTheme = default
    OSDTop = 52
    OSDTopP = 0.090000
    OSDWidth = 624
    OSDWidthP = 0.870000



    Still no femon:
    OSDAspect = 1.066667
    OSDHeight = 490
    OSDHeightP = 0.850000
    OSDLanguage = 1
    OSDLeft = 58
    OSDLeftP = 0.080000
    OSDMessageTime = 2
    OSDSkin = sttng
    OSDTheme = default
    OSDTop = 52
    OSDTopP = 0.090000
    OSDWidth = 624
    OSDWidthP = 0.870000




    Code
    ERROR: cFemonOsd::cFemonOsd() OSD height (461) smaller than required (480).
    ERROR: cOsd::SetAreas returned 6 (out of memory)

    Offenbar gibt es ein Problem mit dem EPG scan, wenn 2 Karten da sind und 2 Aufnahmen laufen
    in VDR V.1.7.18?


    Ich habe jetzt das EGPScanTimeout auf Null gesetzt und neu gestartet.
    Dennoch schaltet irgend was ständig um!
    Da z.Zt. keine Aufnahmen mehr laufen, ist der Hauptbildschirm wieder stabil


    Warum nimmt EPGscan jetzt Device 2, aber wenn eine Aufnahme läuft Device 1 und achaltet damit
    dem Betrachter ständig das Bild weg?
    Warum ist das mit der Warnung "upcoming recording" verknüpft?



    /etc/vdr/setup.conf -> /var/lib/vdr/setup.conf
    ...
    EPGBugfixLevel = 2
    EPGLanguages =
    EPGLinger = 0
    EPGScanTimeout = 0
    ...
    3:36:01 video2 vdr: [1315] switching device 2 to channel 7
    3:36:12 video2 vdr: [1315] switching device 2 to channel 15
    3:36:23 video2 vdr: [1315] switching device 2 to channel 7
    3:36:34 video2 vdr: [1315] switching device 2 to channel 15
    3:36:45 video2 vdr: [1315] switching device 2 to channel 7
    3:36:56 video2 vdr: [1315] switching device 2 to channel 15

    Hallo


    Kann es wirlich sein, das in zwei Karten die Empfanger defekt sein sollten?
    wobei die eine zukurz zuvor mit der Version 1.6 noch lief, wenn auch schlecht?


    nach der Hochrüstung auf squeeze und VDR 1.7.18 (komlett neu) hatte ich kein Signal von der 2. (von) Nexus Karten.
    Fast alle Aufzeichnungen hatten die Länge 0.


    1.7.18 scheint im Default keinen Neustart mehr zu machen, wenn er keinen Stream bekommt.
    Das ist für den Anwender am TV nur daran zu merken, wenn die Aufnahmen die Länge null haben.


    hab nun mal erste VDR Karte aus dem PCI Slot gezogen und den Anschluss Stecker getauscht:


    Auf der ehemaligen 2. Karte habe ich jetzt das OSD, aber immer noch keinen Empfang.


    Dann habe ich ein noich viel ältere v1.3 anstelle der wohl defekten 2.1 eingebaut:
    So kann zumindet auf der 2. Karte die Kanäle vom EPG gewechselt werden.


    Jetzt habe ich zwar wieder 2 Karten, aber bei Aufzeichnung geht im 2sec der Bildschirmschirm aus
    und es wird grün "upcoming recording!" angezeigt.


    Was ist denn nun schon wieder los?
    Das wirkt wie ein Alptraum mich.




    Stand:
    OSD auf Haupauge Nexus v2.1
    zweite karte: TT v1.3



    Und diese Fehlermeldun var/log/syslog


    3:17:29 video2 vdr: [1309] switching device 1 to channel 15
    3:17:29 video2 vdr: [1309] switching to channel 1
    3:17:29 video2 vdr: [1309] info: Upcoming recording!
    3:17:32 video2 vdr: [1309] switching to channel 1
    3:17:32 video2 vdr: [1309] info: Upcoming recording!


    Kann es sein, das das EPG die Karte ständig umschalten will, obwohl eien Aufnahem ansteht oder läuft?





    3:03:24 video2 vdr: [1315] ERROR: attempt to open OSD while it is already open - using dummy OSD!
    3:03:24 video2 vdr: [1498] receiver on device 1 thread started (pid=1315, tid=1498)
    3:03:24 video2 vdr: [1497] femon receiver thread started (pid=1315, tid=1497)
    3:03:24 video2 vdr: [1499] TS buffer on device 1 thread started (pid=1315, tid=1499)
    3:03:32 video2 vdr: [1315] switching device 1 to channel 15
    3:03:32 video2 vdr: [1497] femon receiver thread ended (pid=1315, tid=1497)
    3:03:32 video2 vdr: [1315] ERROR (dvbsdffdevice.c,520): Device or resource busy
    3:03:32 video2 vdr: [1315] switching to channel 1
    3:03:32 video2 vdr: [1499] TS buffer on device 1 thread ended (pid=1315, tid=1499)
    3:03:32 video2 vdr: [1498] buffer stats: 110356 (5%) used
    3:03:32 video2 vdr: [1498] receiver on device 1 thread ended (pid=1315, tid=1498)
    3:03:32 video2 vdr: [1315] info: Upcoming recording!
    3:03:32 video2 vdr: [1315] ERROR: attempt to open OSD while it is already open - using dummy OSD!
    3:03:32 video2 vdr: [1500] femon receiver thread started (pid=1315, tid=1500)
    3:03:35 video2 vdr: [1315] switching to channel 1
    3:03:35 video2 vdr: [1500] femon receiver thread ended (pid=1315, tid=1500)
    3:03:35 video2 vdr: [1315] info: Upcoming recording!
    3:03:35 video2 vdr: [1315] ERROR: attempt to open OSD while it is already open - using dummy OSD!
    3:03:35 video2 vdr: [1502] receiver on device 1 thread started (pid=1315, tid=1502)
    3:03:35 video2 vdr: [1501] femon receiver thread started (pid=1315, tid=1501)
    3:03:35 video2 vdr: [1503] TS buffer on device 1 thread started (pid=1315, tid=1503)
    3:03:43 video2 vdr: [1315] switching device 1 to channel 15
    3:03:43 video2 vdr: [1501] femon receiver thread ended (pid=1315, tid=1501)3:03:24 video2 vdr: [1315] ERROR: attempt to open OSD while it is already open - using dummy OSD!




    May 29 13:03:24 video2 vdr: [1315] ERROR: attempt to open OSD while it is already open - using dummy OSD!
    May 29 13:03:24 video2 vdr: [1498] receiver on device 1 thread started (pid=1315, tid=1498)
    May 29 13:03:24 video2 vdr: [1497] femon receiver thread started (pid=1315, tid=1497)
    May 29 13:03:24 video2 vdr: [1499] TS buffer on device 1 thread started (pid=1315, tid=1499)
    May 29 13:03:32 video2 vdr: [1315] switching device 1 to channel 15
    May 29 13:03:32 video2 vdr: [1497] femon receiver thread ended (pid=1315, tid=1497)
    May 29 13:03:32 video2 vdr: [1315] ERROR (dvbsdffdevice.c,520): Device or resource busy
    May 29 13:03:32 video2 vdr: [1315] switching to channel 1
    May 29 13:03:32 video2 vdr: [1499] TS buffer on device 1 thread ended (pid=1315, tid=1499)
    May 29 13:03:32 video2 vdr: [1498] buffer stats: 110356 (5%) used
    May 29 13:03:32 video2 vdr: [1498] receiver on device 1 thread ended (pid=1315, tid=1498)
    May 29 13:03:32 video2 vdr: [1315] info: Upcoming recording!
    May 29 13:03:32 video2 vdr: [1315] ERROR: attempt to open OSD while it is already open - using dummy OSD!
    May 29 13:03:32 video2 vdr: [1500] femon receiver thread started (pid=1315, tid=1500)
    May 29 13:03:35 video2 vdr: [1315] switching to channel 1
    May 29 13:03:35 video2 vdr: [1500] femon receiver thread ended (pid=1315, tid=1500)
    May 29 13:03:35 video2 vdr: [1315] info: Upcoming recording!
    May 29 13:03:35 video2 vdr: [1315] ERROR: attempt to open OSD while it is already open - using dummy OSD!
    May 29 13:03:35 video2 vdr: [1502] receiver on device 1 thread started (pid=1315, tid=1502)
    May 29 13:03:35 video2 vdr: [1501] femon receiver thread started (pid=1315, tid=1501)
    May 29 13:03:35 video2 vdr: [1503] TS buffer on device 1 thread started (pid=1315, tid=1503)
    May 29 13:03:43 video2 vdr: [1315] switching device 1 to channel 15
    May 29 13:03:43 video2 vdr: [1501] femon receiver thread ended (pid=1315, tid=1501)3:03:24 video2 vdr: [1315] ERROR: attempt to open OSD while it is already open - using dummy OSD!



    3:03:24 video2 vdr: [1498] receiver on device 1 thread started (pid=1315, tid=1498)
    3:03:24 video2 vdr: [1497] femon receiver thread started (pid=1315, tid=1497)
    3:03:24 video2 vdr: [1499] TS buffer on device 1 thread started (pid=1315, tid=1499)
    3:03:32 video2 vdr: [1315] switching device 1 to channel 15
    3:03:32 video2 vdr: [1497] femon receiver thread ended (pid=1315, tid=1497)
    3:03:32 video2 vdr: [1315] ERROR (dvbsdffdevice.c,520): Device or resource busy
    3:03:32 video2 vdr: [1315] switching to channel 1
    3:03:32 video2 vdr: [1499] TS buffer on device 1 thread ended (pid=1315, tid=1499)
    3:03:32 video2 vdr: [1498] buffer stats: 110356 (5%) used
    3:03:32 video2 vdr: [1498] receiver on device 1 thread ended (pid=1315, tid=1498)
    3:03:32 video2 vdr: [1315] info: Upcoming recording!
    3:03:32 video2 vdr: [1315] ERROR: attempt to open OSD while it is already open - using dummy OSD!
    3:03:32 video2 vdr: [1500] femon receiver thread started (pid=1315, tid=1500)
    3:03:35 video2 vdr: [1315] switching to channel 1
    3:03:35 video2 vdr: [1500] femon receiver thread ended (pid=1315, tid=1500)
    3:03:35 video2 vdr: [1315] info: Upcoming recording!
    3:03:35 video2 vdr: [1315] ERROR: attempt to open OSD while it is already open - using dummy OSD!
    3:03:35 video2 vdr: [1502] receiver on device 1 thread started (pid=1315, tid=1502)
    3:03:35 video2 vdr: [1501] femon receiver thread started (pid=1315, tid=1501)
    3:03:35 video2 vdr: [1503] TS buffer on device 1 thread started (pid=1315, tid=1503)
    3:03:43 video2 vdr: [1315] switching device 1 to channel 15
    3:03:43 video2 vdr: [1501] femon receiver thread ended (pid=1315, tid=1501)



    Mit zwei Nexus 2.1


    2:26:58 video2 vdr: [1381] info: Upcoming recording!
    2:27:04 video2 vdr: [1456] frontend 0/0 timed out while tuning to channel 15, tp 112421
    2:27:06 video2 vdr: [1381] switching device 1 to channel 16
    2:27:06 video2 vdr: [1381] switching to channel 15
    2:27:06 video2 vdr: [1381] info: Channel not available!
    2:27:07 video2 vdr: [1381] connect from 127.0.0.1, port 35605 - accepted
    2:27:08 video2 vdr: [1381] closing SVDRP connection

    Hallo


    nach dem lange Zeit mein Ur-VDR DVB-S von 2006 seinen Dienst tat, wollte ich nun "nur" den lahmen, aber stromfressenden 1300MHz AMD gegen etwas neues ersetzen.


    Ich habe also dass Mobo getauscht, resultat: ACPI Wakeup geht nicht mehr, das Board geht beim ausschalten mit der Taste aus
    nur ganz kurz aus. Power klappt nicht, power up auch nicht. Lirc liefert nicht suprious intterupts und Zeit jitter.


    Das ist nicht ganz so schlimm (wer braucht schon ne FB?),
    wie das von den 2 FF Karten nur eine sauber geht, bei der anderen kommt immer


    "frontend 1/0 timed out while tuning to channel"


    Aufzeichnungen von dieser Karte haben die Länge 0


    video2:~# femon -H -a 1
    FE: ST STV0299 DVB-S (DVBS)
    Problem retrieving frontend information: Function not implemented
    status C | signal 0% | snr 0% | ber 65280 | unc -1217772743 |
    Problem retrieving frontend information: Function not implemented
    status C | signal 0% | snr 0% | ber 65304 | unc -1217772743 |


    video2:~# femon -H -a 0
    FE: ST STV0299 DVB-S (DVBS)
    Problem retrieving frontend information: Function not implemented
    status SCVYL | signal 63% | snr 69% | ber 65280 | unc -1216294087 | FE_HAS_LOCK
    Problem retrieving frontend information: Function not implemented
    status SCVYL | signal 62% | snr 69% | ber 0 | unc -1216294087 | FE_HAS_LOCK


    Starte ich femon im OSD so fliege ich kommentarlos aus Menu raus.


    Mein vorgehen:
    ctvdr 7 von CD installiert
    Die Dummy Falle mit dem sources.conf.online umschift
    UPdate/upgrade gemacht
    Die Referenzen auf eTopi gemacht
    updat/upgrade gemacht
    Tat!
    Aber die 2. Karte nicht.
    Beim zappen blieben einige Kanäle schwarz, torz gleichem Transport (mdr ging nicht, rbb ging)


    Ich habe natürlich die Antennen Kabel getauscht
    Auch habe ich diseq abgecshaltet
    und die DVB-S Karte gegen eine andere, v2.1, getauscht.


    Bin jetzt am ende, wie ich weiter such soll.



    VDR 1.7.18
    BOOT_IMAGE=/boot/vmlinuz-2.6.32-5-486
    ASROCK AM2NF3-VSTA mit AMD X2 BE-2350


    <6>[ 7.744381] dvb-ttpci: found av7110-0.
    <6>[ 7.744405] dvb 0000:02:09.0: PCI INT A -> Link[LNKB] -> GSI 19 (level, low) -> IRQ 19
    <4>[ 7.744443] IRQ 19/: IRQF_DISABLED is not guaranteed on shared IRQs
    <4>[ 7.744455] saa7146: found saa7146 @ mem f88ae800 (revision 1, irq 19) (0x13c2,0x0003).
    <6>[ 7.744469] dvb 0000:02:09.0: firmware: requesting dvb-ttpci-01.fw
    <6>[ 7.749004] DVB: registering new adapter (Technotrend/Hauppauge WinTV Nexus-S rev2.X)
    <4>[ 7.785041] adapter has MAC addr = 00:d0:5c:20:78:9e
    <6>[ 7.791648] dvb 0000:02:09.0: firmware: requesting av7110/bootcode.bin
    <4>[ 7.998461] dvb-ttpci: gpioirq unknown type=0 len=0
    <4>[ 8.024084] dvb-ttpci: info @ card 1: firm f0240009, rtsl b0250018, vid 71010068, app 80002622
    <4>[ 8.024086] dvb-ttpci: firmware @ card 1 supports CI link layer interface
    <4>[ 8.072153] dvb-ttpci: Crystal audio DAC @ card 1 detected
    <4>[ 8.073212] saa7146_vv: saa7146 (1): registered device video1 [v4l2]
    <4>[ 8.073502] saa7146_vv: saa7146 (1): registered device vbi1 [v4l2]
    <4>[ 8.336181] DVB: registering adapter 1 frontend 0 (ST STV0299 DVB-S)...
    <6>[ 8.336343] input: DVB on-card IR receiver as /devices/pci0000:00/0000:00:0e.0/0000:02:09.0/input/input9
    <6>[ 8.336374] dvb-ttpci: found av7110-1.