Neue Testversion FA2623 für AV7110 firmware

Hi!

Zitat

Original von UFO
@all:
Zunächst wäre es gut, wenn möglichst viele die neue Firmware testen würden.

Danke für die neue Firmware. Sie funktioniert hier (Nokia-Fernseher ... Bezeichnung weiß ich leider nicht genau) einwandfrei. Ich bekomme auch keine falschen Videoevents mehr und das Videosystem-Plugin funktioniert auch wieder wie zuvor.

Gruß,
Brougs78

Zitat

Original von UFO
Dies hängt möglicherweise vom TV ab.

Tja, vorausgesetzt ich habe beim Übersetzen nichts falschgemacht, interessiert sich der
Fernseher nicht für WSS.

BTW: wIe sieht man übrigens, welche genaue Firmware Version man aktiviert hat?

Zitat

DVB: registering new adapter (Technotrend/Hauppauge WinTV Nexus-S rev2.X).
Jan 22 20:08:02 hermes kernel: adapter has MAC addr = 00:d0:5c:22:d0:03
Jan 22 20:08:02 hermes kernel: dvb-ttpci: info @ card 1: firm f0240009, rtsl b0250018, vid 71010068, app 80fd2623
Jan 22 20:08:02 hermes kernel: dvb-ttpci: firmware @ card 1 supports CI link layer interface
Jan 22 20:08:02 hermes kernel: dvb-ttpci: Crystal audio DAC @ card 1 detected
Jan 22 20:08:02 hermes kernel: saa7146_vv: saa7146 (1): registered device video0 [v4l2]
Jan 22 20:08:02 hermes kernel: DVB: registering frontend 1 (ST STV0299 DVB-S)...

Alles anzeigen

Etwas hier offtopic: ist es prinzipiell möglich, die Ausgabe vom DVB dauerhaft auf 16:9 zu schalten und für 4:3 senkrechte schwarze Balken zu erzeugen?

Ulrich

Zitat

Original von ulho
Jan 22 20:08:02 hermes kernel: dvb-ttpci: info @ card 1: firm f0240009, rtsl b0250018, vid 71010068, app 80fd2623

fd2623, also nicht die aktuellste

Zitat

Original von jowi24

fd2623, also nicht die aktuellste

Nicht?

Ich habe die aus dem Link am Anfang des Threads genomenn (test_av-1.33.tar.bz2)
nach /usr/lib/hotplug/firmware/dvb-ttpci-01.fw-2623 gepackt
und dafur gesorgt, dass in der Linux config folgende Zeile steht:
CONFIG_DVB_AV7110_FIRMWARE_FILE="/usr/lib/hotplug/firmware/dvb-ttpci-01.fw-2623"

Böh, und das reicht nicht?

Ulrich

edit: es gibt in den linux sourcen die Datei drivers/media/dvb/ttpci/av7110_firm.h die anscheinend generiert
aber bei einem make clean nicht abgeräumt wird. Scheint, als ob ich in diese Falle getappt bin.

edit2: jetzt verwende ich wirklich die aktuelle firmware -- funktioniert aber trotzdem nicht.

Zitat

Ich habe die aus dem Link am Anfang des Threads genomenn (test_av-1.33.tar.bz2)
nach /usr/lib/hotplug/firmware/dvb-ttpci-01.fw-2623 gepackt
und dafur gesorgt, dass in der Linux config folgende Zeile steht:
CONFIG_DVB_AV7110_FIRMWARE_FILE="/usr/lib/hotplug/firmware/dvb-ttpci-01.fw-2623"

Mach doch einfach in /usr/lib/hotplug/firmware einen symbolischen link von der 2623 auf dvb-ttpci-01.fw, sonst sind keine weiteren Änderungen notwendig

Hi,

ich möchte nochmal auf ein Problem aufmerksam machen, das schon sehr lange (wenn nicht immer) da war.

Die Situation ist folgende:
video dev: VIDEO_SELECT_SOURCE -> VIDEO_SOURCE_MEMORY
audio dev: AUDIO_SELECT_SOURCE -> AUDIO_SOURCE_MEMORY
(d.h. VDR playmode pmAudioVideo)
Es werden PCM-Audiodaten an das Audio Device geschickt.
(d.h. mp3-plugin spielt Musik)
Irgendwann wird per VIDEO_STILLPICTURE ein Frame angezeigt.
(d.h. ein Coverbild wird angezeigt)
Man hat dann eine fast 100% Chance das der StillPicture ioctl() nie zurück kommt.

