Neue Testversion F22623 für AV7110 firmware

bitstreamout · 15. Mai 2006

Zitat

Original von Der_Pit
Hi,

ich hab gestern auch auf die neue FW umgestellt (System s.u.), und hatte abends während einer Aufnahme von Pro 7 zwei crashes:

Zufall (lief mit der alten Version FA2623 eigentlich immer brav) oder gibt's nen Zusammenhang?

Hmmm ... also LiveTV mit Dolby Digital und der DolbyRepacker laufen nicht gleichzeitig.
Ob der besser Workaround gegen Absturz bei HDTV oder der WSS Support etwas
für diesen Fall geändert hat, wage ich zu bezweifeln.

Werner

woprr · 15. Mai 2006

bitstreamout

hallo herr dr. fink,

mit keiner der ac-3 firmwares wird bei mir ac3dec vom vdr für live-tv gestartet, die letzte
fw mit der das hier passiert ist 261f.

falls das kein bug ist, bin ich hier auf dem holzweg? :

AC-3 DD live TV über 5.1 Soundkarte mit ac3dec (NICHT für SPDIF zu externen Receivern -> gr. howto)

mfg,
woppr

bitstreamout · 15. Mai 2006

Zitat

Original von woppr
mit keiner der ac-3 firmwares wird bei mir ac3dec vom vdr für live-tv gestartet, die letzte
fw mit der das hier passiert ist 261f.

falls das kein bug ist, bin ich hier auf dem holzweg? :

AC-3 DD live TV über 5.1 Soundkarte mit ac3dec (NICHT für SPDIF zu externen Receivern -> gr. howto)

Hmmm ... also es geht mit dieser firmware nur um S/P-DIF -> AV-Receiver.
Bei Dolby Digital über bitstreamout oder ac3dec sollte kein Dolby Digital
bei LiveTV nicht über den S/P-DIF der DVB-Karte laufen. Das bitstreamout
plugin verwendet dafür das Interface

Code

cDvbDevice::SetTransferModeForDolbyDigital(false);

des VDRs, damit wird vom VDR kein Dolby Digital bei LiveTV auf der DVB-Karte
verwendet, noch ein Transfermode gestartet. Grund ist einfach, dass die
DVB-Karten im LiveTV Mode mit Dolby Digital, den Ton intern verarbeiten
und damit kann dieser nicht gleichzeitig noch vom VDR für eine
Aufnahme, Transfer, ac3dec oder bitstreamout verwendet werden.

Werner

zaubi4u · 15. Mai 2006

Hallo Friedjof,

würde dass ja gerne mal an meinem vdr ausprobieren, aber dafür fehlen mir echt die ausreichenden Linuxkenntnisse....

schade...

Gruß Micha

zaubi4u · 15. Mai 2006

Leider habe ich auch gaanz böse effekte bei Aufnahmen von ZDF oder 3SAT (fährt jetzt mit ähnlichen Datenraten wie ZDF und 3 Audiospuren...) Hab 3 SAT aufgenommen und sowohl bei 3SAT als auch ZDF stand das Bild live!!!! So extrem hatte ich das vorher nicht..... Da die Aufnahme auch Tonaussetzer hat, ist die Firmware für mich nicht wirklich praxistauglich...

Lässt sich denn da ne Mischung zwischen der ( mit guten live TV DD) und der vorhergehenden (mit guten Aufnahmen von Sendern mit hohen Datenraten) entwickeln?
Ich persönlich denke auch, dass der ARM nicht schnell genug bedient wird, um die Daten abzuholen, kleinere Pakete sind da sicher genau das richtige Rezept....

hier mal das Logread:

Code

