search

h0tw1r3 / dvbhdhomerun

hdhomerun dvb driver for linux with working debian packaging!
GNU General Public License v2.0
30 stars 10 forks source link

HDHomerun seems to loose signal, but in reality it doesn't #3

Closed jeroen94704 closed 10 years ago

jeroen94704 commented 10 years ago

My HDHomerun (HDHDR3-EU, dual tuner) works fine for a little while after starting dvbhomerun-utils, and I can watch TV through tvheadend. However, after a while (anywhere from a few minutes to half an hour or so), the signal just seems to drop. Switching to another channel doesn't work, and tvheadend reports "no input detected". The moment this happens is clearly visible when running femon:

status SCVYL | signal  94% | snr   0% | ber 0 | unc 0 | FE_HAS_LOCK
status SCVYL | signal  94% | snr   0% | ber 0 | unc 0 | FE_HAS_LOCK
status SCVYL | signal  94% | snr   0% | ber 0 | unc 0 | FE_HAS_LOCK
status S     | signal   0% | snr   0% | ber 0 | unc 0 |
status S     | signal   0% | snr   0% | ber 0 | unc 0 |
status       | signal   0% | snr   0% | ber 0 | unc 0 |
status S     | signal   0% | snr   0% | ber 0 | unc 0 |

However, even after this, the QuickTV application for Windows provided by SolliconDust has no problem tuning into a channel, and will happily show me the program.

Also, restarting dvbhdhomerun-utils immediately resolves the problem, as shown again by femon:

status       | signal   0% | snr   0% | ber 0 | unc 0 |
status       | signal   0% | snr   0% | ber 0 | unc 0 |
status     L | signal  11% | snr   0% | ber 0 | unc 0 | FE_HAS_LOCK
status SCVYL | signal  94% | snr   0% | ber 0 | unc 0 | FE_HAS_LOCK
status SCVYL | signal  94% | snr   0% | ber 0 | unc 0 | FE_HAS_LOCK
status SCVYL | signal  94% | snr   0% | ber 0 | unc 0 | FE_HAS_LOCK

The dvbhdhomrun stderr log is empty, and the stdout log doesn't seem to have a telltale entry around the time the signal "drops".

Another weird thing I see is this kind of output from femon:

status SCVYL | signal   0% | snr   0% | ber 0 | unc 0 | FE_HAS_LOCK
status       | signal   0% | snr   0% | ber 0 | unc 0 |
status SCVYL | signal   0% | snr   0% | ber 0 | unc 0 | FE_HAS_LOCK
status       | signal   0% | snr   0% | ber 0 | unc 0 |
status SCVYL | signal   0% | snr   0% | ber 0 | unc 0 | FE_HAS_LOCK
status       | signal   0% | snr   0% | ber 0 | unc 0 |

Notice the alternating "FE_HAS_LOCK", and the signal at 0%. In this state, I can still watch TV without any problems. Not sure if this is related, but I'm just putting it out there under the premise "more data is better", when investigating a bug.

I realize this may not be the most appropriate place for this, but this is kind of my last-ditch attempt to figure this out, as I am out of tricks. I know you are not the original author of this driver, but it looks like the original project is kind of dead.

If there is anything I can to help debugging this issue (more/other logging), I'd be happy to do so.

jeroen94704 commented 10 years ago

Interesting development: It turns out TVHeadend introduced a new feature at some point called "Full MUX reception", which is on by default. Based on a vaguely related bug report on the original dvbhdhomerun trac page I went ahead and disabled this option. Lo and behold, the problem I described above has disappeared!

I'll keep monitoring things for a while, and if this persists, this issue can be closed.

jeroen94704 commented 10 years ago

Everything still working like a charm. Closing the issue.