Wenn man zwischen dem letzten Senden von Audiodaten ans Audiodevice und dem VIDEO_STILLPICTURE eine Pause von 80-100ms läßt, dann geht es meistens gut.

Für mich sieht es so aus, das der StillPicture ioctl() immer hängt, wenn noch Audiodaten in der Queue sind. Wartet man etwas, ist die Queue leergelaufen und es klappt.

Kann das eine der Firmware-Gurus nachvollziehen?

Gruß
Stefan

Von diesem Problem habe ich noch nie gehört.
Kann man das irgendwie ohne mp3-Plugin reproduzieren?

CU
Oliver

P.S.:
Für Probleme, die nicht speziell mit dieser FW-Version zu tun haben, sollte man besser einen neuen Thread aufmachen.

Ich habe ein Problem beim selektieren von Dolby Digital (2.0 oder 5.1) bei verschlüsselten Kanälen (ORF, Premiere). Diese haben erst nach nochmaligem anwählen des gleichen Senders in der "Kanäle"-Liste Ton.
Bei einem Neustart des VDRs ist der Ton auch sofort da, nur nach erneutem umschalten ist die Prozedur mit der Kanalliste zu wiederholen.
Die Aufnahmen sind hiervon nicht betroffen.

Bei FreeTV Kanälen (Das Erste, ZDF, SAT1, Pro7) tritt das Problem nicht auf.

Dies tritt nicht auf mit der Firmware 261f aber bei allen? nachfolgenden, leider kann ich aufgrund der nicht immervorhandenen Versionierung keine Unterschiede bei den Zwischenversionen von 00261f bis ff2621 erkennen.

In einem älteren Thread wurde der beschriebene Bug schonmal erwähnt, ich habe das Posting aber leider nicht mehr gefunden

Leider weiß ich nicht ob das Problem wirklich durch die Firmware verursacht wird oder im CAM Handling des VDRs zu suchen ist.

Ach ja die Ausgabe des VDRs zeigt bei buffer stats: 122388 (5%) used an und wechselt nach kurzer Zeit auf 0 (0%), dem nochmaligen Auswählen des Senders über "Kanäle" bekomme ich direkt buffer stats: 2068 (0%) used also 0% Buffer.

Getestet habe ich es aktuell mit VDR 1.3.40 .

Zitat

Original von UFO
Von diesem Problem habe ich noch nie gehört.
Kann man das irgendwie ohne mp3-Plugin reproduzieren?

Du meinst außerhalb von vdr?
Ich müsste dann probieren ein Beispiel Programm zu machen.

Zitat

P.S.:
Für Probleme, die nicht speziell mit dieser FW-Version zu tun haben, sollte man besser einen neuen Thread aufmachen.

Es hat insoweit etwas mit dieser FW Version zu tun, als das ich aktuell einen Bugreport haben genau mit dieser FW Version.

Gruß
Stefan

Zitat

Original von UFO
Von diesem Problem habe ich noch nie gehört.
Kann man das irgendwie ohne mp3-Plugin reproduzieren?

Ja, mit dem muggle - Plugin.

Ich hatte dieses Problem schon mal auf der linux-dvb ML gemeldet, am 20.7.5:

Zitat

this is 2.6.12 with rather current cvs driver and firmware 261f

the muggle player now can show cover images.
When playing a track ends, the next image is displayed and the next track
starts playing. However when displaying the next image the driver
still has audio data to be processed. This seems to cause dvb_play_kernel()
to never return, it hangs forever in
wait_event_interruptible(av7110->avout.queue,FREE_COND)

I can fix this in muggle by sleeping for 1 second before displaying
the picture but still this seems like a driver bug. Maybe play_iframe()
should write into the aux_ring_buffer?

dprintk(1,"dvb_play_kernel before wait_event_interruptible,todo=%ld\n",todo);
rc = wait_event_interruptible(av7110->avout.queue, FREE_COND);
dprintk(1,"dvb_play_kernel after wait_event_interruptible\n");

Code

Jul 20 00:11:44 mm kernel: dvb-ttpci: aux_ring_buffer_write(): aux_ring_buffer_write
Jul 20 00:11:44 mm kernel: dvb-ttpci: av7110_pes_play(): av7110_pes_play(2048)
Jul 20 00:11:44 mm last message repeated 26 times
Jul 20 00:11:44 mm kernel: dvb-ttpci: aux_ring_buffer_write(): aux_ring_buffer_write
Jul 20 00:11:44 mm kernel: dvb-ttpci: aux_ring_buffer_write(): aux_ring_buffer_write
Jul 20 00:11:44 mm kernel: dvb-ttpci: av7110_pes_play(): av7110_pes_play(2048)
Jul 20 00:11:44 mm last message repeated 24 times
Jul 20 00:11:44 mm kernel: dvb-ttpci: aux_ring_buffer_write(): aux_ring_buffer_write
Jul 20 00:11:44 mm kernel: dvb-ttpci: av7110_pes_play(): av7110_pes_play(2048)
Jul 20 00:11:44 mm last message repeated 31 times
Jul 20 00:11:44 mm kernel: dvb-ttpci: aux_ring_buffer_write(): aux_ring_buffer_write
Jul 20 00:11:44 mm kernel: dvb-ttpci: aux_ring_buffer_write(): aux_ring_buffer_write
Jul 20 00:11:44 mm kernel: dvb-ttpci: dvb_video_ioctl(): av7110:c3970000, cmd=40086f1e
Jul 20 00:11:44 mm kernel: dvb-ttpci: dvb_video_ioctl(): VIDEO_STILLPICTURE:before play_iframe
Jul 20 00:11:44 mm kernel: dvb-ttpci: dvb_play_kernel(): dvb_play_kernel before wait_event_interruptible,todo=9
Jul 20 00:11:44 mm kernel: dvb-ttpci: av7110_pes_play(): av7110_pes_play(2048)
Jul 20 00:12:03 mm last message repeated 101738 times
Jul 20 00:12:03 mm kernel: -ttpci: av7110_pes_play(): av7110_pes_play(2048)
Jul 20 00:12:03 mm kernel: dvb-ttpci: av7110_pes_play(): av7110_pes_play(2048)
Jul 20 00:12:03 mm last message repeated 101738 times

Alles anzeigen

Alles anzeigen

Zitat

Original von wolfgang61

Ja, mit dem muggle - Plugin.

Das läuft wohl auf das gleiche heraus. Ich dachte an etwas einfaches, ohne daß ich erst einen Tag lang Datenbanken, Libraries und Plugins installieren muß...

Zitat

Ich hatte dieses Problem schon mal auf der linux-dvb ML gemeldet, am 20.7.5:

Kannst Du vor dem wait_event_interruptible mal die Werte dvb_ringbuffer_free(&av7110->avout) und dvb_ringbuffer_free(&av7110->aout) ausgeben lassen?

Ich vermute, daß der Audio-Ringbuffer so voll ist, daß FREECOND immer FALSE ist.
Löst sich das Problem, wenn man die Ausgabe der Audio-Daten kurz stoppt?

Auf den ersten Blick erschließt sich mir nicht, wieso dvb_play_* warten muß, bis Platz im *audio*-Ringbuffer ist. Müßte ich mir jedoch noch mal genauer anschauen.

<edit>
Ah ja, liegt daran, daß dvb_play im allgemeinen sowohl in den Video- als auch den Audio-Ringbuffer schreiben kann...
</edit>

CU
Oliver

Zitat

Original von Frodo
Ich habe ein Problem beim selektieren von Dolby Digital (2.0 oder 5.1) bei verschlüsselten Kanälen (ORF, Premiere). Diese haben erst nach nochmaligem anwählen des gleichen Senders in der "Kanäle"-Liste Ton.
Bei einem Neustart des VDRs ist der Ton auch sofort da, nur nach erneutem umschalten ist die Prozedur mit der Kanalliste zu wiederholen.
Die Aufnahmen sind hiervon nicht betroffen.

Bei FreeTV Kanälen (Das Erste, ZDF, SAT1, Pro7) tritt das Problem nicht auf.

Dies tritt nicht auf mit der Firmware 261f aber bei allen? nachfolgenden, leider kann ich aufgrund der nicht immervorhandenen Versionierung keine Unterschiede bei den Zwischenversionen von 00261f bis ff2621 erkennen.

In einem älteren Thread wurde der beschriebene Bug schonmal erwähnt, ich habe das Posting aber leider nicht mehr gefunden

Leider weiß ich nicht ob das Problem wirklich durch die Firmware verursacht wird oder im CAM Handling des VDRs zu suchen ist.