May 15 23:25:09 Micha_vdr user.info noad[3006]: noad args done
May 15 23:25:09 Micha_vdr user.info noad[3007]: wait 60 secs for vdr creating directory
May 15 23:25:09 Micha_vdr user.info noad[3006]: noad forked to pid 3007
May 15 23:25:09 Micha_vdr user.info vdr: [2946] record /video0/@Mirabella#2FSindelfingen/2006-05-15.23.25.80.90.rec
May 15 23:25:09 Micha_vdr user.debug vdr: [2946] creating directory /video0/@Mirabella#2FSindelfingen
May 15 23:25:09 Micha_vdr user.debug vdr: [2946] creating directory /video0/@Mirabella#2FSindelfingen/2006-05-15.23.25.80.90.rec
May 15 23:25:09 Micha_vdr user.debug vdr: [2946] recording to '/video0/@Mirabella#2FSindelfingen/2006-05-15.23.25.80.90.rec/001.vdr'
May 15 23:25:09 Micha_vdr user.debug vdr: [2946] creating directory /video1/@Mirabella#2FSindelfingen
May 15 23:25:09 Micha_vdr user.debug vdr: [2946] creating directory /video1/@Mirabella#2FSindelfingen/2006-05-15.23.25.80.90.rec
May 15 23:25:09 Micha_vdr user.debug vdr: [3008] file writer thread started (pid=3008, tid=3008)
May 15 23:25:09 Micha_vdr user.debug vdr: [3009] recording thread started (pid=3009, tid=3009)
May 15 23:25:09 Micha_vdr user.info vdr: [2946] info: Aufzeichnung gestartet
May 15 23:25:14 Micha_vdr user.debug vdr: [2946] max. latency time 5 seconds
May 15 23:25:29 Micha_vdr user.debug vdr: [2990] buffer usage: 70% (tid=2989)
May 15 23:25:29 Micha_vdr user.debug vdr: [2990] buffer usage: 60% (tid=2989)
May 15 23:25:29 Micha_vdr user.debug vdr: [2990] buffer usage: 70% (tid=2989)
May 15 23:25:29 Micha_vdr user.debug vdr: [2990] buffer usage: 60% (tid=2989)
May 15 23:25:29 Micha_vdr user.debug vdr: [2990] buffer usage: 70% (tid=2989)
May 15 23:25:29 Micha_vdr user.debug vdr: [2990] buffer usage: 60% (tid=2989)
May 15 23:25:29 Micha_vdr user.debug vdr: [2990] buffer usage: 70% (tid=2989)
May 15 23:25:29 Micha_vdr user.debug vdr: [2990] buffer usage: 60% (tid=2989)
May 15 23:25:29 Micha_vdr user.debug vdr: [2990] buffer usage: 70% (tid=2989)
May 15 23:25:32 Micha_vdr user.debug vdr: [2990] buffer usage: 80% (tid=2989)
May 15 23:25:33 Micha_vdr user.info vdr: [2946] switching to channel 2
May 15 23:25:33 Micha_vdr user.err vdr: [2989] ERROR: attempt to use cPlayer::PlayPes() without attaching to a cDevice!
May 15 23:25:33 Micha_vdr user.debug vdr: [2989] transfer thread ended (pid=2989, tid=2989)
May 15 23:25:33 Micha_vdr user.debug vdr: [2946] buffer stats: 1777916 (84%) used
May 15 23:25:33 Micha_vdr user.debug vdr: [3012] transfer thread started (pid=3012, tid=3012)
May 15 23:25:33 Micha_vdr user.debug vdr: [2946] buffer stats: 0 (0%) used
May 15 23:25:33 Micha_vdr user.debug vdr: [2946] creating directory /vtx/S19.2E-1-1079-28006
May 15 23:25:33 Micha_vdr user.debug vdr: [2946] max. latency time 9 seconds
May 15 23:25:37 Micha_vdr user.debug vdr: [2990] buffer usage: 70% (tid=3012)
May 15 23:25:38 Micha_vdr user.debug vdr: [2990] buffer usage: 80% (tid=3012)
May 15 23:25:38 Micha_vdr user.debug vdr: [2990] buffer usage: 90% (tid=3012)
May 15 23:25:38 Micha_vdr user.debug vdr: [3012] clearing transfer buffer to avoid overflows
May 15 23:25:38 Micha_vdr user.debug vdr: [2990] buffer usage: 0% (tid=3012)
May 15 23:25:41 Micha_vdr user.debug vdr: [2990] buffer usage: 70% (tid=3012)
May 15 23:25:42 Micha_vdr user.debug vdr: [2990] buffer usage: 80% (tid=3012)
May 15 23:25:42 Micha_vdr user.debug vdr: [2990] buffer usage: 90% (tid=3012)
May 15 23:25:42 Micha_vdr user.debug vdr: [3012] clearing transfer buffer to avoid overflows
May 15 23:25:42 Micha_vdr user.debug vdr: [2990] buffer usage: 0% (tid=3012)
May 15 23:25:45 Micha_vdr user.debug vdr: [2990] buffer usage: 70% (tid=3012)
May 15 23:25:45 Micha_vdr user.debug vdr: [2990] buffer usage: 80% (tid=3012)
May 15 23:25:46 Micha_vdr user.debug vdr: [2990] buffer usage: 90% (tid=3012)
May 15 23:25:46 Micha_vdr user.debug vdr: [3012] clearing transfer buffer to avoid overflows
May 15 23:25:46 Micha_vdr user.debug vdr: [2990] buffer usage: 0% (tid=3012)
May 15 23:25:46 Micha_vdr user.err vdr: [3009] cAudioRepacker(0xC0): skipped 588 bytes to sync on next audio frame
May 15 23:26:05 Micha_vdr user.debug vdr: [3009] PES packet shortened to 5210 bytes (expected: 5390 bytes)
May 15 23:26:05 Micha_vdr user.err vdr: [3012] cAudioRepacker(0xC0): skipped 588 bytes to sync on next audio frame
May 15 23:26:05 Micha_vdr user.debug vdr: [3009] PES packet shortened to 7510 bytes (expected: 7694 bytes)
May 15 23:26:05 Micha_vdr user.err vdr: [3012] cAudioRepacker(0xC1): skipped 204 bytes to sync on next audio frame
May 15 23:26:05 Micha_vdr user.debug vdr: [3012] PES packet shortened to 2138 bytes (expected: 2318 bytes)
May 15 23:26:05 Micha_vdr user.debug vdr: [3012] PES packet shortened to 5210 bytes (expected: 5390 bytes)
May 15 23:26:09 Micha_vdr user.debug vdr: [2990] buffer usage: 70% (tid=3012)
May 15 23:26:09 Micha_vdr user.err noad[3007]: nice ERROR(19,0): Bad file descriptor
May 15 23:26:09 Micha_vdr user.info noad[3007]: Monday,15.05.2006 23:26:09 start noad-0.6.0 online for /video0/@Mirabella#2FSindelfingen/20$
May 15 23:26:09 Micha_vdr user.debug vdr: [2990] buffer usage: 80% (tid=3012)
May 15 23:26:10 Micha_vdr user.debug vdr: [2990] buffer usage: 90% (tid=3012)
May 15 23:26:10 Micha_vdr user.debug vdr: [3012] clearing transfer buffer to avoid overflows
May 15 23:26:10 Micha_vdr user.debug vdr: [2990] buffer usage: 0% (tid=3012)
May 15 23:26:10 Micha_vdr user.debug vdr: [3009] PES packet shortened to 7142 bytes (expected: 7694 bytes)
May 15 23:26:10 Micha_vdr user.debug vdr: [3009] PES packet shortened to 2138 bytes (expected: 2318 bytes)
May 15 23:26:10 Micha_vdr user.err vdr: [3009] 1 cRepacker messages suppressed
May 15 23:26:10 Micha_vdr user.err vdr: [3009] cAudioRepacker(0xC1): skipped 200 bytes while syncing on next audio frame
May 15 23:26:10 Micha_vdr user.debug vdr: [3009] PES packet shortened to 5210 bytes (expected: 5390 bytes)
May 15 23:26:10 Micha_vdr user.debug vdr: [3012] PES packet shortened to 5030 bytes (expected: 5390 bytes)
May 15 23:26:13 Micha_vdr user.debug vdr: [2990] buffer usage: 70% (tid=3012)
May 15 23:26:13 Micha_vdr user.debug vdr: [2990] buffer usage: 60% (tid=3012)
May 15 23:26:13 Micha_vdr user.debug vdr: [2990] buffer usage: 70% (tid=3012)
May 15 23:26:13 Micha_vdr user.debug vdr: [2990] buffer usage: 60% (tid=3012)
May 15 23:26:13 Micha_vdr user.debug vdr: [2990] buffer usage: 70% (tid=3012)
May 15 23:26:13 Micha_vdr user.debug vdr: [2990] buffer usage: 60% (tid=3012)
May 15 23:26:13 Micha_vdr user.debug vdr: [2990] buffer usage: 70% (tid=3012)
May 15 23:26:13 Micha_vdr user.debug vdr: [2990] buffer usage: 80% (tid=3012)
May 15 23:26:13 Micha_vdr user.debug vdr: [2990] buffer usage: 90% (tid=3012)
May 15 23:26:13 Micha_vdr user.debug vdr: [3012] clearing transfer buffer to avoid overflows
May 15 23:26:13 Micha_vdr user.debug vdr: [2990] buffer usage: 0% (tid=3012)
May 15 23:26:13 Micha_vdr user.debug vdr: [3009] PES packet shortened to 5030 bytes (expected: 5390 bytes)
May 15 23:26:13 Micha_vdr user.debug vdr: [3009] PES packet shortened to 2138 bytes (expected: 2318 bytes)
May 15 23:26:14 Micha_vdr user.debug vdr: [3009] PES packet shortened to 7326 bytes (expected: 7694 bytes)
May 15 23:26:16 Micha_vdr user.debug vdr: [2990] buffer usage: 70% (tid=3012)
May 15 23:26:16 Micha_vdr user.debug vdr: [2990] buffer usage: 60% (tid=3012)
May 15 23:26:16 Micha_vdr user.debug vdr: [2990] buffer usage: 70% (tid=3012)
May 15 23:26:16 Micha_vdr user.debug vdr: [2990] buffer usage: 60% (tid=3012)
May 15 23:26:16 Micha_vdr user.debug vdr: [2990] buffer usage: 70% (tid=3012)
May 15 23:26:16 Micha_vdr user.debug vdr: [2990] buffer usage: 80% (tid=3012)
May 15 23:26:17 Micha_vdr user.debug vdr: [2990] buffer usage: 90% (tid=3012)
May 15 23:26:17 Micha_vdr user.debug vdr: [3012] clearing transfer buffer to avoid overflows
May 15 23:26:17 Micha_vdr user.debug vdr: [2990] buffer usage: 0% (tid=3012)
May 15 23:26:20 Micha_vdr auth.info sshd[3014]: Accepted password for root from 192.168.1.200 port 2025 ssh2
May 15 23:26:20 Micha_vdr auth.info sshd[3014]: lastlog_get_entry: Error reading from /var/log/lastlog: Bad file descriptor

