DVB signal monitor, signal level OSD (race condition ?)

[John Pullan <john.pullan@…>]

I keep getting the "you should have a signal lock" OSD dialog appear when I'm changing channel in LiveTV.

It's quite hard to reproduce with debug logging on, easy otherwise. I had to alter the logging to be the released version. The attached logs are for :

mythfrontend -v playback,record,general,siparser

mythbackend -v general,record,channel,siparser

The last channel change is when it breaks.

[danielk]

Got a message from John that he couldn't reproduce. It may have just been a fluke, but if anyone experiences something similar, reopen this ticket.

[John Pullan <john.pullan@…>]

I'm afraid it's quite reproducible on my system. (I had logging on when I tried again so it appeared to work)

[bolek-mythtv@…]

I am experiencing this as well. Interestingly, it doesn't happen when I first enter Live TV, only after changing channels.

[nooneimprt4nt@…]

I can easily reproduce this as well using DVB-S. In fact in my case, it is worse, in that it often takes more than 4 retries before the frontend is able to read data when switching channels, so I get something that looks like:

2005-12-13 22:12:37.003 Invalid file handle when opening /var/lib/mythtv/1110_20051213221236.mpg.  4 retries remaining.
2005-12-13 22:12:37.505 Invalid file handle when opening /var/lib/mythtv/1110_20051213221236.mpg.  3 retries remaining.
2005-12-13 22:12:37.580 NVP: Prebuffer wait timed out 10 times.
2005-12-13 22:12:38.007 Invalid file handle when opening /var/lib/mythtv/1110_20051213221236.mpg.  2 retries remaining.
2005-12-13 22:12:38.400 NVP: Prebuffer wait timed out 10 times.
2005-12-13 22:12:38.512 Invalid file handle when opening /var/lib/mythtv/1110_20051213221236.mpg.  1 retries remaining.
2005-12-13 22:12:39.013 Invalid file handle when opening /var/lib/mythtv/1110_20051213221236.mpg.  0 retries remaining.
2005-12-13 22:12:39.224 NVP: Prebuffer wait timed out 10 times.
2005-12-13 22:12:39.518 RingBuf(/var/lib/mythtv/1110_20051213221236.mpg) Error: File I/O problem in 'safe_read()'
    eno: Bad file descriptor (9)
2005-12-13 22:12:39.580 RingBuf(/var/lib/mythtv/1110_20051213221236.mpg) Error: File I/O problem in 'safe_read()'
    eno: Bad file descriptor (9)
2005-12-13 22:12:39.642 RingBuf(/var/lib/mythtv/1110_20051213221236.mpg) Error: File I/O problem in 'safe_read()'
    eno: Bad file descriptor (9)
2005-12-13 22:12:39.644 RingBuf(/var/lib/mythtv/1110_20051213221236.mpg) Error: File I/O problem in 'safe_read()'
    eno: Bad file descriptor (9)
2005-12-13 22:12:39.706 RingBuf(/var/lib/mythtv/1110_20051213221236.mpg) Error: File I/O problem in 'safe_read()'
    eno: Bad file descriptor (9)
2005-12-13 22:12:39.768 RingBuf(/var/lib/mythtv/1110_20051213221236.mpg) Error: File I/O problem in 'safe_read()'
    eno: Bad file descriptor (9)
2005-12-13 22:12:40.044 NVP: Prebuffer wait timed out 10 times.
2005-12-13 22:12:40.864 NVP: Prebuffer wait timed out 10 times.
2005-12-13 22:12:41.685 NVP: Prebuffer wait timed out 10 times.
2005-12-13 22:12:42.507 NVP: Prebuffer wait timed out 10 times.
2005-12-13 22:12:43.327 NVP: Prebuffer wait timed out 10 times.
...

At which point I need to restart the frontend to continue.

Changing the default number of retries to 20 in RingBuffer?.h fixes that problem, but I still get the 'you should have a signal lock' message whenever it takes more than a couple retries.

[John Pullan <john.pullan@…>]

Applying the patch from #743 seems to help a lot. Although it isn't a cure all it does help. I'm guessing this might provide a clue :)

[danielk]

nooneimprt4nt, I believe you are experiencing a different problem; we don't wait for
the recorder to begin writing data before setting the ringbuffer ready flag, so if
it takes longer than the timeout on the ringbuffer reads, things go badly. You should open a seperate ticket on that problem.

It looks as everyone else's problem has something to do with the program number not being set at the right time, or to the right value, or the signal monitor not realizing when it has the right PMT if it isn't the first PMT it sees. If so, #812 may be a duplicate of this. I'm going to look at #689 again, then I'll look at fixing this problem.

John, am I right in assuming you are also only seeing this on channel changes; never on the initial channel?

[John Pullan <john.pullan@…>]

Daniel,
Correct.
John

[danielk]

Closed by [8274]