Neue Testversion FA2623 für AV7110 firmware

Zitat

Original von viking
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.

So soll's sein.

Zitat

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

Alles anzeigen

Hm - sieht ja irgendwie nach einer Art ARM-Crash aus. Ein Treiber-Reload muß aber in jedem Fall helfen, da dabei das Ding zurückgesetzt wird. Was steht denn im Log, wenn der Treiber-Reload schief geht?

CU
Oliver

Zitat

Original von vikingmal ein bischen positives feedback

mit WSS in der fa2623 klappt es super mit meinem Phillips röhren-fernseher.

Bei mir klappt die Umschaltung schon seid jeher - aber auch mit der neuen Firmware klappt es immer noch perfekt (Röhrenfernseher von Panasonic).

Skobi

Zitat

Original von UFO
Hm - sieht ja irgendwie nach einer Art ARM-Crash aus. Ein Treiber-Reload muß aber in jedem Fall helfen, da dabei das Ding zurückgesetzt wird. Was steht denn im Log, wenn der Treiber-Reload schief geht?

Einige module lassen sich nicht entladen, deshalb ist der reboot notwendig. Das ist eine "debug ausgabe" (was ich in mein start/stop script drin habe = "lsmod | head -n 10|logger") nach mehrmaligem entladen des treibers mit "insmod.sh unload" :

Jan 23 00:21:07 vdr logger: DVB Driver unloaded ?
Jan 23 00:21:07 vdr logger: Module                  Size  Used by
Jan 23 00:21:07 vdr logger: budget                 11776  38
Jan 23 00:21:07 vdr logger: budget_core             9732  1 budget
Jan 23 00:21:07 vdr logger: dvb_ttpci              97728  8
Jan 23 00:21:07 vdr logger: ttpci_eeprom            3072  2 budget_core,dvb_ttpci
Jan 23 00:21:07 vdr logger: saa7146_vv             50688  1 dvb_ttpci
Jan 23 00:21:07 vdr logger: saa7146                18568  4 budget,budget_core,dvb_ttpci,saa7146_vv
Jan 23 00:21:07 vdr logger: s5h1420                 9604  1 budget
Jan 23 00:21:07 vdr logger: stv0297                 8576  1 dvb_ttpci
Jan 23 00:21:07 vdr logger: tda8083                 6532  2 budget,dvb_ttpci

sonst ist beim entladen nur sowas wie "module XYZ in use by XYZ" - wenn es hilft kann ich die das gerne per PM senden.

skobi
Bei mir hat es auch immer funktioniert, das war aber die "bilderkennung " des fernsehers und das hat dann immer ein bischen gedauert - 1-5 sek. Jetzt ist das bild sofort so wie es sein sollte

Oliver
Aus meiner sicht hat sich der aufwand also auf jeden fall gelohnt

Gruß
Viking

Zitat

Original von viking
skobi
Bei mir hat es auch immer funktioniert, das war aber die "bilderkennung " des fernsehers und das hat dann immer ein bischen gedauert - 1-5 sek. Jetzt ist das bild sofort so wie es sein sollte

Eine Bilderkennung hat mein TV auch, die dauert aber gut 10sek. - dabei betrachtet er einfach nur einen sehr dunklen Rahmen um das Bild, und zoomt dann bei Bedarf auf.
Jedoch hat auch schon mit älterer Firmware eine echte Erkennung geklappt, d.h. der Fernseher ist selbstständig und sofort auf z.B. 'WIDE' gegangen, also nicht in den einfachen Zoom-Modus via 'Bilderkennung' - gab es glaub auch nur bei ZDF und Co.

Leider ist die FA263 nichts für meinen Sony 16:9 Fernseher.
Die letze Firmware, die richtig umgeschalten hat (und ich noch griffbereit habe), war FF261, also die hier:

dvb-ttpci: info @ card 2: firm f0240009, rtsl b0250018, vid 71010068, app 80ff2621