Alles anzeigen

Gruß Micha

woprr · 16. Mai 2006

das hatte ich heut abend auch bei der aufnahme von 4400 auf proll7.

mit fw 261f und ac3dec.

liegt also eher am treiber oder vdr

kilroy · 16. Mai 2006

Zitat

Original von woppr
das hatte ich heut abend auch bei der aufnahme von 4400 auf proll7.

Das kann ich bestätigen. Diese "Störungen" sind auch wahrnehmbar.

Code

zaphod:~$ grep "Repacker\|shortened" /var/log/syslog.0
May 15 20:19:52 zaphod vdr: [25662] cDolbyRepacker: skipped 1608 bytes to sync on next AC3 frame
May 15 20:19:52 zaphod vdr: [25662] PES packet shortened to 8790 bytes (expected: 8974 bytes)
May 15 20:20:00 zaphod vdr: [25662] PES packet shortened to 8790 bytes (expected: 8974 bytes)
May 15 20:32:43 zaphod vdr: [25662] PES packet shortened to 8790 bytes (expected: 8974 bytes)
May 15 20:32:43 zaphod vdr: [25662] 2 cRepacker messages suppressed
May 15 20:32:43 zaphod vdr: [25662] cDolbyRepacker: skipped 1608 bytes to sync on next AC3 frame
May 15 20:38:48 zaphod vdr: [25662] cVideoRepacker: found system start code: stream seems to be scrambled or not demultiplexed
May 15 20:40:32 zaphod vdr: [25662] PES packet shortened to 8790 bytes (expected: 8974 bytes)
May 15 20:40:32 zaphod vdr: [25662] cDolbyRepacker: skipped 1608 bytes to sync on next AC3 frame
May 15 20:42:23 zaphod vdr: [25662] cDolbyRepacker: skipped 1608 bytes to sync on next AC3 frame
May 15 20:42:23 zaphod vdr: [25662] PES packet shortened to 8790 bytes (expected: 8974 bytes)
May 15 20:54:59 zaphod vdr: [25662] PES packet shortened to 3286 bytes (expected: 3470 bytes)
May 15 20:54:59 zaphod vdr: [25662] cAudioRepacker(0xC0): skipped 388 bytes while syncing on next audio frame
May 15 20:59:31 zaphod vdr: [25662] PES packet shortened to 8606 bytes (expected: 8974 bytes)
May 15 20:59:31 zaphod vdr: [25662] cDolbyRepacker: skipped 1424 bytes to sync on next AC3 frame
May 15 21:16:53 zaphod vdr: [25662] PES packet shortened to 8832 bytes (expected: 8974 bytes)
May 15 21:16:53 zaphod vdr: [25662] cDolbyRepacker: skipped 1650 bytes to sync on next AC3 frame
May 15 21:16:53 zaphod vdr: [25662] PES packet shortened to 3286 bytes (expected: 3470 bytes)
May 15 21:16:53 zaphod vdr: [25662] 1 cRepacker messages suppressed
May 15 21:16:53 zaphod vdr: [25662] cAudioRepacker(0xC0): skipped 388 bytes while syncing on next audio frame
May 15 21:30:45 zaphod vdr: [25662] PES packet shortened to 8790 bytes (expected: 8974 bytes)
May 15 21:30:45 zaphod vdr: [25662] cDolbyRepacker: skipped 1604 bytes while syncing on next AC3 frame
May 15 21:30:45 zaphod vdr: [25717] PES packet shortened to 8790 bytes (expected: 8974 bytes)
May 15 21:30:45 zaphod vdr: [25717] cDolbyRepacker: skipped 1604 bytes while syncing on next AC3 frame
May 15 21:49:29 zaphod vdr: [25662] PES packet shortened to 3286 bytes (expected: 3470 bytes)
May 15 21:49:29 zaphod vdr: [25662] 1 cRepacker messages suppressed
May 15 21:49:29 zaphod vdr: [25662] cAudioRepacker(0xC0): skipped 392 bytes to sync on next audio frame
May 15 21:49:29 zaphod vdr: [25717] PES packet shortened to 3286 bytes (expected: 3470 bytes)
May 15 21:49:29 zaphod vdr: [25717] cAudioRepacker(0xC0): skipped 392 bytes to sync on next audio frame
May 15 22:03:42 zaphod vdr: [25662] PES packet shortened to 8790 bytes (expected: 8974 bytes)
May 15 22:03:42 zaphod vdr: [25662] 1 cRepacker messages suppressed
May 15 22:03:42 zaphod vdr: [25662] cDolbyRepacker: skipped 1604 bytes while syncing on next AC3 frame
May 15 22:27:02 zaphod vdr: [25762] PES packet shortened to 368 bytes (expected: 552 bytes)
May 15 22:27:02 zaphod vdr: [25762] PES packet shortened to 1472 bytes (expected: 1840 bytes)
May 15 22:27:02 zaphod vdr: [25762] cAudioRepacker(0xC0): skipped 284 bytes while syncing on next audio frame
May 15 22:27:02 zaphod vdr: [25762] cDolbyRepacker: skipped 1380 bytes while syncing on next AC3 frame

