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)  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.


>Which application is producing them and under which circumstances???

"(Kernel 2.4.10, *VDR 0.96*, snaphot DVB, Intel)"



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
destination buffer is run to xffff and linux is not willing to swapin
new memory ;-))
I saw no places were "unexpected data" is logged by the driver.
Clear: But's for a driver harder to decide if he is worling
on garbage data or senseful.

I have dvb debug enabled and "removed" (extra bit flags) all 
these messages that just said: have an interrupt. (Sent this 
patch to the address mentioned in the source one week ago together
with a little "volume" patch)

I have slowed down VDR-demux (AFAIR) with a while(40000--)-loop 
(usleep(0) leads to 100% buffer fill up/overrun ) and got better results, 
but more heat of cause :-) (no idle sleep)

I now run a "full" DVB-s 1.5 in the same box at the same place of the
Nova: No problems, except that the first card (above the second)
becomes too hot and the CPU temp increases from 36 to 40C because the
second card is covering the CPU-Fan  a little and that the card
produces extra 5W heat...

The problem becomes only obvious on records on the second card.
But the first card shows very few of those artefact so
that those might be overseen (just if one is not trained). But the 
first card is a full card (V2.1) of cause.. ;-)



>> Maybe there is is still a tiny problem with this type card?
>> I have tested two, both are not working flawlessly in Intel 815
>> (had only Intels avail) (Artefacts. Sound probs. no tune from "H" to
>> "V" etc) The "full" 1.5 and 2.1 records errors free(as far as
>> i can see and as long it is logged at all)

>Do you have sample code which produces streams
>with artifacts and sound problems?

What "code"?
Maybe i have saved a record with those artefacts.
Do you mean that?


>H/V selection is identical in the NOVA and "full" cards (if they use
>the same tuner).

All the same "Alps" type.

>Are you certain it is the H/V switching or could it be a DiSEqC
>problem? (DiSEqC switching is done differently on NOVA cards).

VDR is set up with diseq=0.
I think that means: "no diseq"

I have two Nova in the moment.
The one can -meanwhile- not switch back to "v".
(remember: i have no Multiswitch, just a "T-box" 
("Freitag Elektronik Typ 3536 Sat 4fach Verteiler 5-2050 MHz")
so i have to watch the same channel i am recording when it is "v".)
In the T-Box are decoupling diodes so the highest voltage dominates.
4 Weeks back this card could record "v" and i had no artefacts.

Because the second "fresh" nova card (but same(!) series) too shows 
some artefacts too, but not so much and i find complaints in the 
newgroups i could imagine that all nova (newer?) have a hardware problem.

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?


-- 
Info:
To unsubscribe send a mail to listar@linuxtv.org with "unsubscribe linux-dvb" as subject.


Home | Main Index | Thread Index