Die neue FA263, hat hier i.a. sehr flottes Umschalten zwischen den Formaten (ich glaube, dass das früher lahmer war).
16:9-Filme laufen auch lange "stabil", ich kann mich nicht daran erinnern, dass da einmal ein falsches Format gesetzt wurde.
ABER das 4:3-Bild ist nicht stabil, da zuckt der TV öfter kurz nach 16:9, dann wieder zurück zum richtigen Format. Bei einigen Filmen/Sendern kommt das eher selten vor, bei anderen Sendungen auch mehrmals pro Minute.
=> Das aktuelle Verhalten der firmware ist für meinen TV nicht zu gebrauchen.

Was wurde denn eigentlich seit 261 geändert? Ich kann nirgends ein changelog finden.
Kann man das alte WS-Umschalten nicht wieder einführen?

Zitat

Original von shh
16:9-Filme laufen auch lange "stabil", ich kann mich nicht daran erinnern, dass da einmal ein falsches Format gesetzt wurde.
ABER das 4:3-Bild ist nicht stabil, da zuckt der TV öfter kurz nach 16:9, dann wieder zurück zum richtigen Format. Bei einigen Filmen/Sendern kommt das eher selten vor, bei anderen Sendungen auch mehrmals pro Minute.

Möglicherweise ist dies ein ähnliches Problem, wie es Dr. Seltsam weiter oben beschrieben hat.

Tritt dies auch beim Abspielen von Aufnahmen auf? Falls ja, wäre ich für ein Aufnahmeschnipsel dankbar, wo dies gehäuft auftritt.

Zitat

Was wurde denn eigentlich seit 261 geändert? Ich kann nirgends ein changelog finden.
Kann man das alte WS-Umschalten nicht wieder einführen?

Detailliertere Angaben als bereits hier im Thread bzw. auf http://linuxtv.org/downloads/firmware/ kann ich leider nicht machen (Stichwort NDA).

Falls Du einen aktuellen Treiber hast und kompilieren kannst, könntest Du mit http://escape-edv.de/endriss/dvb/wsstest.c experimentieren. Interessant wäre für mich, ob das Bild auch zuckt, wenn man mit wsstest fix auf 4:3- bzw. 16:9 einstellt.

CU
Oliver

Zitat

Tritt dies auch beim Abspielen von Aufnahmen auf? Falls ja, wäre ich für ein Aufnahmeschnipsel dankbar, wo dies gehäuft auftritt.

Ja, tritt auch bei Aufnahmen auf.
Ich bin gerade dabei, einen Schnipsel zu isolieren. Ein Teil hier hat ~21MB, da schaltet er 3mal nach 16:9 hin und zurück.
Ist das zu groß? Ich weiß leider nicht, wie ich die .vdr Datei schneiden kann.

Hin+Herschalten:
1. Da wo Kitt zum ersten Mal von rechts nach links rauscht.
2. Da wo Kitt nach vorne auf den Zuschauer zufährt.
3. (nicht immer) Ziemlich am Ende, wo sich der "Junge" beim Tanken zu Michael hinwendet. Da konnte ich aber mal einen Stop-Punkt finden, wo der TV wärend des Standbilds dauerhaft im 1-3sek Takt hin und her geschalten hat.

Außerdem habe ich ein Foto gemacht, wo der TV gerade auf 16:9 stehenbleibt (naja sehr lange, bis es mal ein Zucken nach 4:3 gibt, dann wieder nach 16:9)
Foto: http://www.sysh.de/schnipsel/DSC_0012.JPG

Datei: (Vorsicht! 21MB)
Bitte nur runterladen, wer's wirklich braucht!
http://www.sysh.de/schnipsel/2006-02-08.17.30.50.99.rec.zip

Zitat

mit wsstest.c experimentieren

Ist es dafür nötig die dvb-Module zu kompilieren, oder reicht es die wsstest.c zu kompilieren?
Reichen die Standardmodule vom 2.6.15er, oder braucht wsstest Erweiterungen der dvb-module?

Was anderes:
Leider bekomme ich mit der Firmware auch ARM-crashes:
(An einem FernsehAbend mehrmals, leider auch mit der ff261)
zB:

/var/log/kern.log
Feb  8 16:15:50 vdr kernel: dvb-ttpci: warning: timeout waiting in LoadBitmap: 0, 1
Feb  8 16:15:50 vdr kernel: dvb-ttpci: StopHWFilter error  cmd 0b08 0001 0008  ret 0  resp 0008 ffff  pid 1028
Feb  8 16:15:50 vdr kernel: dvb-ttpci: StopHWFilter error  cmd 0b08 0001 0007  ret 0  resp 0007 ffff  pid 16
Feb  8 16:15:50 vdr kernel: dvb-ttpci: StopHWFilter error  cmd 0b08 0001 0000  ret 0  resp 0000 ffff  pid 1229
Feb  8 16:15:50 vdr kernel: dvb-ttpci: StopHWFilter error  cmd 0b08 0001 0006  ret 0  resp 0006 ffff  pid 17
Feb  8 16:15:50 vdr kernel: dvb-ttpci: StopHWFilter error  cmd 0b08 0001 0005  ret 0  resp 0005 ffff  pid 0
Feb  8 16:15:50 vdr kernel: dvb-ttpci: StopHWFilter error  cmd 0b08 0001 0004  ret 0  resp 0004 ffff  pid 20
Feb  8 16:15:50 vdr kernel: dvb-ttpci: StopHWFilter error  cmd 0b08 0001 0001  ret 0  resp 0001 ffff  pid 18
Feb  8 16:15:50 vdr kernel: dvb-ttpci: StopHWFilter error  cmd 0b08 0001 0002  ret 0  resp 0002 ffff  pid 18
Feb  8 16:15:50 vdr kernel: dvb-ttpci: StopHWFilter error  cmd 0b08 0001 0003  ret 0  resp 0003 ffff  pid 18

In /etc/modprobe.d/dvb-ttpci habe ich für das Modul hw_sections=0 gesetzt, was ja gegen crashes helfen soll...
Hilft aber offenbar nichts

Grüße...

Zitat

Original von shh

Ja, tritt auch bei Aufnahmen auf.
Ich bin gerade dabei, einen Schnipsel zu isolieren. Ein Teil hier hat ~21MB, da schaltet er 3mal nach 16:9 hin und zurück.
Ist das zu groß? Ich weiß leider nicht, wie ich die .vdr Datei schneiden kann.

Die Größe ist kein Problem. Btw, Schneiden kann man mit vdr.

Zitat

Ist es dafür nötig die dvb-Module zu kompilieren, oder reicht es die wsstest.c zu kompilieren?
Reichen die Standardmodule vom 2.6.15er, oder braucht wsstest Erweiterungen der dvb-module?

Die nötigen Treibererweiterungen sind leider erst in Kernel 2.6.16-rc1 vorhanden.

Zitat

Was anderes:
Leider bekomme ich mit der Firmware auch ARM-crashes:
(An einem FernsehAbend mehrmals, leider auch mit der ff261)
[/code]

Daran dürfte sich eigentlich auch nichts geändert haben.
Der neuere Treiber enthält allerdings eine Crash-Recovery, d.h. man braucht die Treiber nicht mehr neu zu laden...

CU
Oliver

Zitat

Die nötigen Treibererweiterungen sind leider erst in Kernel 2.6.16-rc1 vorhanden.

Ich habe hier einen v4l-dvb-wss-v2.diff auf 2.6.15 angewendet, der ordentlich durchlief. Reicht das?

Ich bekomme nur die wsstest.c nicht kompiliert.

vdr:/usr/src# gcc wsstest.c
wsstest.c: In function 'main':
wsstest.c:33: error: storage size of 'vbicap' isn't known
wsstest.c:35: error: storage size of 'data' isn't known
wsstest.c:63: error: 'VIDIOC_G_SLICED_VBI_CAP' undeclared (first use in this function)
wsstest.c:63: error: (Each undeclared identifier is reported only once
wsstest.c:63: error: for each function it appears in.)
wsstest.c:75: warning: incompatible implicit declaration of built-in function 'memset'
wsstest.c:76: error: 'V4L2_BUF_TYPE_SLICED_VBI_OUTPUT' undeclared (first use in this function)
wsstest.c:77: error: 'union <anonymous>' has no member named 'sliced'
wsstest.c:77: error: 'V4L2_SLICED_WSS_625' undeclared (first use in this function)
wsstest.c:97: error: 'union <anonymous>' has no member named 'sliced'
wsstest.c:97: error: 'union <anonymous>' has no member named 'sliced'
wsstest.c:98: error: 'union <anonymous>' has no member named 'sliced'
vdr:/usr/src#