Alles anzeigen

Der_Pit · 16. Mai 2006

Hmm, also ich hatte mit der neuen FW jetzt schon zweimal 'nen Crash beim Wechel auf Kanäle mit schlechter Signalstärke (bei mir TW1 und GoTV):

Code

May 16 00:12:17 vdr  vdr: [3876] ERROR: can't open XPM file '/etc/vdr/plugins/skinelchi/logos/TW1.xpm'
May 16 00:12:17 vdr  vdr: [3876] switching to channel 32
May 16 00:12:20 vdr  vdr: [3876] switching to channel 33
May 16 00:12:21 vdr  vdr: [3876] ERROR (dvbdevice.c,696): Connection timed out
May 16 00:12:21 vdr  kernel: dvb-ttpci: __av7110_send_fw_cmd(): timeout waiting for COMMAND idle
May 16 00:12:21 vdr  kernel: dvb-ttpci: av7110_send_fw_cmd(): av7110_send_fw_cmd error -110
May 16 00:12:21 vdr  kernel: dvb-ttpci: av7110_fw_cmd error -110

Das Problem war früher schonmal da, aber mit einer der vorigen FW-Versionen behoben(?) - ist jedenfalls das erste Mal seit längerem daß er mir so abschmiert.
Bin vorläufig wieder zurück bei der FA2623...

