Mailing List archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[linux-dvb] Re: WinTV nova problem?
rjkm@convergence.de(Ralph Metzler) 16.10.01 12:27
>Rainer Zocholl writes:
>> rjkm@convergence.de(Ralph Metzler) 14.10.01 23:09
>>
>> Once upon a time Ralph Metzler shaped the electrons to say...
>>
>>>Rainer Zocholl writes:
>>>> Are here other user of "budget" cards like "WinTV nova 541"?
>>>>
>>>> If they have time would someone be so kind and
>>>> do a
>>>>
>>>> grep "ERROR: can't record MPEG1!" /var/log/messages
>>>> /var/log/syslog grep "ERROR: skipped" /var/log/messages
>>>> /var/log/syslog grep "ERROR: unknown picture type"
>>>> /var/log/messages /var/log/syslog
>>>>
>>>> (Or whereever your syslog.conf logs, maybe
>>>> zcat /var/log/*.gz | grep ERROR
>>>> to get some older/longer time infos )
>>
>>>Sorry, but all these messages are not from the DVB driver.
>>
>> Jepp. But the problem seems not to be in the application.
>Why?
Because i got too kernel panics from the driver while
in the interrupt.
Always in a (one of several) memcpy) routines.
>>>Which application is producing them and under which circumstances???
>>
>> "(Kernel 2.4.10, *VDR 0.96*, snaphot DVB, Intel)"
>This does not tell me under which circumstances the mentioned messages
>occur.
I can't reproduce it.
It only "just happens" when i record with VDR from the second
card and this card is WinTV-Nova (not a 1.5, did not try if
the 2.1 too shows this effect.)
>"ERROR: can't record MPEG1!" or "ERROR: skipped"
>does not really tell me what is going on.
It tell's that in the buffer are data tagged that
should not /can't be there.
msi:~/video/VDR# grep "ERROR: can't record MPEG1" *.c
remux.c: esyslog(LOG_INFO, "ERROR: can't record MPEG1!");
void cTS2PES::instant_repack(const uint8_t *Buf, int Count)
{
int c = 0;
while (c < Count && (mpeg == 0 || (mpeg == 1 && found < 7) || (mpeg == 2
&& found < 9)) && (found < 5 || !done)) {
switch (found ) {
case 0:
case 1:
if (Buf[c] == 0x00)
found++;
else
found = 0;
c++;
break;
case 2:
if (Buf[c] == 0x01)
found++;
else if (Buf[c] != 0)
found = 0;
c++;
break;
case 3:
cid = 0;
switch (Buf[c]) {
case PROG_STREAM_MAP:
case PRIVATE_STREAM2:
case PROG_STREAM_DIR:
case ECM_STREAM :
case EMM_STREAM :
case PADDING_STREAM :
case DSM_CC_STREAM :
case ISO13522_STREAM:
done = true;
case PRIVATE_STREAM1:
case VIDEO_STREAM_S ... VIDEO_STREAM_E:
case AUDIO_STREAM_S ... AUDIO_STREAM_E:
found++;
cid = Buf[c++];
break;
default:
found = 0;
break;
}
break;
case 4:
if (Count - c > 1) {
unsigned short *pl = (unsigned short *)(Buf + c);
plength = ntohs(*pl);
c += 2;
found += 2;
}
else {
plen[0] = Buf[c];
found++;
return;
}
break;
case 5: {
plen[1] = Buf[c++];
unsigned short *pl = (unsigned short *)plen;
plength = ntohs(*pl);
found++;
}
break;
case 6:
if (!done) {
flag1 = Buf[c++];
found++;
if ((flag1 & 0xC0) == 0x80 )
mpeg = 2;
else {
esyslog(LOG_INFO, "ERROR: can't record MPEG1!");
hlength = 0;
which = 0;
mpeg = 1;
flag2 = 0;
}
}
break;
case 7:
if (!done && mpeg == 2) {
flag2 = Buf[c++];
found++;
}
break;
case 8:
if (!done && mpeg == 2) {
hlength = Buf[c++];
found++;
}
break;
default:
break;
}
}
...
>> These messages are only indicators. From DVB-drvicer i didn't get
>> such (warning) messages (if i do not count the kernel oopses that
>> sometimes happened in DVBdemux etc. memcpy-routines because the
>Do you mean dvb_demux.c?
>Where does this oops occur in there?
>Can you run it through ksymoops?
I tried, but the problem is, that the error occurs only
in the interrupt part, so nothing is logged.
I just have some screen .jpg.(www.toppoint.de/~zoc/Foto/Oops/)
Sometimes i have partly retyped and compared with ksyms.
I postet that to the list.
>No, I mean a simple program which records the kind of stream you have
>problems with and shows those artifacts.
Ok, no. I would be luky too to be at that point.
I just wanted to have more info.
Maybe this depends on 2.4.x too.
As long i had 2.2 i did not see any of this problems.
>> The driver is involved only so far as that he seems to rely on that
>> the received data is in "spec". But sometimes the garbage seems to
>> lead the driver to try to copy more data in the buffer as would fit:
>> Oops. Maybe VDR delievers wrong pointers, but that too should never
>> lead to a kernel oops andf why should it depend on the board used?
>Without something like a ksymoops dump I really cannot do anything.
Have a look in the postings:
Sa 29.09.01, 15:17
[linux-dvb] Kernel Oops while in interrupt
Do 11.10.01, 16:07
[linux-dvb] kernel oops: dvbdemux trusting received s
I did not retype the entire screen because a stack trace
in an interrupt routine makes not always sense, and as long there
is no takers i hesitate retyping stupidly hex numbers,
maybe with errors... :-)
Maybe you can give some tips "how to get more infos
to un-oops"?
I searched for infos but the only thing i found was
the (outdated) mail of linus concering bugs and the
NT (nice try) of sgi to add an oops-dump facility, but only
for Kernel 2.4.4.
For example:
"objdump -D -S dvbdemux.o"
would have helped a lot, but i did not know that trick.
The problem is, that the box has only 2 PCI slots and only
one serial. It uses lirc serial so i can't use V.24 terminal emu
writing a log file. I tried to make the dvb IR run,
but i found that it was a miss information/understanding:
I thought that dvb now supports the IR input on the 2.1 DVB-s for lirc,
but it should read, that dvb can now use IR _form_ lirc.
And lirc does only support the Hauppage IP control unit (the
"device" with the two AAA batteries ;-) ) and not the IR receiver.
--
Info:
To unsubscribe send a mail to listar@linuxtv.org with "unsubscribe linux-dvb" as subject.
Home |
Main Index |
Thread Index