Neue Testversion FA2623 für AV7110 firmware

    Hi,
    dumme Frage: Benutze zwar den aktuellsten kernel-dvb-Treiber, aber eben fuer den Kernel 2.4.
    Hier laesst sich obiger patch nicht ohne rejects (die zweite condition fehlt) anwenden und der patch zeigt damit auch keinen positiven Effekt (usleep weiterhin notwendig).
    Gruss
    Burkhardt


    Mir erschließt sich schon nicht, wieso überhaupt der Schwellenwert auf 20 KByte festgelegt worden ist. Ich hatte früher diesbezüglich schon mal in der ML gefragt, jedoch keine Antwort erhalten.


    Der ganze Code sieht sehr renovierungsbedürftig aus.


    Vermutlich ist es relativ egal, denn der PC kann die Daten wesentlich schneller anliefern als es die Karte konsumieren kann. D.h. die Puffer sind praktisch immer gefüllt bis zum durch FREE_COND gegebenen Limit.


    Zitat


    Nebenbei wird FREE_COND auch in dvb_video_poll() verwendet,
    daher noch eine Frage: warum wird statt einem UND nicht ein
    ODER zwischen den beiden Bedingungen verwendet ?(


    Sowohl video als auch audio laufen i.a. über das video-Device. In dvb_play/dvb_video_poll ist jedoch nicht bekannt, ob es sich um Video- oder Audio-Daten handelt. In welchen Ringbuffer die Daten müssen, weiß man erst in play_video_cb().


    Daher wird einfach geprüft, ob Platz in beiden Ringbuffern vorhanden ist. Deshalb '&&'.


    Zitat


    Ausserdem könnte man das neue FREE_COND_AUDIO Makro auch
    in dvb_audio_poll() anwenden :D


    Ich wollte die Änderungen zunächst minimal halten. Später werde ich das AUDIO-Makro auch in dvb_aplay und ..._poll verwenden.


    CU
    Oliver

    Zitat

    Original von burki
    dumme Frage: Benutze zwar den aktuellsten kernel-dvb-Treiber, aber eben fuer den Kernel 2.4.
    Hier laesst sich obiger patch nicht ohne rejects (die zweite condition fehlt) anwenden und der patch zeigt damit auch keinen positiven Effekt (usleep weiterhin notwendig).


    Bei 2.4 sollte es genügen, die Routine dvb_play() entsprechend zu patchen.


    CU
    Oliver


    Btw, die CVS-Treiber für Kernel 2.4 kann man nicht mehr als aktuell bezeichnen... ;(

    Hi,

    Zitat

    Bei 2.4 sollte es genügen, die Routine dvb_play() entsprechend zu patchen.


    klar, hab ich ja auch gemacht, doch das Testprogramm von Stefan blebt dann trotzdem (wenn man den usleep deaktiviert) haengen.
    Gruss
    Burkhardt

    Zitat

    Original von burki
    Hi,


    klar, hab ich ja auch gemacht, doch das Testprogramm von Stefan blebt dann trotzdem (wenn man den usleep deaktiviert) haengen.


    Treiber kompiliert und auch wirklich neu geladen? :D


    Falls ja, poste mal die gepatchte dvb_play() Routine.


    CU
    Oliver

    Hi,

    Zitat

    Treiber kompiliert und auch wirklich neu geladen? großes Grinsen


    aber sicher doch ;) ...


    dvb_play:


    Gruss
    Burkhardt

    Zitat

    Original von burki


    aber sicher doch ;) ...


    dvb_play:

    Code
    static ssize_t dvb_play(struct av7110 *av7110, const u8 *buf,
                        unsigned long count, int nonblock, int type, int umem)