Pit

bitstreamout · 16. Mai 2006

Zitat

Original von Der_Pit
Hmm, also ich hatte mit der neuen FW jetzt schon zweimal 'nen Crash beim Wechel auf Kanäle mit schlechter Signalstärke (bei mir TW1 und GoTV):
[...]
Das Problem war früher schonmal da, aber mit einer der vorigen FW-Versionen behoben(?) - ist jedenfalls das erste Mal seit längerem daß er mir so abschmiert.
Bin vorläufig wieder zurück bei der FA2623...

Damit kommen wir nicht weiter
Wie wäre es, wenn Du mal die firmware nach FA2623 durchprobierts, d.h.
F62623, F42623 und F32623. Ab welcher Version tritt das Problem auf?
IMHO sind die gemachten Änderungen im Dolby Digital Bereich nicht
für crashes bei TW1 und GoTV verantwortlich, die werden bei diesen
Sendern noch nicht mal benutzt. Allerdings wurde mit F62623 der
error handler der DVB-Hardware umgestellt.

Werner

mdatab · 16. Mai 2006

Öhm, diese Versionen verwirren mich etwas. Kann mir mal jemand einen Überblick (oder Link) geben welche Version stabil/alpha/beta/neuer/älter/empfohlen ist?

Der_Pit · 16. Mai 2006

