massenhaft Einträge Audio-/Videorepacker in syslog

Hallo,
sehe ich das richtig, daß der Repacker versucht, Fehler während des Empfangs on-the-fly zu korrigieren? Ist das auch noch sinnvoll, wenn man seine Aufnahmen sowieso durch ProjectX korrigieren läßt?

Nichts gegen diese Idee, aber so weit ich das verstehe, hat ProjectX da einfach wesentlich mehr Rechenzeit zur Verfügung, falls nötig.

Aufhänger meines Posts sind viele Fehler in der Aufnahme (ProjectX meldet so grob alle 3-10 Minuten ein Dropped GOP), begleitet von richtig vielen syslog-Meldungen (cAudioRepacker, cVideoRepacker, cDolbyRepacker). Das Ganze ist mir leider erst nach 2 Tagen aufgefallen
System ist ein Sarge mit selbstgebautem Kernel 2.6.13, vdr 1.3.34 ohne Bigpatch (weil das jemand gefragt hatte), Hardware ist ein Via C3 (Samuel2) 800MHz auf einem PCChips 789 (2PCI: 1x Hauppauge Nova, 1x Skystar2) mit Via 8237 Chipsatz. Ich hatte das Ganze zuerst ca. 2 Wochen mit der Skystar2 alleine getestet - komplett fehlerfrei, dann mit beiden Karten - auch oK, und dann habe ich dummerweise das X nicht abgeschossen, bevor ich den Rechner alleine gelassen habe, ich nehme mal an, daß da die zusätzliche Belastung herkam, die meine Aufnahmen zerlegt hat. Laut FEMon sollte der SNR ausreichen. Naja, heute mal neu gebootet, X weggelassen, mal schauen, was jetzt mit der Aufnahme von Rambo III (Tele5) ist, bisher sieht das log gut aus.

Meine Frage ist nun:
Wäre es möglich, den Repacker ein-/ausschaltbar zu machen? Für Live-TV ist das ja sinnvoll, aber für Aufnahmen sollte man je nach geplanter Weiterverarbeitung entscheiden können.

Oder wie sind Euere Ideen/Ansätze?

Zitat

Original von Trekkie2
Wäre es möglich, den Repacker ein-/ausschaltbar zu machen? Für Live-TV ist das ja sinnvoll, aber für Aufnahmen sollte man je nach geplanter Weiterverarbeitung entscheiden können.

Oder wie sind Euere Ideen/Ansätze?

schau mal auf Seite 1 dieses Threads in meinen Beitrag vom 24.10.2005 21:36

Moin,

Danke für den Hinweis, das stand schon gestern auf meiner ToDo-Liste fürs Wochenende!

Ich meinte, ob es möglich ist, den Repacker im laufenden Betrieb zuzuschalten bzw. auszuschalten, z.B. per OSD. Und daß man ihn für Aufnahmen generell abschalten kann. Die Meldungen von ProjectX kamen mir nämlich ziemlich bekannt vor von der Original-Windows-Software. Wegen dem on-the-fly remuxxen hatte ich massenhaft Dropped GOPs, so kam ich überhaupt erst auf den vdr

Ich finde die Idee mit dem Repacker generell gut, wenn man direkt schaut, aber die Aufnahme möchte ich möglichst unverändert auf die Platte schreiben, damit ProjectX die besten Chancen hat, etwaige Fehler zu korrigieren - nach einer "Vorkorrektur" durch das Aufnahmeprogramm wirft PX meist das ganze GOP einfach weg

Vielen Dank für den Hinweis, WO man den Repacker ausschalten kann, ohne wäre ich da nie drauf gekommen!
Werde jetzt also heute Abend oder morgen mal vdr neu kompilieren und dann nochmal mit laufendem X testen.

Achso, die Aufnahme von heute Nacht konnte ich mangels Zeit noch nicht komplett demuxxen, aber im syslog waren keine Fehler mehr, sieht so weit also gut aus.

Hallo,

die Aufnahme Rambo3 hat geklappt, lag allerdings nicht (wie ich vermutet hatte) am noch laufenden X, sondern wohl an dem eingesteckten CAM. Ich habe oben wohl etwas zu sehr abgekürzt und unterschlagen, daß ich eine Nova-CI verwende. In dem Schacht steckte noch ein Irdeto, das ich mal billig bei ebay geschossen hatte - das hatte ich beim Umbau vom "alten" vdr (ich glaube, es war 1.3.24) auf den neuen einfach drin gelassen und jetzt beim Testen irgendwann mal rausgenommen (und seither gehts), also bei mir:
alter vdr + CAM: alles oK
neuer vdr + CAM: Fehler am Fließband
neuer vdr ohne CAM: wieder alles oK
Läßt sich auch wunderbar reproduzieren - CAM rein, Fehlermeldungen tauchen auf...

Und das Ganze, obwohl ich nur FTA-Sender aufgenommen habe! Was hat das dann mit dem CAM zu tun? Kann es sein, daß das CAM die Streams ganz leicht verändert und der Repacker dann mit diesen Streams nicht mehr klar kommt, ProjectX aber schon? Oder liegt es daran, daß der alte vdr (noch unter kernel 2.6.8 ) das CAM gar nicht erkannt hat?

Hm, ich werde da wohl nur klüger, wenn ich den vdr neu kompiliere, das wird heute aber Nix mehr.

Hat noch jemand einen CI-Schacht und könnte das mal testen?

Hallo an alle !