Ach ja die Ausgabe des VDRs zeigt bei buffer stats: 122388 (5%) used an und wechselt nach kurzer Zeit auf 0 (0%), dem nochmaligen Auswählen des Senders über "Kanäle" bekomme ich direkt buffer stats: 2068 (0%) used also 0% Buffer.

Getestet habe ich es aktuell mit VDR 1.3.40 .

Alles anzeigen

Das war ein Problem in VDR 1.3.37 (konnte ich auch nachvollziehen).
Sollte aber seit 1.3.38 behoben sein.

Klaus

Zitat

Original von UFO
Kannst Du vor dem wait_event_interruptible mal die Werte dvb_ringbuffer_free(&av7110->avout) und dvb_ringbuffer_free(&av7110->aout) ausgeben lassen?

das könnte bei mir ein paar Tage dauern - ich müsste auch erstmal wieder alles so einrichten, dass die Bildchen kommen, im Moment habe ich andere Prioritäten. Stefan?

Zitat

Ah ja, liegt daran, daß dvb_play im allgemeinen sowohl in den Video- als auch den Audio-Ringbuffer schreiben kann...

oder brauchst Du das deshalb nun doch nicht?

Zitat

Original von wolfgang61

das könnte bei mir ein paar Tage dauern - ich müsste auch erstmal wieder alles so einrichten, dass die Bildchen kommen, im Moment habe ich andere Prioritäten. Stefan?

oder brauchst Du das deshalb nun doch nicht?

Alles anzeigen

Doch. Ich ändere nichts am Treiber, bevor nicht klar ist, worin das Problem genau besteht...

Der Bug ist schon so lange drin, daß es auf ein paar Tage auch nicht mehr ankommen sollte...

CU
Oliver

ich habe noch immer das Problem, das bei Aufruf von femon (mit aktivierter Streamanalyse) auf einem beliebigen DD-Sender der Ton verstummt und erst nach einem Kanalwechsel wieder zurückkommt.

Das hat m.E. nichts mit dem Problem bei verschlüsselten AC3-Sendern zu tun.

Hat das eigentlich auch noch wer auf der ToDo-Liste stehen?

Zitat

Original von UFO
Doch. Ich ändere nichts am Treiber, bevor nicht klar ist, worin das Problem genau besteht...

Der Bug ist schon so lange drin, daß es auf ein paar Tage auch nicht mehr ankommen sollte...

Ich habe ein kleines Test-Prog geschrieben, mit dem ich das Problem bei mir in 10 von 10 Fällen reproduzieren kann.
http://www.muempf.de/down/stilltest.c.gz
Wenn man den Kommentar vor dem usleep() rausnimmt, dann läuft es durch.

Ich hoffe das hilft weiter.

Gruß
Stefan

Zitat

Original von stefan.h
Ich habe ein kleines Test-Prog geschrieben, mit dem ich das Problem bei mir in 10 von 10 Fällen reproduzieren kann.
http://www.muempf.de/down/stilltest.c.gz
Wenn man den Kommentar vor dem usleep() rausnimmt, dann läuft es durch.

Ich hoffe das hilft weiter.

Müßte man mit diesem Programm etwas sehen bzw. hören können, oder ist der einzige erkennbare Effekt der Hänger? Lezterer ist damit reproduzierbar.

CU
Oliver

Zitat

Original von UFO
Müßte man mit diesem Programm etwas sehen bzw. hören können, oder ist der einzige erkennbare Effekt der Hänger? Lezterer ist damit reproduzierbar.

Die Audio-Daten bestehen nur aus Nullen, da ist nix zu hören
Was genau das StillPicture anzeigen würde, kann ich gerade nicht sagen. Ich habe die Daten einfach woanders rauskopiert.
[edit]
Ich denke das Bild ist einfach nur ein schwarzer Hintergrund.
[/edit]

Gruß
Stefan

Zitat

Original von stefan.h

Die Audio-Daten bestehen nur aus Nullen, da ist nix zu hören
Was genau das StillPicture anzeigen würde, kann ich gerade nicht sagen. Ich habe die Daten einfach woanders rauskopiert.
[edit]
Ich denke das Bild ist einfach nur ein schwarzer Hintergrund.
[/edit]

Alles anzeigen

Ok, der angehängte Patch sollte den Bug beheben. War kein Firmwareproblem.

CU
Oliver