Zitat

Original von bitstreamout
Damit kommen wir nicht weiter

Sorry
Ich hab halt Null Ahnung und installiere es, sehe ob's geht oder nicht, ohne zu wissen ob da ein Zusammenhang möglich ist oder nicht ....

Zitat

Wie wäre es, wenn Du mal die firmware nach FA2623 durchprobierts, d.h.
F62623, F42623 und F32623. Ab welcher Version tritt das Problem auf?

OK, ich hab mir mal alle Versionen geholt, kann aber im Moment keine Crashes produzieren (Murphy?). Ich behalte die Sache aber im Auge und gebe laut sobald ich mehr Neuigkeiten hab.

Aber wenn ich echt der einzige mit solchen Problemen bin war's vielleicht wirklich nur Zufall daß es gerade nach dem FW-Wechsel aufgetreten ist.

Pit

PS: Und auf jeden Fall Danke für Deine Arbeit und die Verbesserungen an der FW!

habichthugo · 16. Mai 2006

Hat eigentlich mit dieser Firmware noch einer das Problem, dass das Live-Bild nach dem Abspielen einer Aufnahme manchmal nicht wieder kommt, sprich das Bild schwarz bleibt? Das passiert bei mir grob geschätzt so jedes vierte mal. Dann hilft nur ein kompletter Reboot des VDR, um wieder live gucken zu können. Mit den Vorgängerversionen war das bei mir auch schon so bzw. seit Umstieg auf c't-vdr 4.5 vor ca. drei Monaten, wobei ich da sofort auch die neuste Testfirmware draufgebügelt habe. Vielleicht liegt's ja gar nicht an der Firmware...?

Hier mal die mir scheinbar damit im Zussammenhang stehende Stelle aus dem syslog:

Code

May 16 17:30:02 vdr2 vdr[19566]: clearing device because of consecutive poll timeouts
May 16 17:30:02 vdr2 kernel: av7110_fw_request: timeout waiting for COMMAND to complete
May 16 17:30:02 vdr2 kernel: dvb-ttpci: StartHWFilter error  buf 0b07 0010 0012 b96a  ret -110  handle 0000
May 16 17:30:03 vdr2 vdr[4429]: ERROR (dvbdevice.c,213): Connection timed out
May 16 17:30:03 vdr2 kernel: dvb-ttpci: __av7110_send_fw_cmd(): timeout waiting for COMMAND idle
May 16 17:30:03 vdr2 kernel: dvb-ttpci: av7110_send_fw_cmd(): av7110_send_fw_cmd error -110
May 16 17:30:03 vdr2 kernel: dvb-ttpci: av7110_fw_cmd error -110

Das Ganze passiert während des Abspielens, vielleicht irgendwie noch im Zusammenhang mit einer hier parallel endenden Aufnahme, noad...? Die komplette syslog ab Begin des Abspielens (Live-Bild war noch da) häng ich mal mit an. Etwas zu länglich für nen Code-Tag...

Wenn mir irgend jemand nen Anhaltspunkt liefern könnte, was da los ist, wäre ich sehr dankbar!

CKone · 16. Mai 2006

Ich hab mit der F22623 und Treiber vom 01.05. keine dieser Crash Probleme. Einziges Manko ist, dass bei Wiedergabe von DD Sendungen manchmal so ein Zeitlupen bzw. Breakdance Effekt eintritt. Dieser lässt sich aber durch einfaches Stoppen und Neustarten der Wiedergabe abstellen. Insgesamt ist dieser Stolper Effekt aber im Vergleich zu FW F62623 und Treiber 01.04. wesentlich geringer geworden.

Christian

Der_Pit · 16. Mai 2006

habichthugo

Das ist zumindest dieselbe Fehlermeldung die ich beim Schalten auf schlechte Kanäle bekomme. Vielleicht werden da beim Beenden der Wiedergabe irgendwelche 'unverträglichen' Dinge an die Karte gegeben?

Pit

habichthugo · 16. Mai 2006

Der_Pit
Hm, das passiert bei mir aber so ziemlich mit jedem wiedergegebenen Material, aber halt nicht immer, nur so jedes dritte, vierte Mal, manchmal Tage lang nicht, dann wieder praktisch immer. Beim umschalten habe ich das nur gaaaaaanz selten, wobei ich hier Null Probleme mit der Empfangsqualität habe.

bitstreamout · 17. Mai 2006

Zitat

Original von CKone
Ich hab mit der F22623 und Treiber vom 01.05. keine dieser Crash Probleme. Einziges Manko ist, dass bei Wiedergabe von DD Sendungen manchmal so ein Zeitlupen bzw. Breakdance Effekt eintritt. Dieser lässt sich aber durch einfaches Stoppen und Neustarten der Wiedergabe abstellen. Insgesamt ist dieser Stolper Effekt aber im Vergleich zu FW F62623 und Treiber 01.04. wesentlich geringer geworden.

Welche Treiberversion benutzt Du und hast Du UDMA für Deine Platten aktiv
geschaltet? Wenn die Daten nicht schnell genug bei der DVB-Karte ankommen,
sind underruns auf der DVB-Karte möglich und genau dann wird neu synchronisiert.
Da kann es zu Verlangsamung oder Beschleunigung von Bildsequenzen kommen.
Bei einem Stoppen bzw. Neustart werden die Daten dann aus dem Cache statt
direkt von der Platte geladen.

Werner

viking · 17. Mai 2006

Hallo Werner,

echt gut die neue version :], kann es sein das die synchronität viel besser ist als vorher ? (Hatte vorher die f62623 in betrieb.)

Auf jeden fall habe ich seit 8 tagen keine asynchronität nach pause bei den nachrichten mehr gehabt (hoffentlioch bleibt es auch so)

@alle
ich habe bei mir den eindruck das wenn ich so zu sagen im laufenden betrieb die version ändere = neue vdr version oder treiber aktivieren (also VDR neustart) das dann VDR/DVB treiber nicht immer stabil läuft. Ich habe dann auch regelmässig fehler. Vieleicht liegt es ja auch daran das beim kompilieren o.ä. die last hochgeht und das system aus der bahn wirft ... Wenn ich aber ein frisch gestartetes system habe dann läuft es auch 5 tage durch ohne probleme Woran das liegt kann ich nicht sagen aber ihr könnt ja mal beobachten ob es ähnlich bei euch ist.

habichthugo
Also mein system läuft mittlerweile sehr gut. Wenn ich die obige regel beachte dann habe ich nur absolut selten probleme. Nach der wiedergabe kommt das bild immer zurück - dauert manschmal 2-5 sekunden aber es kommt immer zurück. Vieleicht mal einen neueren DVB treiber probieren. Also meine läuft ziemlich stabil seit Februar (siehe signatur).

Was aber ganz wichtig ist in zusammenhang mit dein WSS detect !!! wenn vdr abschmiert und neu startet + den treiber neu laden will dann muß man unbedingt vorher WSS stoppen !!
Also vor dem entladen vom DVB treiber ein :
killall dvb-wss-overdrive dvb-aspect
sleep 10

Und dann auch warten bis WSS gestoppt ist !! (habe eine testschleife, killt WSS und wartet bis es weg ist, kann das script im WSS thread posten wenn gewüscht) sonst geht es ziemlich schief, dann läuft VDR echt nicht mehr gut ... Der DVB treiber wird dann nähmlich nicht entladen, oder es werden nur einige module entladen, habe das nicht so genau analysiert