Wollte kurz berichten:
Habe vor ca. 1 Woche mein stabiles System vdr 1.2.25 von der Platte geputzt
und mich für LinVDR0.7 entschieden, habe alle möglichen Patches und
Kernel-Versionen getestet und bin zur Erkenntnis gekommen , daß die
Treiber für den 2.6 Kernel ziemlich "besch..." sind.
Die Cpu muß voll da sein (mind. 40% idle) sonst kommt es zu den berühmten cAudioRepacker Meldungen im Log.
Das heisst bei meiner Config : KEIN Noad z.B oder vdrconvert und dergl.
Bin jetzt beim 2.6.9-Kernel hängengeblieben mit DVB-Treibern vom 28.01.05
von MarkTwain kompiliert.
Von dem gepatchen DVB-Treibern (MultiStream) kann ich persönlich für
Budget-Karten NICHT empfehlen und schon gar keine verschlüsselten
Sendungen.
Einziges System von einem Freund mit 2xFF wo die gepatchen DVB-Treiber
so halbwegs klappen und es eigentlich keine Artefakte bei Aufnahmen
gibt.
Trekkie2 Das kann ich Dir bestätigen weil die Software-Cam-Ersatz
Geschichte auch die gleichen Fehler produziert ausser bei der von
mir genannten Kernel-DVB-Treiber Kombi.

lg Steve

Zitat

// --- cRemux ----------------------------------------------------------------

#define RESULTBUFFERSIZE KILOBYTE(256)

cRemux::cRemux(int VPid, const int *APids, const int *DPids, const int *SPids, bool ExitOnFailure)
{
exitOnFailure = ExitOnFailure;
isRadio = VPid == 0 VPid == 1 VPid == 0x1FFF;
numUPTerrors = 0;
synced = false;
skipped = 0;
numTracks = 0;
resultSkipped = 0;
resultBuffer = new cRingBufferLinear(RESULTBUFFERSIZE, IPACKS, false, "Result");
resultBuffer->SetTimeouts(0, 100);
if (VPid)
#define TEST_cVideoRepacker
#ifdef TEST_cVideoRepacker
ts2pes[numTracks++] = new cTS2PES(VPid, resultBuffer, IPACKS, 0xE0, 0x00, new cVideoRepacker);
#else
ts2pes[numTracks++] = new cTS2PES(VPid, resultBuffer, IPACKS, 0xE0);
#endif
if (APids) {
int n = 0;
while (*APids && numTracks < MAXTRACKS && n < MAXAPIDS) {
#define TEST_cAudioRepacker
#ifdef TEST_cAudioRepacker
ts2pes[numTracks++] = new cTS2PES(*APids++, resultBuffer, IPACKS, 0xC0 + n, 0x00, new cAudioRepacker(0xC0 + n));
n++;
#else
ts2pes[numTracks++] = new cTS2PES(*APids++, resultBuffer, IPACKS, 0xC0 + n++);
#endif
}
}
if (DPids) {
int n = 0;
while (*DPids && numTracks < MAXTRACKS && n < MAXDPIDS)
ts2pes[numTracks++] = new cTS2PES(*DPids++, resultBuffer, IPACKS, 0x00, 0x80 + n++, new cDolbyRepacker);
}
if (SPids) {
int n = 0;
while (*SPids && numTracks < MAXTRACKS && n < MAXSPIDS)
ts2pes[numTracks++] = new cTS2PES(*SPids++, resultBuffer, IPACKS, 0x00, 0x00, NULL, 0x28 + n++);
}
}

cRemux::~cRemux()
{
for (int t = 0; t < numTracks; t++)
delete ts2pes[t];
delete resultBuffer;
}

