Jump to content

A DVBViewer Bug or Hardware fault?


RedDwarf

Recommended Posts

I keep experiencing stream errors while recording using the latest? DVBViewer (4.8.1.0).

 

It seems to happen only when recording two channels at the same time on different transponders and only when stopping recording that the errors occur in the recording which is being viewed. Therefore it corrupts the channel which is still recording. Packet loss occurs in transedit if a similar situation is used when running two instances of transedit and recording in each.

 

I suspect that it is the Satellite card hardware at fault but I need to prove it before returning it so can anyone confirm that this isn't a bug/obscure fault with DVBViewer?

 

nVidia driver is 280.26 on Windows XP Pro x86

Satellite card drivers = 2.2.0.44 - the latest I believe

 

support.zip

Edited by RedDwarf
Link to comment

In what respect?

 

I have two satellites and both go to a DiSEqC switch and the output is combined with the DVB-T/DAB feed down to my PC.

 

Also to a TV, DAB radio and Satellite wallplate splitter near my PC. DVB-T and DAB muxed using a loftbox and then to a TV/SAT Combiner with the DiSEqC feed because I can only get two cables inside the cable route. The 2nd cable is for a separate satellite cable for LNB2.

 

All cable is Satellite cable and waterproofed using silicon grease with F connectors.

 

It is only one dual tuner Satellite card and a separate DVB-T dual tuner but I don't think that that is part of the problem.

Edited by RedDwarf
Link to comment

you have to get rid of the diseqc-switches and invest instead in a real multiswitch. Or you have to live with the problem and avoid switching to different transponders/satellites (same sat same IF-plane won't harm) while recording.

Link to comment

Viewing Tuner 1 (T1) and stopping Tuner 2 (T2) while both are recording creates stream errors in T1

 

Viewing T2 and stopping T1 created no stream errors when both tuners were H.264

 

Viewing T2 and stopping T2 created stream errors in T1

 

Viewing T2 and stopping T1 created stream errors on another test when T1 was H.264 and T2 was Mpeg2

 

Viewing T2 and stopping T2 created no stream errors, T1 H.264 and T2 Mpeg2

 

It tends to be around 1 to 3 stream errors which are created on each occasion, which is enough to corrupt the recording, especially with H.264.

Link to comment

you have to get rid of the diseqc-switches and invest instead in a real multiswitch. Or you have to live with the problem and avoid switching to different transponders/satellites (same sat same IF-plane won't harm) while recording.

 

Is this a known problem with DiSEqC switches?

 

No DiSEqC switching took place while recording, satellites were not switched, recordings were only on one satellite! Therefore I cannot see how there can be a problem. Should this still be a problem?

 

However, I will disconnect the DiSEqC when I can and test again to rule it out.

Link to comment

..these problems are quite common with twin/quad-lnbs combined by diseqc switches. Anyway, it's not a bug of the DVBViewer.

 

/edit

 

..twins and quads without disecq can suffer also from cross talk ;)

Link to comment

What if I am not actually switching satellites?

 

The recordings are only done on one satellite. Both tuners are connected to the same satellite so effectively there no switching done.

 

The stream errors and packet loss occurs when stopping a recording so no switching is being done. It also depends upon which tuner is being viewed at the time.

 

I suspect the Satellite card because I RMA'd the first card because it was losing lots of packets. This card is not as bad but there is still some packet loss which is ruining recordings. These cards have been revised on many occasions to fix errors and I suspect my card still has a problem.

 

Any ideas on how best to detect it? It doesn't seem to happen on every occasion, which is why I don't think the DiSEqC switch is a problem, but it frequently does occur especially when I don't want it to. Certainly enough to be a problem and cause problems with my recordings.

 

I don't think that I should have to pay so much attention when doing recordings, trying to avoid causing corruption is such a damn nuisance. It should just work without a hitch.

Edited by RedDwarf
Link to comment

Do you use twins or quads? Try a loopthrough configuration with a single cable (you have to check "shared lnb" in the hardware options).

I have Quad LNB's on both dishes. I will disconnect the DiSEqC switch and see if that changes anything, although I doubt it will help. It will eliminate the DiSEqC part of the equation which will simplify matters while I get to the bottom of the cause.

 

Do you have any instructions on setting up a loop through configuration? In what way will that help? Do you have any links to a webpage where I can read about it?

Link to comment

you have exactly the configuration I had in mind and I was talking about. Believe me, I went through the same experience ;) After replacing the lnbs and diseqc switches by quattros and a multiswitch I have no glitches anymore :) (4 lnbs and 2 dishes)

 