Vieleicht hilft das ja weiter

Gruß
Viking

CKone · 17. Mai 2006

Zitat

Original von bitstreamout

Welche Treiberversion benutzt Du und hast Du UDMA für Deine Platten aktiv
geschaltet? Wenn die Daten nicht schnell genug bei der DVB-Karte ankommen,
sind underruns auf der DVB-Karte möglich und genau dann wird neu synchronisiert.
Da kann es zu Verlangsamung oder Beschleunigung von Bildsequenzen kommen.

Treiber ist der vom 01.05 mit FW F22623, kann aber gerne nochmal updaten wenn du meinst. Hab nur eine SV1604N als Primary Master ohne Slave und die steht auf DMA Mode, ob UDMA weiß ich nicht. Tritt das Problem auf ist sowohl Festplattenaktivität als auch das Load nicht auffällig. Ganz im Gegenteil, ohne DD kannst du ohne Probleme auf 3 Karten 3 Kanäle aufnehmen und parallel ne Aufnahme schauen.

Hilft das bei der Erklärung? Fehler tritt wie gesagt nicht regelmäßig auf, nur von Zeit zu Zeit - dann aber immer im Zusammenhang mit DD. Könnte das auch ne Interrupt Geschichte sein?

Christian

bitstreamout · 17. Mai 2006

Zitat

Original von CKone
Treiber ist der vom 01.05 mit FW F22623, kann aber gerne nochmal updaten wenn du meinst. Hab nur eine SV1604N als Primary Master ohne Slave und die steht auf DMA Mode, ob UDMA weiß ich nicht. Tritt das Problem auf ist sowohl Festplattenaktivität als auch das Load nicht auffällig. Ganz im Gegenteil, ohne DD kannst du ohne Probleme auf 3 Karten 3 Kanäle aufnehmen und parallel ne Aufnahme schauen.

Hilft das bei der Erklärung? Fehler tritt wie gesagt nicht regelmäßig auf, nur von Zeit zu Zeit - dann aber immer im Zusammenhang mit DD. Könnte das auch ne Interrupt Geschichte sein?

Ich persöhnlich fahre die Platte mit UDMA2, unmasked IRQ, 32bit support on
und read-lookahead enabled. D.h. hdparm wird mit

Code

hdparm -q -d -q -X udma2 -q -c 1 -q -u 1 -q -A 1 /dev/hda

wobei udma2 nur wegen des chipsatz gewählt ist, denn die Platte selbst kann
mehr. Und da die Datenraten bei AC3 sehr gross sind und der Audiobuffer
der DVB-Karte etwa 35ms Spielzeit hat, im Gegensatz zu Mpeg-Audio mit 100ms,
kann eine kleine Verzögerung zu underruns führen. Zudem scheint derzeit der
DVB-Treiber bzw. der Kernel 2.6.16 ein Latenzproblem zu haben.

Werner

bitstreamout · 17. Mai 2006

Zitat

Original von woppr
mit keiner der ac-3 firmwares wird bei mir ac3dec vom vdr für live-tv gestartet, die letzte
fw mit der das hier passiert ist 261f.

falls das kein bug ist, bin ich hier auf dem holzweg? :

AC-3 DD live TV über 5.1 Soundkarte mit ac3dec (NICHT für SPDIF zu externen Receivern -> gr. howto)

Teste doch mal diese Änderung im VDR. In der Datei dvbdevice.c ind der
Funktion

Code

bool cDvbDevice::SetAudioBypass(bool On) {
  if (!setTransferModeForDolbyDigital)
     return false;
  return ioctl(fd_audio, AUDIO_SET_BYPASS_MODE, On) == 0;
}

Einfach mal als erste Zeile ein ``return false;'' einbauen:

Code

bool cDvbDevice::SetAudioBypass(bool On) {
  return false;
  if (!setTransferModeForDolbyDigital)
     return false;
  return ioctl(fd_audio, AUDIO_SET_BYPASS_MODE, On) == 0;
}

damit wird der DVB-karteninterne Transfermode nicht eingeschaltet
und es sollte bei AC3-Ton der Transfermode anspringen, um dann
die AC3-Daten zum externen ac3dec zu pipen

Werner

Neue Testversion F22623 für AV7110 firmware

Jetzt mitmachen!

Teilen