Was tun?

Du gibst Bescheid, wenn du was an meinem Schnipsel findest?

Grüße....

Zitat

Original von shh

Ich habe hier einen v4l-dvb-wss-v2.diff auf 2.6.15 angewendet, der ordentlich durchlief. Reicht das?

Ja.

Zitat

Ich bekomme nur die wsstest.c nicht kompiliert.

Code

vdr:/usr/src# gcc wsstest.c
wsstest.c: In function 'main':
wsstest.c:33: error: storage size of 'vbicap' isn't known
wsstest.c:35: error: storage size of 'data' isn't known
wsstest.c:63: error: 'VIDIOC_G_SLICED_VBI_CAP' undeclared (first use in this function)
wsstest.c:63: error: (Each undeclared identifier is reported only once
wsstest.c:63: error: for each function it appears in.)
wsstest.c:75: warning: incompatible implicit declaration of built-in function 'memset'
wsstest.c:76: error: 'V4L2_BUF_TYPE_SLICED_VBI_OUTPUT' undeclared (first use in this function)
wsstest.c:77: error: 'union <anonymous>' has no member named 'sliced'
wsstest.c:77: error: 'V4L2_SLICED_WSS_625' undeclared (first use in this function)
wsstest.c:97: error: 'union <anonymous>' has no member named 'sliced'
wsstest.c:97: error: 'union <anonymous>' has no member named 'sliced'
wsstest.c:98: error: 'union <anonymous>' has no member named 'sliced'
vdr:/usr/src#

Alles anzeigen

Was tun?

Vermutlich ist /usr/include/linux/videodev2.h zu alt. Probier's mal mit der entsprechenden Datei aus dem Kernel (/usr/src/linux-2.6.15/include/linux/videodev2.h).

Zitat

Du gibst Bescheid, wenn du was an meinem Schnipsel findest?

Sicher.

CU
Oliver

wsstest ausprobiert mit folgenden Resultaten:
Zur Erinnerung: Ich habe nen Sony 16:9 TV

- : Keine Änderung feststellbar
SMART: Pseudo-Zoom. 4:3-Bild wird auf 16:9 eingepasst (igitt!)
ZOOM: 4:3 Material wird mit Erhalt der aspect-ratio gezoomed
4:3: Normales 4:3 Vollbild
16:9: Vollbild für anamorphe Quellen. Quelle wird nur horiz. auf 16:9 gestreckt

0: -
1: SMART
2: SMART
3: -
4: ZOOM
5: -
6: -
7: 16:9
8: 4:3
9: -
a: -
b: ZOOM
c: -
d: ZOOM
e: SMART
f: -

Problem:
Das Zurückschalten von 16:9 nach 4:3 klappt manchmal nicht. Es kommt zwar oft sofort, aber halt nicht immer. Durchschnittl. vielleicht jedes 20ste Mal bleibt der TV im 16:9-Modus hängen und schaltet schätzungsweise erst nach weiteren 10/20/30sek von selber nach 4:3 zurück.

Irgendwie sind die Pegel also zusehr am 16:9-Modus dran, sodass der TV entweder
- zu leicht (unnötig) nach 16:9 schaltet
oder
- nicht erkennt, wenn er 16:9 verlassen soll.

Wo werden diese WSS-Pegel eigentlich erzeugt? In der Firmware?
Komischerweise hatte ich das Problem vor den 262er firmware-Versionen noch nicht.
Vielleicht wichtig: Mein TV hängt via externer FBAS-Stecker -> SCART-Kabel an der TT-Karte (rev. 1.5) dran

Grüße...

Zitat

Original von UFO
Interessant wäre für mich, ob das Bild auch zuckt, wenn man mit wsstest fix auf 4:3- bzw. 16:9 einstellt.

Hab das jetzt auch gechecked:
Das kurze Schalten nach 16:9 und zurück gibt's auch, wenn ich wss fest auf 8 (=4:3) setze.

Edit:
D.h. aber dann, dass irgendwas mit dem WSS=8 in Verbindung mit meinem TV nicht stimmt. Oder, dass bestimmte Bilder den WSS=8 killen.
Was mich zur Frage zurück bringt, wer denn die Signale letzten Endes für den TV erzeugt. Die Firmware? Die Kartenhardware selber?

Wie war's denn früher? Da wurde doch gar kein WSS gesendet, oder?
Dann bräuchte mein TV zwangsläufig eine modul-Option (für dvb-ttpci ?) die die firmware anweist, statt WSS=8 *gar*nichts* zu senden, denn früher hat das so ja geklappt.
Oder beim Umschalten zu 4:3 zumindest ein paar frames lang WSS=8 senden und später nichts mehr.

Hi shh, ufo,

das problem mit dem wechsel zwischen 16:9 4:3 habe ich an einem projector pansonic pt ae700e ebenfalls, jedoch nur am Scart SVideo funktioniert. Leihweise habe ich einen pt ae900e angeschlossen hier ist die WSS Erkennung in Ordnung d.h. kein ständiger wechsel weder bei Scart noch SVideo.
Den pt-ae700e habe ich zu Panasonic gesendet um einen firmware update machen zu lassen. Gerät ist jedoch noch nicht wieder da. Werde mich dann melden und berichten.

IMHO liegt das Problem am Endgerät und nicht an der Firmware.

Gruß
Gerald

Die Firmware 261 macht ebenfalls die 16:9 4:3 Umschalt Probleme am Scart Ausgang.

Ich würde bei dieser Thematik mal den Übertragungsweg - sprich die Verkabelung - mit in Betracht ziehen. Wir reden hier über eine analoge Übertragungsstrecke. Bei langen Kablenstrecken, schlechter Dämpfung, nicht abgestimmter Impedanz (Auskopplung von JP2 ohne entsprechende Beschaltung) etc. könnten z.B. Phasendreher und Übermodulationen die Bits schwammig machen, was man an der Bildqualität nicht unbedingt sehen muss...

> langen Kablenstrecken, schlechter Dämpfung, nicht abgestimmter Impedanz

Bei mir ist's am Chinch-Ausgang angeschlossen, auch mehrere verschiedene sehr kurze HQ-SCART-Kabel bringen den selben Effekt. Auf den SCART-Kabeln wird auch kein Sound mitgeschickt, was evtl noch extra stören könnte. Bitdreher kann man zumindest bei mir glaube ich ausschließen.
Wie bereits gesagt, bei der firmware FF2621 funktioniert das 4:3/16:9-Umschalten tadellos, wenn auch etwas träge.

Wo müsste man denn rumbasteln, wenn man loggen möchte, was denn die FF-Karte gerade für ein WSS rausschickt. Oder zB jede Veränderung loggen lassen.
Locked denn wsstest wirklich dauerhaft das WSS-Signal? Oder kann das noch von woaders her verändert werden?

Edit
Hab mal mit nem veränderten wsstest den Status während der Pause ausgelesen. Keine Ahnung, ob das blöd war, aber da verändert sich nichts an den WSS Signalen. Vermutlich stimmt da irgendwas auf der Karte selber nicht.
Ich habe jetzt auch ein anderes Chinch-Kabel an einem anderen Eingang am TV ausprobiert: Gleicher Effekt. Irgendwas ist an den Signalen für ein normales 4:3-Bild krumm.

Nochwas anderes zur FA2623:
femon schaffts sehr schnell das Teil zum Aufhängen zu bringen (Bild steht), aber die firmware "rebootet" nicht. Trotz mehrmaligem Umschalten und/oder Warten.

