Opened 14 years ago

Closed 14 years ago

#804 closed defect (fixed)

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

Reported by: John Pullan <john.pullan@…> Owned by: danielk
Priority: minor Milestone: unknown
Component: mythtv Version:
Severity: medium Keywords: DVB signal monitor
Cc: bolek-mythtv@… Ticket locked: no

Description

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.

Attachments (2)

backend.log.gz (99.4 KB) - added by John Pullan <john.pullan@…> 14 years ago.
frontend.log.gz (61.4 KB) - added by John Pullan <john.pullan@…> 14 years ago.

Download all attachments as: .zip

Change History (11)

Changed 14 years ago by John Pullan <john.pullan@…>

Attachment: backend.log.gz added

comment:1 Changed 14 years ago by danielk

Resolution: worksforme
Status: newclosed

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.

Changed 14 years ago by John Pullan <john.pullan@…>

Attachment: frontend.log.gz added

comment:2 Changed 14 years ago by John Pullan <john.pullan@…>

Resolution: worksforme
Status: closedreopened

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

comment:3 Changed 14 years ago by bolek-mythtv@…

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

comment:4 Changed 14 years ago by bolek-mythtv@…

Cc: bolek-mythtv@… added

comment:5 Changed 14 years ago by 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.

comment:6 Changed 14 years ago by 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 :)

comment:7 Changed 14 years ago by danielk

Milestone: 0.19
Version: head

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?

comment:8 Changed 14 years ago by John Pullan <john.pullan@…>

Milestone: 0.19
Version: head

Daniel, Correct. John

comment:9 Changed 14 years ago by danielk

Resolution: fixed
Status: reopenedclosed

Closed by [8274]

Note: See TracTickets for help on using tickets.