int cRemux::GetPid(const uchar *Data)
{
return (((uint16_t)Data[0] & PID_MASK_HI) << | (Data[1] & 0xFF);
}

int cRemux::GetPacketLength(const uchar *Data, int Count, int Offset)
{
// Returns the length of the packet starting at Offset, or -1 if Count is
// too small to contain the entire packet.
int Length = (Offset + 5 < Count) ? (Data[Offset + 4] << + Data[Offset + 5] + 6 : -1;
if (Length > 0 && Offset + Length <= Count)
return Length;
return -1;
}

int cRemux::ScanVideoPacket(const uchar *Data, int Count, int Offset, uchar &PictureType)
{
// Scans the video packet starting at Offset and returns its length.
// If the return value is -1 the packet was not completely in the buffer.
int Length = GetPacketLength(Data, Count, Offset);
if (Length > 0) {
int PesPayloadOffset = 0;
if (AnalyzePesHeader(Data + Offset, Length, PesPayloadOffset) >= phMPEG1) {
for (int i = Offset + PesPayloadOffset; i < Offset + Length - 5; i++) {
if (Data[i] == 0 && Data[i + 1] == 0 && Data[i + 2] == 1) {
switch (Data[i + 3]) {
case SC_PICTURE: PictureType = (Data[i + 5] >> 3) & 0x07;
return Length;
}
}
}
}
PictureType = NO_PICTURE;
return Length;
}
return -1;
}

Alles anzeigen

Darf man einmal fragen, was genau man da "löschen" soll ?

Ich habe nur die beiden "#" entfernt, danach kompilierte der VDR jedoch nicht mehr ...
Ich kann den Code leider nich lesen ... ich denke einmal, das na noch irgendwo zwei "#" entfernt werden müssen ... vermute ich mal.

MFG
Marco

Hallo,

skratzer:
Daß eine Software-Methode natürlich nochmal CPU abzweigt ist klar und Decodieren scheint ja gar nicht so ohne zu sein...

Dr. Seltsam:
Habs mal mit auskommentiertem Repacker getestet: Da hat vdr dann des Öfteren den Notausgang genommen wegen "video data stream broken" Ansonsten hat sich Nix verändert.

Absolut unverständlich ist für mich, daß das Ganze passiert, sobald ich das CAM reinstecke, egal was für einen Sender ich tune? Aber dann nur auf der Nova.

Einen Verdacht habe ich da noch, für den muß ich allerdings noch ein paar Daten nachlegen:
Mein System ist ein Debian sarge mit dem kernel-Paket von Debian: linux-source-2.6.13_2.6.13-1_all.deb, das heißt mit relativ alten DVB-Treibern.

Nach dem, was ich hier gefunden habe:
http://www.linuxtv.org/cgi-bin…tpci/?sortby=date#dirlist
(s. budget*.c) wurde am 03.10. ein Fehler aus dem Code für das Frontend entfernt: "Remove broken stv0299 enhanced tuning code" und am 24.10 etwas am Handling des Frontends optimiert "stv0299_set_frontend(): reduced number of i2c transfers, set register 0x12 from inittab".

Dr. Seltsam, Du scheinst da ja richtig Ahnung von zu haben, wenn ich mir die Beschriebung zu Deiner Kernel-Variante so ansehe: http://drseltsam.device.name/vdr/kernel2614.html

Könnte es daran liegen oder etwas damit zu tun haben?
Ich verliere grade leider etwas den Überblick, aber wenn ich mich recht erinnere, tauchten bei Leuten, die Deinen Kernel (mit CVS-Treibern vom 28.10) verwenden derartige Probleme nicht auf.

Werde mal einen Test machen und den 2.6.14-2 von Debian mit den aktuellen DVB-Treibern aus dem CVS versehen. Eine Frage hätte ich da noch: Hat es Vorteile, wenn man die DVB-Treiber als Module kompiliert? Da ich bei einer Hardware-Änderung sowieso einen neuen Kernel baue, integriere ich immer möglichst viel fest in den Kernel.

Vielen Dank im Voraus!!!

[edit]
mbc, auskommentieren mit // am Zeilenanfang, d.h.
//#define...

Bei mir kompiliert dann alles.

Zitat

Original von Trekkie2

Absolut unverständlich ist für mich, daß das Ganze passiert, sobald ich das CAM reinstecke, egal was für einen Sender ich tune? Aber dann nur auf der Nova.

auf der vdr-Mailinglist war gerade ein Thread wegen CAM und repacker-Fehler.
http://www.linuxtv.org/piperma…/2005-October/005735.html
(geht im November weiter)

Zitat

Nach dem, was ich hier gefunden habe:
http://www.linuxtv.org/cgi-bin…tpci/?sortby=date#dirlist
(s. budget*.c) wurde am 03.10. ein Fehler aus dem Code für das Frontend entfernt: "Remove broken stv0299 enhanced tuning code" und am 24.10 etwas am Handling des Frontends optimiert "stv0299_set_frontend(): reduced number of i2c transfers, set register 0x12 from inittab".

schwer zu sagen, ob das Auswirkungen haben kann.

Zitat

Dr. Seltsam, Du scheinst da ja richtig Ahnung von zu haben

oh nee, das ist zuviel der Ehre Meine Bildungslücken füllen immer noch ganze Bibliotheken

Zitat

wenn ich mich recht erinnere, tauchten bei Leuten, die Deinen Kernel (mit CVS-Treibern vom 28.10) verwenden derartige Probleme nicht auf.

um ehrlich zu sein, habe ich diese Probleme bei mir noch nie mit irgendeinem Kernel gehabt - allerdings verwende ich auch eine selbst kompilierte vdr-Version (ohne bigpatch) die außer dem enAIO-Patch nix drin hat. Was ich allerdings massiv erlebt habe (mit 2.6.14 aber zuletzt nicht mehr aufgefallen) sind probleme mit volllaufendem buffer bei Live-TV während einer Wiedergabe, siehe http://www.vdrportal.de/board/thread.php?threadid=40290

Interessant in diesem Zusammenhang, die Diskussion über einen Zusammenhang (siehe Link oben) zwischen TRANSFERBUFSIZE und repacker-Fehler.

Zitat

Werde mal einen Test machen und den 2.6.14-2 von Debian mit den aktuellen DVB-Treibern aus dem CVS versehen.

Du könntest auch meinen Kernel mal testen -sollte auch unter Sarge laufen. Sind sicher etliche andere Module nicht drin, aber für vdr sollte es reichen.

Zitat

Hat es Vorteile, wenn man die DVB-Treiber als Module kompiliert? Da ich bei einer Hardware-Änderung sowieso einen neuen Kernel baue, integriere ich immer möglichst viel fest in den Kernel.

also, die DVB-Treiber fest in den Kernel einzukompilieren macht sicher keinen Sinn, denn dann hat man bei einem DVB-Treiberabsturz einen kompletten Kernelabsturz. Man sollte schon die Möglichkeit des Entladens und Neuladen der dvb-Module haben. Ich habe sie immer als Kernelmodule kompiliert.

Gruß
Dr. Seltsam

Zitat

Original von Dr. Seltsam
auf der vdr-Mailinglist war gerade ein Thread wegen CAM und repacker-Fehler.
http://www.linuxtv.org/piperma…/2005-October/005735.html
(geht im November weiter)

Puh - meine Verwirrung nimmt zu!

Zitat

Original von Dr. Seltsam
schwer zu sagen, ob das Auswirkungen haben kann.

Dann hilft wohl nur testen!

Zitat

Original von Dr. Seltsam
um ehrlich zu sein, habe ich diese Probleme bei mir noch nie mit irgendeinem Kernel gehabt - allerdings verwende ich auch eine selbst kompilierte vdr-Version (ohne bigpatch) die außer dem enAIO-Patch nix drin hat.

Ich habe meinen 1.3.34 auch selbst kompiliert. An Patches habe ich nur das, was für das xine-network-plugin gebraucht wird.

Zitat

Original von Dr. Seltsam
Was ich allerdings massiv erlebt habe (mit 2.6.14 aber zuletzt nicht mehr aufgefallen) sind probleme mit volllaufendem buffer bei Live-TV während einer Wiedergabe, siehe http://www.vdrportal.de/board/thread.php?threadid=40290

Ein Grund mehr, mal den 2.6.14er zu testen - wenn ich das hier
http://packages.debian.org/cgi-bin/search_packages.pl?keywords=linux-source&searchon=names&subword=1&version=all&release=all
richtig deute, sind die Debian-Leute mit dem 2.6.13er auch so uinzufrieden, daß der 14er schon unstable ist, während der 13er experimental bleibt...

Zitat

Original von Dr. Seltsam
Interessant in diesem Zusammenhang, die Diskussion über einen Zusammenhang (siehe Link oben) zwischen TRANSFERBUFSIZE und repacker-Fehler.

Hm, ist einen Versuch wert. Allerdings ist es bei dem betroffenen dadurch ja auch nicht komplett verschwunden.

Zitat

Original von Dr. Seltsam
Du könntest auch meinen Kernel mal testen -sollte auch unter Sarge laufen. Sind sicher etliche andere Module nicht drin, aber für vdr sollte es reichen.

Mal sehen, wie viel ich an meiner Konfiguration vom 13er anpassen muß. Hatte ja schon geschrieben, daß ich Kernel gerne selber baue.

Zitat

Original von Dr. Seltsam
also, die DVB-Treiber fest in den Kernel einzukompilieren macht sicher keinen Sinn, denn dann hat man bei einem DVB-Treiberabsturz einen kompletten Kernelabsturz.

Ich hab das bisher bei meinen 2 (für DVB-Betrieb) selbstgebauten Kernel so gehabt, da lief das gut. Kompletter Kernelabsturz bedeutet doch dann, daß der Rechner komplett hängt, oder? Das ist mir auf den 2 Kisten nie passiert.
Achso, auf die Art kann ich dann einfach über die Modulreihenfolge auch festlegen, welche Karte Dev.0 und welche Dev.1 ist, oder? Damit hätten wir noch einen weiteren Vorteil...

...Danke auch für den Link - mal schauen, wie weit ich heute noch komme!

Hi,

oh was habe ich mir mit den c*Repacker nur angetan

Hier ein paar Hinweise zur Nachvollziehbarkeit:
- wenn sich die c*Repacker beklagen, bitte in remux.c cTS2PES::ts_to_pes() den

dsyslog("TS continuity error (%d)", ccCounter);

aktivieren.
- wenn vor den c*Repacker Meldungen dann diese "TS continuity error" Meldungen auftauchen, dann liegt das Problem schon vorher und c*Repacker synchronisieren sich nur wieder auf den Datenstrom.
- da beim CAM-Problem auch TS-Pakete verloren gehen, gilt als NOTLÖSUNG derzeit, in dvbdevice.c cDvbDevice::OpenDvr() den cTSBuffer zu vergrößern, z. B.

tsBuffer = new cTSBuffer(fd_dvr, MEGABYTE(16), CardIndex() + 1);

Zumindest hat das denjenigem geholfen, auch wenn nicht klar ist warum, da sich kein einziger Buffer über seine Größe beschwert hat.
- das Scannen der Datenströme belastet natürlich die CPU, vorallem der Videostrom, da hier keinerlei Längenangaben vorliegen und wirklich jedes Byte betrachtet werden muss, bis wieder ein bestimmtes Muster auftaucht (Start-Code). Trotzdem schafft das mein EPIA-MII6000E mit 600 MHz problemlos und macht das für Aufnahme und LiveTV (z. B. Wetten dass..? von gestern) gleichzeitig und gibt das ganze noch mit xine's xxmc-Treiber wieder.
- derzeit bin ich noch auf SuSE 9.3 mit Kernel 2.6.11.4-21.9-smp festgelegt, da ein BIOS-Fehler mir SuSE 10 mit Kernel 2.6.13, Hyperthreading und ACPI verwehrt. VDR betreibe ich mit einem CVS-Abzug des Kernel-DVB-Treibers vom März 2005. Auf dem EPIA läuft der gleiche Treiber mit Kernel 2.6.10. Ansonsten habe ich nur NOVA-S im Einsatz (2 unter SuSE 9.3, 1 im EPIA).

Die c*Repacker sollten mittlerweile eigentlich stabil arbeiten. Trotzdem wurde ich heute darauf hingewiesen, dass evtl. im cVideoRepacker noch ein Fehler steckt. Das muss ich aber erst noch untersuchen.

Bye.

Soo, hab mal X installiert und hier mal ein Auszug aus meinem Log:

Zitat

Nov 2 10:23:50 VDR-Server vdr[1702]: cDolbyRepacker: skipped 252 bytes while syncing on next AC3 frame
Nov 2 10:23:50 VDR-Server vdr[1712]: cDolbyRepacker: skipped 252 bytes while syncing on next AC3 frame
Nov 2 10:23:50 VDR-Server vdr[1702]: cDolbyRepacker: skipped 412 bytes to sync on next AC3 frame
Nov 2 10:23:50 VDR-Server vdr[1712]: cDolbyRepacker: skipped 412 bytes to sync on next AC3 frame
Nov 2 10:23:50 VDR-Server vdr[1702]: cDolbyRepacker: skipped 768 bytes to sync on next AC3 frame
Nov 2 10:23:50 VDR-Server vdr[1702]: cDolbyRepacker: skipped 512 bytes to sync on next AC3 frame
Nov 2 10:23:50 VDR-Server vdr[1712]: cDolbyRepacker: skipped 768 bytes to sync on next AC3 frame
Nov 2 10:23:50 VDR-Server vdr[1712]: cDolbyRepacker: skipped 512 bytes to sync on next AC3 frame

Alles anzeigen

Zitat

Oct 14 03:50:48 VDR-Server vdr[1772]: ERROR: skipped 123 byte to sync on TS packet
Oct 14 03:50:48 VDR-Server vdr[1772]: cAudioRepacker(0xC0): skipped 12 bytes to sync on next audio frame
Oct 14 03:50:48 VDR-Server vdr[1772]: cDolbyRepacker: skipped 806 bytes while syncing on next AC3 frame
Oct 14 03:50:48 VDR-Server vdr[1772]: cDolbyRepacker: skipped 174 bytes to sync on next AC3 frame
Oct 14 03:54:06 VDR-Server vdr[1772]: cAudioRepacker(0xC0): skipped 406 bytes while syncing on next audio frame
Oct 14 03:54:06 VDR-Server vdr[1772]: cDolbyRepacker: skipped 924 bytes while syncing on next AC3 frame
Oct 14 03:54:06 VDR-Server vdr[1772]: cAudioRepacker(0xC0): skipped 8 bytes to sync on next audio frame
Oct 14 03:54:06 VDR-Server vdr[1772]: cDolbyRepacker: skipped 44 bytes to sync on next AC3 frame

Alles anzeigen

! EDIT DER LOGFILES !

MFG
Marco

Hallo Reinhard,

also zuerst mal: Vielen Dank für die tolle Arbeit!

Ich glaube alle hier sind sich einig, daß ohne die Leute, die solche Ideen 1. haben, 2. implementieren können, 3. sich die Zeit nehmen, diese zu implementieren und 4. andere kostenlos daran teilhaben lassen, gäbe es so tolle Projekte nicht und wir wären immer noch auf die meist einfach traurige Software der Hersteller angewiesen - zumindest in meinem Fall hätte das dazu geführt, daß die Karte wieder in den Laden gewandert wäre...

Ich fürchte, daß auch in meinem Fall der Bote für die schlechte Nachricht verantwortlich gemacht wurde: Egal ob mit oder ohne Repacker spinnen die zwei Karten einfach manchmal rum. Ich habe also den Repacker wieder "eingeschaltet", d.h. die beiden #define-Zeilen wieder mitkompiliert.

Dann habe ich den 2.6.14er Kernel probiert - und war erstmal Super-Happy: Eine Probe-Aufnahme von ca. 1 Stunde auf beiden Karten parallel ging problemlos, ich dachte, ich hätte es geschafft.

Dann CAM rein, Ergebnis: wenige Repacker-Meldungen. OK, damit hätte ich leben können.
CAM wieder raus, Reboot: Ab da konnte ich mit beiden Karten Nix mehr anfangen - der vdr hat sich jedesmal nach kürzester Zeit wieder beendet.
Rechner aus, Netztrennschalter aus (damit wirklich Nix in der Karte bleibt), Rechner wieder an, keine Besserung. Dann nur mit der Skystar getestet - unbrauchbar!

Irgendwann gings dann einfach wieder (mit der Skystar2)

Hm, alles was mir jetzt noch einfällt ist ein Wärmeproblem: Das Gehäuse stand zwar die ganze Zeit offen, aber da das Board nur 2 PCI-Steckplätze hat, stecken beide Karten direkt nebeneinander, das Flachbandkabel zur CAM-Platine (PCI-Ausführung) ist so kurz, daß die Nova in der Mitte des Sandwichs zwischen Skystar2 und CAM-Platine sitzt. Ich habe die Temperatur der Karten zwar auch immer mal wieder mit der Hand kontrolliert, aber evtl kommt man an die richtig heißen Teile ja garnicht ran (irgendwo müssen ja aus den 12V vom PCI die 18V für den LNB hochgeregelt werden).

Nun läuft vdr seit einer knappen halben Stunde ohne Mucken und ich nutze die Pause, um mir den Frust wegzuschreiben und Andere zu warnen, daß es vielleicht doch irgendein Hardware-Problem sein könnte...

Naja, ich hänge jetzt mal einen 80er Lüfter direkt über die 2 Karten und schaue, obs dann länger als 1 Stunde läuft.

Habt Ihr einen Tip für mich, welche Bauteile bei TT-Budget bzw. Skystar2 (2.6d)-Karten heiß werden bzw. problematisch sind?

Also Reinhard,
ich entschuldige mich, daß ich den repacker in Verdacht hatte! Das sollte auch keine böse Unterstellung sein, aber der Entwicklungsprozess ist ganz selbstverständlich fehlerbehaftet und ich versuche halt eine Fehlerquelle nach der anderen auszuschließen.

Danke auch nochmal für die ausführliche Anleitung mit der Pufferbergrößerung, werde ich als Nächstes einbauen. Zuerst muß ich allerdings ohne CAM wieder vernünftig aufnehmen können...

[edit]
mbc, wolltest Du nicht zuletzt noch Repacker auskommentieren?
Und was hast Du mit den Log-Files gemacht?
Steh auf dem Schlauch und verstehs nicht...

[edit2]
Hab grade noch ein 10cm 50adriges SCSI-Kabel gefunden, damit kann ich auch die CAM-Platine aus der Schusslinie bringen.

Hi,

du hast recht, das ganze ist/war tough stuff, vorallem wenn man versucht, das ganze mit sowenig memcpy()s wie möglich über die Bühne zu bekommen.

Weil die c*Repacker so geschwätzig sind, liegt der Verdacht natürlich nahe, dass da noch Fehler drin sind, denn soviele Probleme wie hier gemeldet werden, hatten wir früher nie mit den Aufnahmen. Tja, eine Zeile mit der Anzahl TS discontinuities fällt natürlich nicht so auf. Und ich werde das Logging bis zur 1.4 wohl auf optional und/oder als Summary umarbeiten.

Soweit es meine Zeit erlaubt gehe ich den Problemen auch nach. Deshalb wäre es mir wichtig, das vorab geprüft wird, ob TS discontinuities vorliegen, dann kann ich an den c*Repackern nämlich nichts machen, ausser die Meldungen zu unterdrücken. Vielleicht hilft es ja was, den cTSBuffer zu vergrößern, wie weiter oben beschrieben.

Aber meist ist das Problem bei TS discontinuities in der Hardware oder bei äußeren Einflüssen zu suchen: Wetter, Schüsselausrichtung, Kabel, Stecker, Kartentemperatur, Mainboard (DMA, Interrupts). Aber auch Kernel und DVB-Treiber können böse mitspielen.

Bei mir sind die beiden NOVA-S von einer NV6600GT und einer halbhohen WLAN-Karte eingefasst, in einem Desktop-Gehäuse und -Board, dass nur 4 Slots bietet. Bei offenem Gehäuse hat es oberhalb der NOVA-S 42 °C, laut AUX-Sensor des Mainboards.

Also: c*Repacker-Probleme ruhig melden (gerne auch ein Hinweise auf einen Thread an die bekannte eMail-Adresse, da ich im Portal nur sporadisch unterwegs bin), aber andere Probleme vorher ausschließen.

EDIT: ich habe ein 50 cm SCSI-Kabel am CAM hängen!

Bye.

Hi,

ohje, nun muß ich was beichten: Ich hab unbemerkt den General-Fehler in Form eines DECT-Telefons mit in die Geschichte reingebracht

Das habe ich vor 4 Wochen als Ersatz mal schnell provisorisch (bevor ich das nächste Mal diesen Satz sage, stürze ich mich eher von der Brücke) angehängt und einen Platz auf der Fensterbank, d.h. weit weg von den SAT-Kabeln (die laufen hier in einem Extra-Kanal durch alle 5 Stockwerke) ausgesucht.

Leider habe ich vergessen, daß das eine Kabel, daß ich jetzt zusätzlich verwendet habe, VOR diesem 4er Strang abgeht und über den Balkon geführt wurde - NEBEN der Station.

Nun ist so ein Telefon ab und zu mal leer, dann sind die Störungen weg, weil Kabel Tauschen hatte ich natürlich probiert - aber offensichtlich immer nur dann, wenn das Telefon aus war...

Zusammen mit den anderen Fehlerquellen ergab das nicht-reproduzierbare, scheinbar völlig zufällige Fehler, die mich fast in den Wahnsinn getrieben hätten und mit denen ich diese Woche jeden Feierabend und das gesamte Wochenende verbracht habe - wo ist eigentlich der Kopf-gegen-die-Wand-Smiley?

Also habe ich bisher:
- CAM
- DECT-Telefon
als sichere Fehlerquellen, ausschließen kann ich inzwischen wohl:
- Repacker
- IRQ-Sharing mit eth0 (dieser IRQ scheint fest verdrahtet auf dem Board), USB wird noch getestet

Zum Logging: Also mir hat es insgesamt SEHR geholfen!
Ansonsten bleibt mir ja nur das log von ProjectX im Nachhinein, weil die Anzeige von femon war zu langsam um die DECT-Störungen wiederzugeben, da hatte ich immer nur kurze Aussetzer...
Also BITTE lass das ausführliche Logging drin, zumindest als Option! Und wo wir schonmal dabei sind: Kannst Du die Kartennummer von der der fehlerhafte Stream kam noch dazuschreiben? Oder ist die zu diesem Zeitpunkt schwer zu ermitteln?

Gibt es eigentlich eine Philosophie hinter dem system WAS WOHIN geloggt wird? Ich suche meist erstmal im falschen log (syslog/messages), ein spezielles vdr-log in /var/log fände ich wesentlich praktischer...

Danke auch für die Erfahrungen mit dem SCSI-Kabel und den Temperaturen, da ich für das Ding ein Eigenbau-Gehäuse plane, suche ich hier noch Erfahrungswerte.

Hi,

ich hatte hier die letzten 4 Wochen auch ein DECT-Telefon stehen. Abstand zum Kabel ca. 1.2 m und zum offenen Rechner ca. 3.5 m. Die Basis-Station war ungefähr 10 m weg, aber trotzdem gabs keine Probleme.

Es gibt aber im Haus auch ein altes Antennenkabel und da hatte ich in den letzten 4 Wochen Probleme, bei einem Abstand zur Basisstation von gut 4 m.

Bzgl. dem Logging:
cRemux kennt die Karte nicht, von der die Daten stammen. Dass müsste man sich aus den Logfile Einträgen zusammen suchen. Ansonsten werden VDRs *syslog() Aufrufe benutzt, d. h. mit geeigneten Einstellungen für VDR (facility?) und syslog müssten die Ausgaben auch in ein eigenes File geschrieben werden können.

Bye.

Zitat

Original von rnissl
ich hatte hier die letzten 4 Wochen auch ein DECT-Telefon stehen. Abstand zum Kabel ca. 1.2 m und zum offenen Rechner ca. 3.5 m. Die Basis-Station war ungefähr 10 m weg, aber trotzdem gabs keine Probleme.

Ja, wenn ich eines von den neuen Kabeln verlegt hätte...
...der Sonderweg, den dieses Kabel nimmt, kommt davon, daß es einfach von der guten alten terrestrischen Hausantenne übrig geblieben ist und am Verteiler im Dachboden noch eine Buchse frei war - ich nehme mal an, daß das Kabel noch zu Zeiten verlegt wurde, als es grade mal ein Farbsignal gab...

Zitat

Original von rnissl
Bzgl. dem Logging:
cRemux kennt die Karte nicht, von der die Daten stammen. Dass müsste man sich aus den Logfile Einträgen zusammen suchen. Ansonsten werden VDRs *syslog() Aufrufe benutzt, d. h. mit geeigneten Einstellungen für VDR (facility?) und syslog müssten die Ausgaben auch in ein eigenes File geschrieben werden können.

Hm, das hieße eine Zeile
vdr.* /var/log/vdr.log
in /etc/syslog.conf müßte alles in die separate Datei umleiten? Kommt auf meine ToDo-Liste!

Hoi

Trekkie2

bei syslog-ng gehts so

destination messages { file("/var/log/messages-$YEAR-$MONTH-$DAY"); };

entsprechenden Filter kannste ja vorher noch setzen

funzt bei mir auch etlichen Rechner sehr gut

PS: bei meinem VDR:

Datei: syslog-ng.conf   Spalte 0           1364 Bytes                                                                                                    0%
# $Header: /var/cvsroot/gentoo-x86/app-admin/syslog-ng/files/syslog-ng.conf.gentoo,v 1.4 2004/07/18 02:25:02 dragonheart Exp $
#
# Syslog-ng default configuration file for Gentoo Linux
# contributed by Michael Sterrett


options {
        long_hostnames(off);
        sync(0);


        # The default action of syslog-ng 1.6.0 is to log a STATS line
        # to the file every 10 minutes.  That's pretty ugly after a while.
        # Change it to every 12 hours so you get a nice daily update of
        # how many messages syslog-ng missed (0).
        stats(43200);
};


source src { unix-stream("/dev/log"); internal(); pipe("/proc/kmsg"); };


destination messages { file("/var/log/messages-$YEAR-$MONTH-$DAY"); };
destination vdr { file("/var/log/messages-vdr-$YEAR-$MONTH-$DAY"); };


filter F_vdr{ program(vdr); };
filter F_mesg{
    facility(auth,authpriv,cron,daemon,kern,syslog,user)
    and not program(vdr);
    };


# By default messages are logged to tty12...
destination console_all { file("/dev/tty12"); };
# ...if you intend to use /dev/console for programs like xconsole
# you can comment out the destination line above that references /dev/tty12
# and uncomment the line below.
#destination console_all { file("/dev/console"); };


log { source(src); filter(F_mesg); destination(messages); };
log { source(src); filter(F_vdr); destination(vdr); };
log { source(src); destination(console_all); };

würde mich aber nicht wundern, wenn es noch besser geht

So, ich habe mal etwas testen können ...

Also ich habe mal die TS-Dinger loggen lassen und siehe da:

Zitat

Nov 12 20:15:08 VDR-Server vdr[1685]: TS continuity error (3)
Nov 12 20:15:08 VDR-Server vdr[1685]: cDolbyRepacker: skipped 840 bytes to sync on next AC3 frame
Nov 12 20:15:08 VDR-Server vdr[1685]: cDolbyRepacker: skipped 648 bytes to sync on next AC3 frame
Nov 12 20:15:08 VDR-Server vdr[1685]: cDolbyRepacker: skipped 1024 bytes to sync on next AC3 frame

Zitat

Nov 12 20:53:18 VDR-Server vdr[1685]: TS continuity error (3)
Nov 12 20:53:18 VDR-Server vdr[1685]: cDolbyRepacker: skipped 1004 bytes while syncing on next AC3 frame
Nov 12 20:53:18 VDR-Server vdr[1685]: cDolbyRepacker: skipped 1420 bytes to sync on next AC3 frame

Zitat

Nov 12 21:02:28 VDR-Server vdr[1685]: TS continuity error (13)
Nov 12 21:02:28 VDR-Server vdr[1685]: cDolbyRepacker: skipped 36 bytes while syncing on next AC3 frame
Nov 12 21:02:28 VDR-Server vdr[1685]: cDolbyRepacker: skipped 1692 bytes to sync on next AC3 frame
Nov 12 21:02:28 VDR-Server vdr[1685]: cDolbyRepacker: skipped 1024 bytes to sync on next AC3 frame

Zitat

Nov 12 21:35:23 VDR-Server vdr[1685]: TS continuity error (10)
Nov 12 21:35:23 VDR-Server vdr[1769]: TS continuity error (10)
Nov 12 21:35:23 VDR-Server vdr[1685]: cDolbyRepacker: skipped 2035 bytes while syncing on next AC3 frame
Nov 12 21:35:23 VDR-Server vdr[1769]: cDolbyRepacker: skipped 2035 bytes while syncing on next AC3 frame
Nov 12 21:35:23 VDR-Server vdr[1685]: cDolbyRepacker: skipped 101 bytes to sync on next AC3 frame
Nov 12 21:35:23 VDR-Server vdr[1769]: cDolbyRepacker: skipped 101 bytes to sync on next AC3 frame
Nov 12 21:35:24 VDR-Server vdr[1685]: cDolbyRepacker: skipped 128 bytes to sync on next AC3 frame
Nov 12 21:35:24 VDR-Server vdr[1769]: cDolbyRepacker: skipped 128 bytes to sync on next AC3 frame

Alles anzeigen

Zitat

Nov 12 21:45:47 VDR-Server vdr[1685]: TS continuity error (15)
Nov 12 21:45:47 VDR-Server vdr[1685]: cDolbyRepacker: skipped 1052 bytes while syncing on next AC3 frame
Nov 12 21:45:47 VDR-Server vdr[1769]: TS continuity error (15)
Nov 12 21:45:47 VDR-Server vdr[1769]: cDolbyRepacker: skipped 1052 bytes while syncing on next AC3 frame
Nov 12 21:45:47 VDR-Server vdr[1685]: cDolbyRepacker: skipped 1268 bytes to sync on next AC3 frame
Nov 12 21:45:47 VDR-Server vdr[1769]: cDolbyRepacker: skipped 1268 bytes to sync on next AC3 frame

Zitat

Nov 12 21:58:54 VDR-Server vdr[1685]: TS continuity error (8)
Nov 12 21:58:54 VDR-Server vdr[1769]: TS continuity error (8)
Nov 12 21:58:54 VDR-Server vdr[1685]: cDolbyRepacker: skipped 1880 bytes to sync on next AC3 frame
Nov 12 21:58:54 VDR-Server vdr[1769]: cDolbyRepacker: skipped 1880 bytes to sync on next AC3 frame
Nov 12 21:58:54 VDR-Server vdr[1685]: cDolbyRepacker: MPEG 2 PES header expected (dropped 616 bytes)
Nov 12 21:58:54 VDR-Server vdr[1769]: cDolbyRepacker: MPEG 2 PES header expected (dropped 616 bytes)
Nov 12 21:58:54 VDR-Server vdr[1685]: cDolbyRepacker: skipped 808 bytes to sync on next AC3 frame
Nov 12 21:58:54 VDR-Server vdr[1769]: cDolbyRepacker: skipped 808 bytes to sync on next AC3 frame

Alles anzeigen

Die Dinger tauchen also bei mir auch auf.

Was mir aber nicht so recht einleuchten will ist die Ursache der Fehler, denn die Fehlermeldungen tauchen definitiv nur bei ProSieben bzw. Sat1 (Austria) auf, die deutschen "Partner" habe ich nicht überpüft.

ALLE anderen Aufnahmen, haben diese Fehler nicht, dort gibt es keine Fehlermeldungen, einzig bei den beiden (oder halt wenn es bei den deutschen genau so ist: vieren) Sendern mit den Dolby-Aufnahmen und so wie ich meine gemerkt zu haben speziell bei den 5.1 Ausstrahlungen.

Außerdem ist die Frequenz der Transponder anders:
German: 12480.00
Austria: 12051.00

Auch Randy sagt hier, das das Problem bei den Austria-Sendern behoben sein müßte, wenn man von DECT ausgehen würde:
http://www.vdr-portal.de/board…?postid=371719#post371719

Außerdem sind es nicht die typischen Probleme die für ein DECT-Telefon sprechen würden.

Ich habe jetzt einmal erneut die 1.3.22er VDR-Version installiert und werde am nächsten WE mal schauen ob die Aufnahmen dort auch Fehler beinhalten, bzw. ob sie auch nicht weiterverarbeitbar sind.

Der Rest der Anlage funktioniert einwandfrei, die Signale sind alle bombig, so wie es immer war, ich schliesse somit dortige Fehler mit ziemlicher Sicherheit ersteinmal aus.

Es ist für mich schon komisch, wenn ich die Aufnahmen, bei denen der Repacker korrigiert hat nicht mehr weiterverarbeiten kann, selbst die allerneusten Versionen von Projectx und PVAStrumento geben den Geist auf.

Auch komisch, das bei mir nur Audio-Meldungen erscheinen, wäre es ein Fehler durch Fremdeinwirkung, müßten doch auch die Video-inhalte beeinflußt werden, da gibt es doch auch einen Repacker für wenn ich mich nicht irre.

Ich weis nur, das es nie Probleme mit den VDR-Dateien gab, die liessen sich immer ohne Fehlermeldungen und Problemen weiterverarbeiten ... somit für mich schon relativ komisch, das es auf einmal diese Probleme gibt.

Ein Standalone-Receiver der auch an der gleichen Anlage hängt hat z.B. keine Probleme, die Aufnahmen von dort weisen keine Fehler auf.

Meine schwache Vermutung:
Die Sender geben seit einiger Zeit einen "konformen" Dolby-Stream raus, d.h. sie schalten neben der 2.0/5.1 Umschaltung auch auf die richtige Bitrate um ( 256 / 448 ).
Das war früher nicht so, da war 2.0 und 5.1 jeweils mit 448kb/s kodiert.

Ich würde einfach mal vermuten, das es eventl. während dieser Umschaltung zu den Problemen kommt, nämlich z.B. dann, wenn Werbung kommt, denn z.B. genau um 20.15 beginnt der Film, dort wird dann nämlich von 2.0 auf 5.1 umgeschaltet.

Also, laut Log (siehe anfang dieses Beitrages) so zu belegen:

Zitat

20.15 : Fehler --> Umschaltung von 2.0 auf 5.1 Film beginnt
20.53 : Fehler --> Umschaltung von 5.1 auf 2.0 erste Werbeeinblendung
21.02 : Fehler --> Umschaltung von 2.0 auf 5.1 erste Werbeeinblendung beendet Film geht weiter
21.35 : Fehler --> Umschaltung von 5.1 auf 2.0 zweite Werbeeinblendung
21.45 : Fehler --> Umschaltung von 2.0 auf 5.1 zweite Werbeeinblendung beendet Film geht weiter
21.59 : Fehler --> Umschaltung von 5.1 auf 2.0 Film endet

Um ca. 22.30 wird ein "record-Thread" geschlossen, also genau 30 Minuten nach dem letzten Fehler .. und mein "Offset" entspricht genau 30 Minuten am Ende ...

Da die Werbeeinblendungen im Schnitt etwa 10 Minuten dauern, käme das auch sehr gut hin.
Sieht für mich somit sehr Verdächtig aus, deshalb lasse ich da auch nicht locker

Dieses würde auch meine Vermutung bzw. Beobachtung bestätigen, das nur die Aufnahmen unbrauchbar sind, die in 5.1 ausgestrahlt wurden, denn bei 2.0 Filmen wird während Film und Werbung nichts am Audio-Stream geändert und es tauchen auch dann während der Aufnahme keine Fehler auf (wenn ich mich recht erinnere).

MFG
Marco

Hallo,

ich habe das gleiche Problem mit Sendern die in DolbyDigital 5.1 ausstrahlen.
Jedoch besteht das Problem auch bei Premiere 1 und 2 und dort wird nicht zwischen den Tonspuren gewechselt.

Nov 20 11:29:56 linvdr user.err vdr[1915]: cDolbyRepacker: skipped 2035 bytes while syncing on next AC3 frame
Nov 20 11:29:56 linvdr user.err vdr[1915]: cAudioRepacker(0xC0): skipped 572 bytes while syncing on next audio frame
Nov 20 11:29:56 linvdr user.err vdr[1915]: cDolbyRepacker: skipped 2039 bytes while syncing on next AC3 frame
Nov 20 11:29:56 linvdr user.err vdr[1915]: cDolbyRepacker: skipped 1298 bytes while syncing on next AC3 frame
Nov 20 11:30:27 linvdr user.err vdr[1914]: ERROR: video data stream broken
Nov 20 11:30:27 linvdr user.err vdr[1914]: initiating emergency exit

Hi,

deine Meldungen stammen aus user.err. Gibt es weitere Meldungen in anderen Logfiles (Vermutung: user.warn oder user.info)?

Hast du in remux.c, ts_to_pes() das loggen von TS continuity Fehlern eingeschaltet?

Wenn TS Fehler vorliegen können die c*Repacker nicht anders reagieren. cVideoRepacker nimmt eine Sonderstellung ein: da keine Längeninformationen vorliegen geht ein Frame immer bis zum nächsten Start-Code und wäre dann halt länger oder kürzer, aber trotzdem fehlerhaft (Klötzchen). Eine Meldung erscheint hier nur, wenn ein falscher Startcode (System-Startcode) gefunden wird.

Bzgl. TS Fehlern: evtl. hilft es, in dvbdevice.c, OpenDvr() den cTSBuffer zu vergrößern.

Bzgl. Premiere: man hat mir gemeldet, dass cVideoRepacker hier evtl. falsch arbeiten würde. Leider kann ich das nicht nachvollziehen (kein Premiere), und der Melder hat mich auch noch nicht unterstützt.

Bitte mal den Anhang einspielen, und falls tatsächlich was geloggt wird, mir bitte zukommen lassen.

Bye.