ERROR: TS packet not accepted in Transfer Mode ...bei Wiedergabe mit ff-sd

  • Hallo zusammen,


    beim live-Fernsehen habe ich immer wieder Ton- und Bildstörungen - siehe unten Log-Auszug.
    - Geprüfte Ausgabe-Devices: Technotrend 1.6, S2300 und T1200, Tuner jeweils deaktiviert!
    - Opensuse 12.3, VDR 2.0.1 (mit 1.7... war's aber auch schon)
    - Ob ein oder mehrere Tuner eingebaut ist egal.


    Was mir auffiel:
    - Aufnahmen sind alle korrekt (u.a. auch geprüft mit ProjectX)
    - Wiedergabe der Aufnahmen, bei denen Live-Bild n.i.O. war, sind i.O.
    - Mit Timeshift (kurzer Versatz von 1 - 2 Sekunden) ist auch alles i.O.
    - Auffällig sind vor allem Sender der Pro7-Gruppe.
    - Ort und Stromkreis des VDRs im Haus ist unabhängig.
    - Ob Kernel- oder Olivers Exp.-Treiber ist auch egal.
    - Unter easyVDR mit identischer Hardware tritt kein Fehler auf.


    Was ist hier los? Habt Ihr Tipps?


    Danke und Grüße,
    Stefan



    2013-05-13T20:13:49.863988+02:00 susevdrtest kernel: [ 1518.963744] stv0299: stv0299_read_status : FE_READ_STATUS : VSTATUS: 0x80
    2013-05-13T20:13:50.833074+02:00 susevdrtest kernel: [ 1519.932132] dvb-ttpci: dvb_video_ioctl(): av7110:ffff88002e174000, cmd=800c6f37
    2013-05-13T20:13:50.874040+02:00 susevdrtest kernel: [ 1519.973195] stv0299: stv0299_read_status : FE_READ_STATUS : VSTATUS: 0x81
    2013-05-13T20:13:51.832967+02:00 susevdrtest kernel: [ 1520.931209] dvb-ttpci: dvb_video_ioctl(): av7110:ffff88002e174000, cmd=800c6f37
    2013-05-13T20:13:51.884994+02:00 susevdrtest kernel: [ 1520.982656] stv0299: stv0299_read_status : FE_READ_STATUS : VSTATUS: 0x81


    2013-05-13T20:13:52.082007+02:00 susevdrtest kernel: [ 1521.179604] dvb-ttpci: dvb_video_ioctl(): av7110:ffff88002e174000, cmd=6f22
    2013-05-13T20:13:52.082039+02:00 susevdrtest kernel: [ 1521.179667] dvb-ttpci: dvb_audio_ioctl(): av7110:ffff88002e174000, cmd=6f0c
    2013-05-13T20:13:52.084009+02:00 susevdrtest vdr: [1443] ERROR: TS packet not accepted in Transfer Mode


    2013-05-13T20:13:52.716997+02:00 susevdrtest kernel: [ 1521.813303] dvb-ttpci: dvb_video_ioctl(): av7110:ffff88002e174000, cmd=6f22
    2013-05-13T20:13:52.717029+02:00 susevdrtest kernel: [ 1521.813488] dvb-ttpci: dvb_audio_ioctl(): av7110:ffff88002e174000, cmd=6f0c
    2013-05-13T20:13:52.718976+02:00 susevdrtest vdr: [1443] ERROR: TS packet not accepted in Transfer Mode
    2013-05-13T20:13:52.833962+02:00 susevdrtest kernel: [ 1521.930274] dvb-ttpci: dvb_video_ioctl(): av7110:ffff88002e174000, cmd=800c6f37
    2013-05-13T20:13:52.895999+02:00 susevdrtest kernel: [ 1521.992216] stv0299: stv0299_read_status : FE_READ_STATUS : VSTATUS: 0x82

    Einmal editiert, zuletzt von 447377 ()

  • Welche Firmware nutzt Du? Evtl. hatte easyvdr ne andere als Du jetzt benutzt. Hier gibts die neueste: http://www.escape-edv.de/endriss/firmware/
    Rausfinden kannst Du die momentan genutzte Version mit:

    Code
    > dmesg|grep rtsl
    [    6.064383] dvb-ttpci: info @ card 1: firm f0240009, rtsl b0250018, vid 71010068, app c0fb2624

    Wobei hinter "app" die fb2624 die Version ist.
    Ist die FF-Karte gemoddet oder Original?

  • Die 24er Firmware von Oliver nutze ich. EasyVDR nutzt die 23er - mit der ich aber die gleichen Probleme habe.
    Die Karte ist nicht gemoddet und hat die originalen 2 MB.


    Gruß,
    Stefan


    EDIT: EasyVDR 1.0 nutz auch die neueste Firmware fb2624. Was ist dort noch anders?

    2 Mal editiert, zuletzt von 447377 ()

  • Sorry, dvb-ttpci-01.fw-fb2624 vom 27.02.10

  • Mittlerweile geht's. Nur ob das wohl so i.O. ist?
    Auf der Suche nach der Quelle der Ausgabe von "ERROR: TS packet not accepted in Transfer Mode" fand ich die Datei transfer.c - dort war eingetragen:
    #define MAXRETRIES 5 // max. number of retries for a single TS packet
    #define RETRYWAIT 5 // time (in ms) between two retries


    Die MAXRETRIES setzte ich auf 20 hoch und siehe da, keine Störungen mehr. :D


    Dann fiel mir meine alte vdr 1.7.31-Installation auf. Hier war 100 und 10 eingetragen.
    - Wieso wurde das so drastisch reduziert?
    - Hat das Hochsetzen irgendwelche negativen Folgen?
    Gehe ich richtig der Annahme, dass das eine Art Puffer für die Ausgabe ist, die nach einer bestimmten Anzahl alles verwirft (-> Bild- und Tonstörungen als Ergebnis) und dann wieder von vorne beginnt?
    Weshalb habe ich das fast nur bei Sendern der Pro7-Gruppe? Bei Sat.1 ist es besonders auffällig. Senden die nicht ganz korrekte Audio-Daten? Aber: Aufnahmen sind alle i.O.


    Vielleicht kann mich hier jemand aufklären und mich nicht mehr in der Unwissenheit belassen. ?(


    Grüße,
    Stefan


  • Ich hatte das damals umgestellt, weil sich hier jemand (ziemlich lauthals) beschwert hatte, daß sich die SD-FF-DVB-Karte an Daten, mit denen sie nichts anfangen konnte, "verschluckte" und dadurch u.U. Aufnahmen auf dem selben Device blockierte. Inzwischen wurden aber in Treiber (und Firmware?) der Karte Verbesserungen eingebaut, so daß das nicht mehr vorkommen sollte.
    Ich werde in der nächsten Maintenance-Release diesen Wert mal auf 20 erhöhen.


    Klaus

  • Hallo Klaus,


    danke für die Info.


    ...Aufnahmen auf demselben Device blockierte... -> betrifft das nur gemoddete SD-FF-Karten, mit denen aufgenommen und wiedergegeben wird?
    Ich habe den Wohnzimmer-VDR (4 Tuner mit Unicable) nun auch umgestellt. Falls die 20 nicht reichen sollten, melde ich mich nochmal bei Dir.


    Mit der HD-FF habe ich übrigens keine Probleme feststellen können. Liegt das am Treiber oder hat die einen größeren Puffer?


    Grüße,
    Stefan

  • Hi,


    ich habe hier ähnliches festgestellt, aber mit xinelibout und einer Cine 5.5.
    Ich habe hier 2 fast identische Setups. Bei einem davon habe ich noch nie diese Meldung gesehen und beim anderen kommt diese Meldung 2-3x am Tag.
    Interessant wäre zu wissen woher das kommt. Da fällt mir noch ein, das bei dem störenden Setup 2 Disec's noch mit dranhängen.


    Stelle ich dem Wert höher wird es besser. DIe alte transfer.c war da deutlich robuster.


    Just my 2Cents.


    Alex

    Server: CPU J1900 | 1x CineS2 | Debian Bullseye headless| VDR 2.6.3
    Client: 2x Himbeere mit vdr

Jetzt mitmachen!

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