Feb  9 16:29:24 vdr kernel: dvb-ttpci: __av7110_send_fw_cmd(): timeout waiting for COMMAND idle
Feb  9 16:29:24 vdr kernel: dvb-ttpci: av7110_send_fw_cmd(): av7110_send_fw_cmd error -110
Feb  9 16:29:24 vdr kernel: dvb-ttpci: av7110_fw_cmd error -110
Feb  9 16:29:25 vdr kernel: dvb-ttpci: __av7110_send_fw_cmd(): timeout waiting for COMMAND idle
Feb  9 16:29:25 vdr kernel: dvb-ttpci: av7110_send_fw_cmd(): av7110_send_fw_cmd error -110
Feb  9 16:29:25 vdr kernel: dvb-ttpci: av7110_fw_cmd error -110
Feb  9 16:29:26 vdr kernel: dvb-ttpci: __av7110_send_fw_cmd(): timeout waiting for COMMAND idle
...
Feb  9 16:29:29 vdr kernel: dvb-ttpci: av7110_send_fw_cmd(): av7110_send_fw_cmd error -110
Feb  9 16:29:29 vdr kernel: dvb-ttpci: av7110_fw_cmd error -110
Feb  9 16:29:31 vdr kernel: av7110_wait_msgstate: timeout waiting for MSGSTATE 0040
Feb  9 16:29:32 vdr kernel: dvb-ttpci: __av7110_send_fw_cmd(): timeout waiting for COMMAND idle
Feb  9 16:29:32 vdr kernel: dvb-ttpci: av7110_send_fw_cmd(): av7110_send_fw_cmd error -110
Feb  9 16:29:32 vdr kernel: dvb-ttpci: av7110_fw_cmd error -110
...
Feb  9 16:29:52 vdr kernel: dvb-ttpci: __av7110_send_fw_cmd(): timeout waiting for COMMAND idle
Feb  9 16:29:52 vdr kernel: dvb-ttpci: av7110_send_fw_cmd(): av7110_send_fw_cmd error -110
Feb  9 16:29:52 vdr kernel: dvb-ttpci: av7110_fw_cmd error -110
Feb  9 16:29:53 vdr kernel: av7110_wait_msgstate: timeout waiting for MSGSTATE 0040
Feb  9 16:29:54 vdr kernel: dvb-ttpci: __av7110_send_fw_cmd(): timeout waiting for COMMAND idle
Feb  9 16:29:54 vdr kernel: dvb-ttpci: av7110_send_fw_cmd(): av7110_send_fw_cmd error -110
Feb  9 16:29:54 vdr kernel: dvb-ttpci: av7110_fw_cmd error -110
...
Feb  9 16:30:06 vdr kernel: dvb-ttpci: __av7110_send_fw_cmd(): timeout waiting for COMMAND idle
Feb  9 16:30:06 vdr kernel: dvb-ttpci: av7110_send_fw_cmd(): av7110_send_fw_cmd error -110
Feb  9 16:30:06 vdr kernel: dvb-ttpci: av7110_fw_cmd error -110
...
Feb  9 16:30:17 vdr kernel: dvb-ttpci: av7110_send_fw_cmd(): av7110_send_fw_cmd error -110
Feb  9 16:30:17 vdr kernel: dvb-ttpci: av7110_fw_cmd error -110
Feb  9 16:30:19 vdr kernel: dvb-ttpci: __av7110_send_fw_cmd(): timeout waiting for COMMAND idle
Feb  9 16:30:19 vdr kernel: dvb-ttpci: av7110_send_fw_cmd(): av7110_send_fw_cmd error -110
Feb  9 16:30:19 vdr kernel: dvb-ttpci: av7110_fw_cmd error -110

Eigentlich ist schon ab Kernel-Meldung

Feb  9 16:29:24 vdr kernel: dvb-ttpci: __av7110_send_fw_cmd(): timeout waiting for COMMAND idle
Feb  9 16:29:24 vdr kernel: dvb-ttpci: av7110_send_fw_cmd(): av7110_send_fw_cmd error -110
Feb  9 16:29:24 vdr kernel: dvb-ttpci: av7110_fw_cmd error -110

nur noch schwarz zu sehen. Kann man ab der Meldung die firmware nicht neu starten lassen? Die Meldung kommt ja nur, wenn schon irgendwas hängt, oder?

Grüße...

Zitat

Original von shh
Problem:
Das Zurückschalten von 16:9 nach 4:3 klappt manchmal nicht. Es kommt zwar oft sofort, aber halt nicht immer. Durchschnittl. vielleicht jedes 20ste Mal bleibt der TV im 16:9-Modus hängen und schaltet schätzungsweise erst nach weiteren 10/20/30sek von selber nach 4:3 zurück.

