Neue Testversion F22623 für AV7110 firmware

Zu früh angekündigt, oder Downloadadresse falsch?

Zitat

Original von wilderigel
Zu früh angekündigt, oder Downloadadresse falsch?

bei mir hat funktioniert - wohl behoben ?

die neue firmware läuft spitzenmäßig, zwei mini-aussetzer im Ton den ganzen abend über bei DD.
SUPERARBEIT UND DANKE
Rainer

Ich schließe mich der Aussage von Rainer gerne an. DD scheint nun gut zu funktionieren. Im ersten Moment dachte ich, das OSD sei qualitativ ein bisschen schlechter als bisher, irgendwie ein Tick unscharf. Aber das kann auch Einbildung gewesen sein...

Vielen Dank jedenfalls und Grüße,
Martin

Hier auch wesentlich bessere Ergebnisse

Nur noch zweimal ein absolutes ministottern...

Christian

Danke für die neue Version, auch bei mirdeutlich besser, sehr schön! Werde die noch ein wenig weiter im laufenden Betreib testen, mal sehen, wie sich das auf den WAF auswirkt... bislang ist meine Frau jedenfalls sehr zufrieden!

Hallo Werner,

klasse arbeit, DD schaltet viel schneller

Gruß
Viking

Hallo. Ich nochmal

Also gestern Abend hab ich irgendwas aufgenommen (die Galapagos-Doku auf ZDFdoku wars glaub) und hab derweil eine Aufnahme angeschaut (Der Große Point Blank oder so). Als ich die Wiedergabe beendet hatte (es wurde noch die Doku aufgenommen) hatte ich das LiveBild von 3sat (soweit ok, hatte ich vorher wohl drin). Allerdings hatte ich dabei deutliche (!) Tonprobleme und Bildaussetzer. Das stottern lies sich auch nicht so einfach beruhigen durch umschalten auf normalen Stereoton. War die Aufnahme von ZDFdoku und das Liveschauen von 3sat zu viel für die Karte/Firmware? Meine Frau meinte, dass früher am Abend auf ARD oder ZDF auch ein Stottern zu vernehmen war. Da war ich aber gerade nicht zugegen...

Möglicherweise stammt dieser Logeintrag von dem Problem am früheren Abend:

May 11 17:59:09 voyager vdr: [7663] cDolbyRepacker: MPEG 2 PES header expected (dropped 880 bytes)

Diese hier dann von dem Problem bei der Aufnahme:

May 11 21:41:47 voyager vdr: [7960] cAudioRepacker(0xC0): skipped 408 bytes to sync on next audio frame
May 11 21:41:47 voyager vdr: [7975] cAudioRepacker(0xC1): skipped 204 bytes to sync on next audio frame
May 11 21:42:01 voyager dvb-ttpci: warning: timeout waiting in LoadBitmap: 0, 1
May 11 21:42:43 voyager vdr: [7960] cAudioRepacker(0xC0): skipped 48 bytes to sync on next audio frame
May 11 21:43:00 voyager vdr: [7960] cAudioRepacker(0xC0): skipped 48 bytes to sync on next audio frame
May 11 21:43:00 voyager dvb-ttpci: warning: timeout waiting in LoadBitmap: 0, 1
May 11 21:43:10 voyager dvb-ttpci: warning: timeout waiting in LoadBitmap: 0, 1
May 11 21:43:20 voyager dvb-ttpci: warning: timeout waiting in LoadBitmap: 0, 1
May 11 21:43:30 voyager dvb-ttpci: warning: timeout waiting in LoadBitmap: 0, 1
May 11 21:43:42 voyager dvb-ttpci: warning: timeout waiting in LoadBitmap: 0, 1
May 11 21:44:20 voyager dvb-ttpci: warning: timeout waiting in LoadBitmap: 0, 1
May 11 21:45:14 voyager dvb-ttpci: warning: timeout waiting in LoadBitmap: 0, 1
May 11 21:45:15 voyager vdr: [7960] 2 cRepacker messages suppressed
May 11 21:45:15 voyager vdr: [7960] cAudioRepacker(0xC0): skipped 48 bytes to sync on next audio frame

