Am 09.08.2005 um 23:58 schrieb Reinhard Nissl:

Simon Baxter sent me a similar report, but with debug code inserted which showed that cVideoRepacker wasn't completely stuck.

Is it easy for you to trigger this issue? I've tried two simultanuous timers plus watching a recording but couldn't trigger the issue.

I had two crashes since i upgraded to 1.3.28, i seems to happen when i watch a recording and a timer starts on the second card (i have two FF cards)

Please add the following 4 lines, which are marked with "<========" to the appropriate source locations (cRepacker::Put(), cVideoRepacker::Repack()) in remux.c and send me the output when the problem happens again.

OK, i'll try. Without cVideorepacker anything works again btw

Ciao, Dominique

Hi,

Dominique Simon wrote:

...

Is it easy for you to trigger this issue? I've tried two simultanuous timers plus watching a recording but couldn't trigger the issue.

With your debug code inserted, VDR didn't crash when i tried to trigger this bug. Maybe the Moon needs to be shining? My Syslog is flooded with debug messages now, but Linvdr only stores 200kB of Syslog :(. Any way to reduce the debug output to a minimum?

I fear not. The basic question which this debug output shall reveal is whether cVideoRepacker is still working within the 30 seconds before VDR is restarted. Therefore it is useful to have a report of the bytes consumed and produced by cVideoRepacker.

Looking at your previous logfile it seems that cVideoRepacker doesn't consume any data and therefore doesn't procude any data which leads to an overflow at the input side and an underflow at the output side.

So if you don't mind, just keep it running until it crashes and then send the logfile.

Bye.

Hi,

Dave P wrote:

In case it helps I'm getting the same problem with 1.3.28. Log extract:

Aug 10 21:32:04 sodom vdr[14087]: cVideoRepacker: skipped 4 bytes to sync on next picture Aug 10 21:32:26 sodom vdr[14087]: ERROR: 1 ring buffer overflow (65 bytes dropped) Aug 10 21:32:32 sodom vdr[14087]: ERROR: 6978 ring buffer overflows (1311864 bytes dropped) Aug 10 21:32:35 sodom vdr[14087]: ERROR: video data stream broken

Note that it runs for half an hour before exiting, though there is a hiccup after 5 minutes. Last night it ran for 20 minutes before stopping on a similar recording.

Well, the question is, what happens between 21:32:04 and 21:32:35?

I don't have a good DTV signal and so the data stream will have errors in it (though the picture is still watchable). Could this be the problem?

At the moment it looks like that.

Would you please add the following debug lines (marked with <=====) to remux.c and send the logfile ('s tail) when it happens again?

static int Put(.....) { esyslog(">>>>> cRepacker::Put(%d)", Count); // <============

int n = ResultBuffer->Put(Data, Count); if (n != Count) esyslog(.....);

esyslog("<<<<< cRepacker::Put"); // <============

return n; }

. . .

void cVideoRepacker::Repack(.....) { esyslog(">>>>> cVideoRepacker::Repack(%d)", Count); // <============

// synchronisation is detected some bytes after frame start. const int SkippedBytesLimit = 4;

// reset local scanner localStart = -1;

. . .

// report that syncing dropped some bytes if (skippedBytes > SkippedBytesLimit) { esyslog(.....); skippedBytes = SkippedBytesLimit; }

esyslog("<<<<< cVideoRepacker::Repack()"); // <============ }

Bye.

Am 10.08.2005 um 21:43 schrieb Reinhard Nissl:

So if you don't mind, just keep it running until it crashes and then send the logfile.

I now had a VDSB on timerstart with cVideorepacker turned off! I recently swapped my Budgetcard (2nd card) with a second FF Card for testing purposes. The Budget card has never crashed with VDSB. I'll test cVideorepacker "on" now with my Budgetcard as secondary card. The reason i swapped the Budget with the FF Card was: i sometimes had artefacts with recordings made on the budgetcard.

Ciao, Dominique

Am 15.08.2005 um 00:16 schrieb Reinhard Nissl:

It definitely has to do with signal quality. The patch below triggers this issue on my maschine. I'll try to find a solution soon.

VDR without cVideorepacker seems to me more tollerant to such distortions in signal quality. For unknown reasons my budget card (satelco standard pci, secondary card) sometimes produces artefacts, even when the signalquality is OK (going to test a skystar2 soon, ordered at www.reichelt.de).

Is anyone else experiencing such a behaviour of a secondary budget card? A FF Card on the same LNB-cable won't produce block-artefacts. The behaviour started some time ago, it worked flawlessly at first, but at some update (Driver, VDR?) it began, can't remember when. The behaviour isn't reproducable, it works fine for days, then it's there again.

Ciao, Dominique

Am Montag 15 August 2005 14:57 schrieb Dominique Simon:

Is anyone else experiencing such a behaviour of a secondary budget card? A FF Card on the same LNB-cable won't produce block-artefacts. The behaviour started some time ago, it worked flawlessly at first, but at some update (Driver, VDR?) it began, can't remember when. The behaviour isn't reproducable, it works fine for days, then it's there again.

Since perhaps 1 month I have disturbances in most of my recordings. Watching live tv via the budget cards is ok. I have no clue why this happens.

S.

Am 15.08.2005 um 17:19 schrieb Suur Karu:

Yes, I can confirm it. My secondary card is Technotrend Skystar2. At moment SS2 card removed from PC.

Since when do you experience this? Had you changed DVB Driver / VDR Version when it started?

Ciao, Dominique

Am Montag 15 August 2005 18:09 schrieb Dominique Simon:

Am 15.08.2005 um 17:33 schrieb Sebastian Frei:

...

Since perhaps 1 month I have disturbances in most of my recordings. Watching

Have you changed DVB Driver / VDR Version before?

Ciao, Dominique

Sure, usually I'm using the most recent kernel and vdr version.

S.