Sehr merkwürdig. Denn eigentlich sollte die WSS-Information in der Austastlücke jedes Frames gesendet werden. Wie solche Verzögerungen zustande kommen könnten, erschließt sich mir nicht.

Zitat

Irgendwie sind die Pegel also zusehr am 16:9-Modus dran, sodass der TV entweder
- zu leicht (unnötig) nach 16:9 schaltet
oder
- nicht erkennt, wenn er 16:9 verlassen soll.

Wo werden diese WSS-Pegel eigentlich erzeugt? In der Firmware?

Alles anzeigen

Es gibt keine "Pegel". WSS ist ein Bitmuster, das in der Austastlücke übertragen wird. Genaueres siehe ETSI-Standard (vgl. WSS-Thread). Wie das Signal auf der Karte erzeugt wird, ist nicht dokumentiert.

Zitat

Komischerweise hatte ich das Problem vor den 262er firmware-Versionen noch nicht.

Bis einschließlich 2622 wird bei 4:3 gar kein WSS gesendet. Wurde geändert, da gewisse Fernseher ohne WSS nicht auf 4:3 schalten.

Zitat

Vielleicht wichtig: Mein TV hängt via externer FBAS-Stecker -> SCART-Kabel an der TT-Karte (rev. 1.5) dran.

Hm, gibt's da nicht so ein Scart-Signal, mit dem man zwischen 16:9 und 4:3 umschalten kann?
Evtl. funkt da etwas dazwischen?

CU
Oliver

Zitat

Original von shh

Hab das jetzt auch gechecked:
Das kurze Schalten nach 16:9 und zurück gibt's auch, wenn ich wss fest auf 8 (=4:3) setze.

Überrascht mich nicht wirklich. Ich habe die FW gecheckt. Auch mit Deinem Filmschnipsel passiert nichts Ungewöhnliches. WSS sollte stabil sein...

Zitat

Wie war's denn früher? Da wurde doch gar kein WSS gesendet, oder?
Dann bräuchte mein TV zwangsläufig eine modul-Option (für dvb-ttpci ?) die die firmware anweist, statt WSS=8 *gar*nichts* zu senden, denn früher hat das so ja geklappt.
Oder beim Umschalten zu 4:3 zumindest ein paar frames lang WSS=8 senden und später nichts mehr.

Wenn sonst nichts hilft, bleibt wohl nichts anderes übrig.

Gib mir mal Deine Mailadresse (per PM oder Mail). Ich möchte Dir eine Firmware zum Testen schicken...

CU
Oliver

Zitat

Original von shh
Wo müsste man denn rumbasteln, wenn man loggen möchte, was denn die FF-Karte gerade für ein WSS rausschickt. Oder zB jede Veränderung loggen lassen.

Was wirklich generiert wird, könnte man nur mit Meßequipment ermitteln, das die Signale in der Austastlücke darstellen kann.

Zitat

Locked denn wsstest wirklich dauerhaft das WSS-Signal? Oder kann das noch von woaders her verändert werden?

Imho ja. Die Information im Datenstrom wird ignoriert.

Zitat

Nochwas anderes zur FA2623:
femon schaffts sehr schnell das Teil zum Aufhängen zu bringen (Bild steht), aber die firmware "rebootet" nicht. Trotz mehrmaligem Umschalten und/oder Warten.

Der Videodecoder der Karte ist bekanntermaßen empfindlich. Wenn beim Umschalten in femon kurzzeitig Schrottdaten angeliefert werden, kann das die FW killen...

Zitat

Kann man ab der Meldung die firmware nicht neu starten lassen? Die Meldung kommt ja nur, wenn schon irgendwas hängt, oder?

Wie schon früher geschrieben, wird mit Treibern ab Kernel 2.6.16 (oder aktuellen Hg-Treibern) genau das gemacht.

CU
Oliver

Zitat

Original von bitstreamout

Über S-Video wird kein WSS übertragen, das funktioniert nur bei
PAL und FBAS bzw. RGB über das Sync-Signal, also auch FBAS.

Über S-Video wird WSS übertragen, wie auch im FBAS/Composite in der Luminace.
Ich habe einen Panasonic PT AE 700, bei dem WSS über S-Video sauber funktioniert. Ich gucke bei Gelegenheit mal nach dem Firmwarestand.