EDIT: Nur der Vollständigkeit halber: Ich hatte davor von VDR 1.3.45 auf 1.4.0 gewechselt.

Gruß,
Martin

Hallo Werner,

danke für die neue Firmware, bei mir läuft DD auch wesentlich besser seit dem, hab kaum noch Aussetzer!
Super Arbeit!

Gruß Micha

bitstreamout: Ja, ich dachte dass das Stottern mit der Datenrate zusammenhängt und dieses Problem mit der neuen Firmware behoben ist. Mein Fehler; hab wohl zwei Probleme in einen Topf geworfen.

Zitat

Original von bitstreamout
mdatab: Der Transponder für ZDF, 3sat und Co. haben seit einem halben Jahr sehr hohe
Datenraten, d.h. eine einzelne Aufnahme kann die ARM CPU überfordern

Werner

Und was macht man dann ? Muss man mit fehlerhaften Aufnahmen leben oder gibt's 'nen workaround ?

Den einzigen Work-Around den ich kenne ist eine zusätzliche Budget-Karte für ZDF-Transponder...

Habe bei mir eine 3. Karte eingebaut und das ZDF darauf gelegt in der Channels.conf.

Dann gehen normale Aufnahmen auf der 2. Karte und Live auf der 1. parallel zu ZDF. Wenn man gleichzeitig ein Live-Bild und eine Aufnahme auf dem ZDF hat, gibt es schon Ärger...

Ist nicht brilliant und die Umschaltzeiten von ARD zu ZDF zu Programm XY vergrößern sich wegen dem Kartenwechsel, aber dafür habe ich keine zerhackte Aufnahme mehr und das ist ja auch was... 40 € für ne TT-Budget bei der Bucht und 2 Min Konfigurieren lösten das Problem bei mir.,..

Hallo, hier mal was ich mit meiner SuSE 10 gemacht habe:

1. in der kernelkonfiguration:

General setup --->
(-Speed) Local version - append to kernel release
// der neue Kernel soll anders heißen, auch im boot menü

Processor type and features --->
Preemption Model (Preemptible Kernel (Low-Latency Desktop))
// der kernel soll unterbrechbar sein
Timer frequency (1000 HZ) --->
// die timer sollen schneller ticken

wenn es nicht so eingestellt ist, kernel neu bauen.

2. in /boot/grup/menu.lst den kernel parameter elevator=cfq angeben

// Hintergrund : wollen mehrere Prozesse also VDR,noad usw.
// gleichzeitig etwas von der Platte, solle die Zugriffe gleichmäßig
// den Prozessen zugeteilt werden. Dadurch kommen die Prozesse öfter
// dran, kriegen aber nur kleinere "Häppchen" abgenommen/geliefert
// merkt man deutlich beim Schneiden

mein Eintrag lautet:

title Linux-2.6.13-15.7-Speed
root (hd0,2)
kernel /boot/vmlinuz-2.6.13-15.7-Speed root=/dev/hda3 vga=0x317 elevator=cfq def-timeslice=30000 min-timeslice=5000 selinux=0 resume=/dev/hda2 splash=silent showopts
initrd /boot/initrd-2.6.13-15.7-Speed

//das mit der timeslice scheint den kernel aber nicht zu interessieren

3. Beim DVB Treiber (HG CVS vom 15.03.2006)
in /usr/src/linux/drivers/media/dvb/dvb-core/dmxdev.h oder wo immer
// er auch steht ändern
#define DVR_BUFFER_SIZE (100*188*1024) // war 10*188*1024
// ein bisschen mehr buffer, falls nicht rechtzeitig abgeholt wird

// treiber neu bauen
4. im VDR bei tools.c

#define WRITE_BUFFER MEGABYTE(1) // war 10
// der VDR soll in kürzeren Abständen aber weniger schreiben, in
// der Hoffnung, das der Schreibvorgang schneller geht

5. Im VDR bei den Einstelungen die maximale Dateigröße auf 100 MB gestellt
// benutze reiser fs, das ganze journaling dauert bei großen Dateien
// offenbar länger als bei kleinen.

Das ganze zielt darauf ab Betriebssystemaufrufe zwar häufiger zu machen,
diese aber möglichst kurz zu halten.

Bei der alten kernel 2.4 methode (ASSUME_KERNEL 2.4) waren bei hoher VDR Aktivität( mehrere Aufnahmen + schneiden + wiedergeben ) aus der Sicht des Betriebssystems (mit ps -a ) ja auch mehrere VDR Prozesse sichtbar( bis zu 10 Stück), die bei der Verteilung der Rechenzeit berücksichtig wurden.
Beim kernel 2.6 und VDR mit der pthread lib ist mit ps -a nur einer zu sehen.

Hier im Forum wurde oft gesagt der ARM sei das schwächste Glied in der Kette. Das mag auch so sein, aber dann sollte der ARM wenn er Daten an den DVBTreiber/VDR weitergeben will an dieser Stelle nicht auch noch unnötig warten müssen und schell seine Daten abgenommen bekommen.

Einfach mal eine Aufname auf ZDF starten, den DMA Modus des DVD Laufwerks abschalten und eine große Datei von der DVD auf die Platte kopieren und schon sind die repacker Meldungen wieder da.

Mit den obigen 5 Punkten nehme ich gerade ZDF auf und schaue eine Aufnahme von 3Sat auch live ZDF geht problemlos und OSD ist super flink.
(nur eine FF Karte im System, DD Ton auf EIN)

Die Aufnahme hat 190552739 byte für 300 sec macht 620 kByte/sec, also doch recht hoch.

Auch ZDF + 3Sat aufnehmen geht, wenn der VDR auf DLF radio steht.

Mit einer Suse 10.0 Standardinstallation ging das nicht.

Falls einer der gurus das liest und meint das sei alles zwar nicht schädlich aber auch nicht besonders hilfreich, bitte Kommentar abgeben.
Ich bin noch in der Lernphase.

Den linux kernel und die ARM software kenne ich eigentlich (gar)nicht so richtig, arbeite aber seit 16 Jahren mit parallelen verteilten Systemen auf der Basis der Sprache OCCAM, also echtes Multitasking ohne Betriebsystem. Beispiel zum schnuppern

PAR                      -- Startet parallel zwei WHILE Schleifen
  WHILE Recording
    --- do Recording
  WHILE Playing
    -- do Playing


  PAR i=0 FOR 4		-- Startet parallel zu den WHILE Schleifen noch 4 DVB Treiber
    DVBDriver(i)

Der Taskwechsel dauert 60ns, bei 600MHz CPU, Taskwechsel zwangsweise alle 2ms, bootet in 0,1s (Damit einen VDR bauen = Wahnsin)

Entschuligung für das Abschweifen vom Thema!

Also probiers mal mit den Punkten von oben.
Eine zusätzliche budget karte ist ebenfalls hilfreich. Wenn die einen eigenen Interrupt hat, sind die Videodaten auch schnell von der Karte in irgendeinem Puffer und dann kan nichts mehr passieren, die CPU langweilt sich eh nur.

Viele Grüsse Frithjof

Zitat

Original von 44892
Den einzigen Work-Around den ich kenne ist eine zusätzliche Budget-Karte für ZDF-Transponder...

Habe bei mir eine 3. Karte eingebaut und das ZDF darauf gelegt in der Channels.conf.

Wie geht das in der channels.conf?
Habe ähnliche Probleme
Gruss, Andi

Zitat

#define DVR_BUFFER_SIZE (100*188*1024) // war 10*188*1024
// ein bisschen mehr buffer, falls nicht rechtzeitig abgeholt wird

Du benutzt doch "diese firmware hier", die F22623, oder?
Hat die Bufferänderung auch bei vorherigen firmwares was gebracht?

Zitat

#define WRITE_BUFFER MEGABYTE(1) // war 10
// der VDR soll in kürzeren Abständen aber weniger schreiben, in
// der Hoffnung, das der Schreibvorgang schneller geht

Das ist im aktuellen vdr1.4 schon auf KILOBYTE(800). Da braucht man dann nichts mehr ändern. Hast du Klaus darauf aufmerksam gemacht?

Was hast du denn für einen Rechner [MHz]?

shh
ein 2.4 Celleron, und Firmware F32623

baue gerade einen neuen VDR mit suse 10.1 vdr 1.4 firmware F22623
das werden ich dann an meiner alten SONY 16:9 Röhre testen. Den VDR im Wohnzimmer fasse ich vorerst nicht an(bin verheiratet).

EDIT
die Idee mit dem write buffer habe ich per google in irgendeiner mailing liste auf englisch gefunden und fand es sinvoll, weis aber nicht mehr wo.

ende EDIT

@all
kommt man eigentlich irgendwie an die Quellen der Firmware? (nur so zum lesen und verstehen)

Viele Grüsse Frithjof

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:

May 14 22:17:22 vdr  vdr: [3312] PES packet shortened to 3286 bytes (expected: 3470 bytes)
May 14 22:17:22 vdr  vdr: [3312] cAudioRepacker(0xC0): skipped 388 bytes while syncing on next audio frame
May 14 22:17:22 vdr  vdr: [3312] PES packet shortened to 3102 bytes (expected: 3470 bytes)
May 14 22:17:23 vdr  vdr: [3312] cDolbyRepacker: skipped 1056 bytes to sync on next AC3 frame
May 14 22:17:23 vdr  vdr: [3312] PES packet shortened to 2918 bytes (expected: 3470 bytes)
May 14 22:17:23 vdr  vdr: [3312] PES packet shortened to 7502 bytes (expected: 8974 bytes)
May 14 22:18:04 vdr  vdr: [3312] PES packet shortened to 8790 bytes (expected: 8974 bytes)
May 14 22:18:04 vdr  vdr: [3312] 2 cRepacker messages suppressed
May 14 22:18:04 vdr  vdr: [3312] cDolbyRepacker: skipped 1604 bytes while syncing on next AC3 frame
May 14 22:18:04 vdr  vdr: [3312] PES packet shortened to 8606 bytes (expected: 8974 bytes)
May 14 22:18:04 vdr  vdr: [3312] 5 cRepacker messages suppressed
May 14 22:18:04 vdr  vdr: [3312] cAudioRepacker(0xC0): skipped 312 bytes while syncing on next audio frame
May 14 22:18:13 vdr  vdr: [3107] frontend 0 lost lock on channel 20, tp 212480
May 14 22:18:13 vdr  vdr: [3107] frontend 0 regained lock on channel 20, tp 212480
May 14 22:18:35 vdr  vdr: [3311] ERROR: video data stream broken
May 14 22:18:35 vdr  vdr: [3311] initiating emergency exit
.
.
.
May 14 22:21:04 vdr  vdr: [3610] cDolbyRepacker: skipped 1056 bytes to sync on next AC3 frame
May 14 22:21:05 vdr  vdr: [3610] PES packet shortened to 2918 bytes (expected: 3470 bytes)
May 14 22:21:05 vdr  vdr: [3610] cAudioRepacker(0xC0): skipped 784 bytes to sync on next audio frame
May 14 22:21:05 vdr  vdr: [3610] PES packet shortened to 3102 bytes (expected: 3470 bytes)
May 14 22:21:14 vdr  vdr: [3610] PES packet shortened to 7870 bytes (expected: 8974 bytes)
May 14 22:21:14 vdr  vdr: [3610] PES packet shortened to 2918 bytes (expected: 3470 bytes)
May 14 22:21:15 vdr  vdr: [3610] PES packet shortened to 7502 bytes (expected: 8974 bytes)
May 14 22:21:46 vdr  vdr: [3609] ERROR: video data stream broken
May 14 22:21:46 vdr  vdr: [3609] initiating emergency exit

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

Pit