With loopthrough you exclude any switching in the quads and diseqc switches by using only a single cable fom your quad. Dunno whether your card has a loopthrough connection. If yes you take a short cable and connect the output of one half with the input of the other half of your card. If not you could use a splitter.

Link to comment

All that would mean a lot more expense :( Those Quattros and switches can get expensive.

 

I will find some info on loop through connections to learn more about it. My Sat card doesn't have a loop through connector, it has two separate LNB inputs.

 

I will start by disconnecting the DiSEqC switch and re-test the Sat card to see if the problem still exists.

 

ATM both dishes, which are different sizes, point at the same Satellite so I don't have any use for the 2nd dish until I decide what to align it to. I was considering installing a motor so I could receive from a number of Satellites. ATM it is a dish without a function.

 

Thanks for your help Derrick, it's appreciated. ;)

Edited by RedDwarf
Link to comment

..you're welome :) If you use totally seperated sat_IF_feeds (different dish, lnb and cable) you won't need to experiment with loop through. Then you can record a channel with T1 and zap with T2. If you then still have disconties it shouldn't come from the cable connected to T1. But there is still a remote chance if there are other receivers connected causing ground loops etc.

Link to comment

I have disconnected the DiSEqC switch so the connection is as simple as it can be, only the Diplexer to combine the TV and satellite onto one cable. Guess what? It's still causing stream errors when the recording is stopped while watching another channel. Therefore it looks like it is a fault with the card.

Link to comment
Therefore it looks like it is a fault with the card.

Looks like the process of releasing a tuner lets the other one fall out of rythm.

 

However, saying "it is a fault with the card" is too simple. Often enough complex interdependencies between devices, mainboard chipsets, drivers, BIOS, Windows, applications etc. are causing such issues, making it very hard to pinpoint the source of the trouble. We feel better after having found something we can point at and blame (a psychological effect), but in many cases "things are not coming together as they should" is a more appropriate conclusion. The card does not work properly in the context of your PC - that's all you really know. It might work well in another PC, where other cards would fail...

Link to comment

The problem that this card is experiencing is very similar to the problem that the first card had and that was confirmed as faulty. It was a known problem with "some" cards of the first card revision. I think that they only noticed the problem under their testing conditions but missed it under other testing methods that I have found. They only tested using transedit and changing channels, however I have found slightly different conditions where the problem also shows itself. It makes the card unusable in any reasonable circumstance.

 

These cards have been revised many times to fix bugs with the chipset.

Link to comment

P.S.

 

Looks like the process of releasing a tuner lets the other one fall out of rythm.

In order to verify this, try the following:

 

- Let DVBViewer play a channel and start recording it manually.

 

- Schedule a background recording that will use the other tuner.

 

- Wait until the scheduled recording has started. Then stop the first recording. Since playback is still going on, DVBViewer will not release the device - no discontinuities expected.

 

- Then perform View -> Close Graph to stop playback. DVBViewer will release the device. Discontinuities are expected...

Link to comment

I have tested what you wrote and it does do that.

 

I have also tested scheduling two recordings and while watching the second recording, stopping the first using recording statistics and that does cause stream errors (2). The question is, why is it doing this? This is the exact situation that I have been using to verify that a TV programme has finished before stopping the recording while doing back to back TV programme recordings where there is insufficient time between TV programmes to record them using timers. That is 3 recordings where two programmes follow each other on the same channel.

 

Even changing channels while a recording is taking place causes 1 stream error in the recording.

 

If I do as you suggested but change to the scheduled recording and then stop the first recording using recording statistics [stop timer], it produces 3 stream errors in the 2nd recording.

Edited by RedDwarf
Link to comment

I have just switched channels while a scheduled recording was taking place and it produced 4 extra stream errors for a total of 7.

 

I have updated to DVBViewer 4.9 today.

Edited by RedDwarf
Link to comment
The question is, why is it doing this?

Often issues like that are due to bus latencies or drivers causing DPC latencies. In a Windows PC several devices are sharing the data lanes and other resources and are using them time-multiplexed.

 

The basic real-time reception problem is that satellites don't wait for your PC to get ready with whatever it is doing at the moment. The data is pushed into your PC and has to be processed in time, otherwise it may get lost.

 

So if releasing a tuner causes something that occupies the bus or the CPU some milliseconds too long, you get discontinuities. It does not not depend solely on the DVB card, but also on the BIOS, the mainboard chip set and how bus-sharing is handled.

 

If you want to dive deeper into this matter, try this

 

http://www.thesycon.de/deu/latency_check.shtml

 

There are some (rather few) users who managed to fix such issues by changing the PCI latency value in the BIOS settings, or by updating chipset drivers, or by replacing Windows default chipset drivers by the ones from the chipset vendor... but it's a gamble. Trying all this may take a lot of time without success.

Link to comment

I been having the same kind of issue for some time now but it is a somehow different landscape:

 

1 dish with a quad LNB pointing to Astra 19,2°E

1 PC(1) with a dual DVB-S2 tuner (TBS 6981) and the recording service

1 PC(2) with a single DVB-S2 tuner (Hauppauge Nova HD-S2) and DVBViewer

 

The signal on any of the LNBs is distorted when using/releasing any other LNB, be it in the same PC or on other PC. The most common case I experience is when recording something with the service on PC(1) and watching live-tv on PC(2): something like channel change on PC(2) causes something like 2 to 8 discontinuities to be logged into the recorded file. I´ve always suspected some kind of grounding problem and don´t want to worry too much about it.

 

Does someone know if the PCI latency settings also affect PCIe cards?

Link to comment

Often issues like that are due to bus latencies or drivers causing DPC latencies. In a Windows PC several devices are sharing the data lanes and other resources and are using them time-multiplexed.

 

The basic real-time reception problem is that satellites don't wait for your PC to get ready with whatever it is doing at the moment. The data is pushed into your PC and has to be processed in time, otherwise it may get lost.

 

So if releasing a tuner causes something that occupies the bus or the CPU some milliseconds too long, you get discontinuities. It does not not depend solely on the DVB card, but also on the BIOS, the mainboard chip set and how bus-sharing is handled.

 

If you want to dive deeper into this matter, try this

 

http://www.thesycon.de/deu/latency_check.shtml

 

There are some (rather few) users who managed to fix such issues by changing the PCI latency value in the BIOS settings, or by updating chipset drivers, or by replacing Windows default chipset drivers by the ones from the chipset vendor... but it's a gamble. Trying all this may take a lot of time without success.

Thanks for making me aware of that Application. However I am very doubtful about such applications and their usefulness.

 

That application has arbitrary values that the coders claim will affect a PC's realtime performance. I have just tested my Dual tuner PCI DVB-T card doing similar things but with many more channel changes and there was not one discontinuity. No stream errors whatsoever. So I will repeat, that I believe the fault is with the card just like it was with the first card that I received. A very buggy chipset which should not be on sale IMO. The people who sell these cards try to claim it is people's systems that are at fault and not the hardware that they sell that is faulty. I spoke to a representative yesterday and he tried to say that the problem is probably with my system, even though he did not know my system and that I should spend hundreds of pounds and upgrade my system. Which probably wouldn't make any difference in any case. It would still be a faulty card with the same problem.

 

If latency was such an issue then putting some memory on the card would solve the issue. Memory is so cheap, putting adequate memory to cache the data to prevent such problems would be a very easy solution IMO. Instead they try and claim it is people's PC's that are at fault even when other cards work without issue under the exact same conditions and on the same Operating system.

 

This card contains the very first chipset revision and there have been about six revisions so far to my knowledge. Some of the later revisions were to add features but the early revisions were to correct chipset bugs and the problems that I am experiencing was the first thing to be corrected.

 

I doubt that my Quad LNB has anything to do with it because it's an Invacom Quad, I have one on each dish. Invacom are very high quality LNB's so should not suffer crosstalk at the price they are.

 

Thanks for the help, it's been interesting. I will RMA the card because I am 100% certain that it is faulty. They just missed the problem with their simple testing procedure.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...