...


    Sieht gut aus. Keine Ahnung, woran es hängt.


    Werde das mal mit Kernel 2.4 testen. Wehe Dir, wenn es geht... :D


    CU
    Oliver

    Zusatzinfo:


    Wenn ich


    verwendet, bekomme ich mit dem Test Programm folgendes Log


    Und dann hängt es. 8634 ist die Länge der Stillpicture Daten.


    Gruß
    Stefan

    Sieht so aus, als ob es unter 2.4 ganz anders abläuft als unter 2.6.
    Ich verstehe überhaupt nicht, wie eine Debugausgabe wie oben zustande kommt...


    Kann das mal jemand unter 2.6 testen?


    CU
    Oliver

    Zitat

    Original von UFO
    Sieht so aus, als ob es unter 2.4 ganz anders abläuft als unter 2.6.
    Ich verstehe überhaupt nicht, wie eine Debugausgabe wie oben zustande kommt...


    Kann das mal jemand unter 2.6 testen?


    Damit kann ich leider nicht dienen.
    Ich kann aber gerne weiter Debugausgaben einbauen, wenn du willst.


    Gruß
    Stefan

    Zitat

    Original von UFO
    Sieht so aus, als ob es unter 2.4 ganz anders abläuft als unter 2.6.
    Ich verstehe überhaupt nicht, wie eine Debugausgabe wie oben zustande kommt...


    Korrektur: Sieht normal aus und unterscheidet sich nicht von 2.6.


    Außerdem eben mit 2.4 getestet: Funktioniert hier ebenfalls.


    Ich weiß allerdings nicht warum:
    Nachdem ich den Treiber noch mal angeschaut habe, denke ich, daß die Codeänderung eigentlich gar nicht nötig sein sollte. Keine Ahnung, was da los ist.


    Sorry, ich muß dieses Problem jetzt erst mal auf Eis legen. :(


    CU
    Oliver

    Habe doch noch etwas gefunden:


    In av7110_pes_play() fehlt ein wake_up:

    Code
    if ((len = dvb_ringbuffer_avail(buf)) < 6) {
--->                  wake_up(&buf->queue);
                        return -1;
                }


    Damit hängt STILL_PICTURE hier nicht mehr. Testet dies mal.


    Ist allerdings immer noch nicht ok:
    Beim ersten Aufruf des Testprogramms nach dem Laden des Treibers liefert poll() nun nach STILL_PICTURE 0, der Video-Ringbuffer ist voll und wird nicht mehr geleert. Die FW holt die Daten offenbar nicht ab. Interessanterweise funktionieren weitere Aufrufe anschließend einwandfrei...


    stefan:
    Ist wohl so ähnlich wie das, was Du auch beobachtet hast. Hatte ich bisher nicht, bei mir hing immer nur STILL_PICTURE bei _leerem_ Ringbuffer...


    Offenbar gibt's hier mehr als einen Fehler... ;(


    CU
    Oliver

    Nach dem Beenden der Wiedergabe von VDR Aufnahmen, als auch
    bei MPlayer und DVD Plugin Wiedergaben, bleibt das letzte
    Bild der Wiedergabe stehen. Der Ton des Live Signals kommt
    aber. Weiterhin gibt es im Bild Artefakte und Piepser im
    Ton. Wie bei schlechtem Empfang.


    Umschalten auf einen anderen Sender bringt nichts. Das
    erneute Abspielen einer Aufnahme gelingt allerdings wieder
    einwandfrei. Weiterhin scheint sich das Problem nach einiger
    Zeit von selbst zu lösen. Wahrscheinlich durch ARM Reset.


    Ich verwende die in diesem Thread verfügbaren Patches,
    natürlich die FA2623 Firmware, VDR 1.3.37, Kernel 2.6.15.1
    und die v4l CVS Version des DVB Treibers vom 22.01.2006.


    Ich habe im Forum noch einen anderen Thread vom 25.01.2006
    gefunden, wo dasselbe Problem erwähnt wird. Allerdings ohne
    brauchbare Antworten. siehe
    http://www.vdrportal.de/board/thread.php?threadid=44714


    Außerdem geht die Sync zwischen Bild und Ton ebenfalls
    um eine 1 Sek. auseinander, wenn man während einer Aufnahme
    auf Pause und dann wieder auf Play geht. Passiert immer.


    Für Hilfe wäre ich dankbar. Es nervt etwas, den Treiber
    immer neu laden zu müssen, wenn eine Wiedergabe erfolgt ist.


    Mit älteren Versionen der FW passiert das ganze übrigens
    nicht. Müsste sonst downgraden. :-((

    Zitat

    Original von stefan.h
    Kann ich noch irgendwelche Informationen zum Einkreisen des Problems liefern?


    Nicht nötig, ich kann's ja reproduzieren. Muß jedoch erst mal rauskriegen, was da in der Firmware schief läuft...


    CU
    Oliver


    Afaik ist dieses Problem nicht neu. Hatte ich schon immer, allerdings nur sporadisch und nicht reproduzierbar.
    Nach Umschalten auf einen HDTV(!)-Kanal verschwinden die Kllötzchen wieder. :D



    Downgrade-Drohungen sind zwecklos und werden ignoriert. :)


    Bitte um genaue Angabe: Ab welcher FW-Version genau tritt das Problem auf?


    CU
    Oliver

    Hallo Oliver,


    mal ein bischen positives feedback ;)


    mit WSS in der fa2623 klappt es super mit meinem Phillips röhren-fernseher . Bei ARD/ZDF & co wird sofort auf breitbild geschaltet und auch sofort zurück wenn ich z.b. auf RTL schalte. Das selbe gilt für wiedergabe und für DVD wiedergabe.


    Echt klasse, mein dank an alle beteiligten :]



    Dann noch eine "kleinigkeit", evt. passt vieleicht eher in einen neuen thread , aber vieleicht ist es ja der selbe fehler wie der von tomglx.
    Manschmal nach wiedergabe und - wenn es richtig sehe - das kurz davor durch noad oder ähnliches hoher last auf dem system war - habe ich folgendes :

    Code
    Dec 28 22:46:14 vdr vdr[15373]: ERROR (dvbdevice.c,696): Das Argument ist ungültig
Dec 28 22:46:14 vdr vdr[15373]: ERROR: can't set PID 163 on device 1
Dec 28 22:46:14 vdr vdr[15373]: ERROR (dvbdevice.c,708): Das Argument ist ungültig
Dec 28 22:46:14 vdr vdr[15373]: ERROR: failed to set PIDs for channel 4 on device 1
Dec 28 22:46:14 vdr vdr[15373]: retrying
< SNIP >
Dec 28 22:46:14 vdr kernel: dvb_demux_feed_del: feed not in list (type=0 state=0 pid=ffff)
Dec 28 22:46:14 vdr last message repeated 17 times

    All kanäle sind dann im "eimer" und es hilft auch kein reload der treiber - nur ein reboot hilft da. Die zweite+ dritte karte snd nicht betroffen und nehmen weiter auf. Passiert nicht so oft aber doch öfters als es sollte ;) = 3 + 22 + 28. Januar


    Kann gerne mehr infos liefern.


    War mit verschiedenen VDR und DVB treiber :
    bis 21. jan : vdr-1.3.37 dvb-kernel-20050826-ac3 fw-2623
    Ab 22. jan : vdr-1.3.39 v4l-dvb-20060118 fw-fd2623
    Ab 28. jan : vdr-1.3.39 v4l-dvb-20060118 fw-fa2623


    Gruß
    Viking

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden