Opened 14 years ago

Closed 14 years ago

#1227 closed defect (fixed)

mythfrontend video output stops during livetv program changes with PVR350.

Reported by: mythtv.cvs@… Owned by: danielk
Priority: minor Milestone: 0.19
Component: mythtv Version: head
Severity: medium Keywords:
Cc: Ticket locked: no

Description

It is very rare now, compared to before, but occasionally the frontend does stop between TV shows. I've attached a mythfrontend -v all log, hopefully it will help a bit.

On a side note, sometimes the frontend stops responding to lirc or keyboard commands for pause, etc.. but keeps playing perfectly fine. Not sure if this is related, and I haven't been able to reproduce it yet with -v logging.

Attachments (3)

svn8873.5feb.mythfrontend.txt (22.0 KB) - added by anonymous 14 years ago.
mythtv.frontend.svn8884.6Feb.log (80.3 KB) - added by anonymous 14 years ago.
mythtv.frontend.svn8884.6Feb.extradebug.log (135.2 KB) - added by mythtv.cvs@… 14 years ago.
new log, with extra debugging enabled as requested…

Download all attachments as: .zip

Change History (16)

Changed 14 years ago by anonymous

comment:1 Changed 14 years ago by Isaac Richards

Summary: mythfrontend video output stops during livetv program changesmythfrontend video output stops during livetv program changes with PVR350.

comment:2 Changed 14 years ago by Isaac Richards

In this log, do you happen to remember what you were doing approx. when, seeking wise?

Also, if this happens again, does the following:

2006-02-05 20:32:04.919 RingBuf(/var/lib/mythtv//2363_20060205200003.mpg): Waited 2 seconds for data to become available...
2006-02-05 20:32:06.967 RingBuf(/var/lib/mythtv//2363_20060205200003.mpg): Waited 4 seconds for data to become available...
2006-02-05 20:32:11.064 RingBuf(/var/lib/mythtv//2363_20060205200003.mpg): Waited 8 seconds for data to become available...

sequence only seem happen for the bad transition, or for all?

comment:3 Changed 14 years ago by danielk

Milestone: 0.19
Owner: changed from Isaac Richards to danielk
Version: head

comment:4 Changed 14 years ago by danielk

It appears the long ignore key period is due to VideoOutputIvtv::ValidVideoFrames?() not being being implemented, which means we underestimate the number of buffered frames in NVP::IsReallyNearEnd?(). It also happens when there is a failed switch, because the keys are never un-ignored in that case.

The failed switching problem may be related as it appears to happen when the ivtv buffer completely empties before the switch. This happens when you are too close to the end when watching LiveTV (skipping back before the switch makes the switch succeed). When this happens ivtv appears to stop accepting more data and MythTV waits forever for it to resume playback.

comment:5 Changed 14 years ago by danielk

(In [8882]) References #1227. Adds debugging; changes prinf's to VERBOSE.

comment:6 Changed 14 years ago by danielk

(In [8883]) References #1227. Avoids false positives in EOF detection.

comment:7 Changed 14 years ago by danielk

(In [8884]) References #1227. Better approximation for ValidVideoFrames?.

This just returns the number of frames in the typical full vo buffer. In practice this means that NVP::IsReallyNearEnd?() uses only the RingBuffer? buffer fill and block size to detect the end of file when doing PVR-350 video output.

comment:8 Changed 14 years ago by mythtv.cvs@…

I recall watching LiveTV, and then trying to skip forward and back to get it to unfreeze. After I attempted this, I noticed the repetitive "2006-02-05 20:32:34.301 IVD: SeekReset?(825, 0, don't flush, do discard)" business in the logs. I am sorry I am not positive about anything else at the time.

I am compiling the latest SVN as of now, and will try to reproduce this again with better documentation for you...

comment:9 Changed 14 years ago by danielk

(In [8885]) References #1227. Special handling of pause, play & esc during ringbuffer switch.

Without the special handling or pause and play it is possible to pause the video just before a ringbuffer switch, and have it never complete because we are not playing the video. The esc handling just allows us to exit playback when something goes terribly wrong.

comment:10 Changed 14 years ago by mythtv.cvs@…

I started LiveTV, and did not touch any controls once it began. It ran until it froze, but I was able to unfreeze it afterwards by using ff/rew to do so. It seemed to work normally afterwards, although debugging information changed compared to before.

I've attached the logfile...

Changed 14 years ago by anonymous

Changed 14 years ago by mythtv.cvs@…

new log, with extra debugging enabled as requested...

comment:11 Changed 14 years ago by danielk

L8r, this appears to be where things go wrong:

2006-02-06 19:30:11.770 IVD: write0 !canwrite
2006-02-06 19:30:11.770 IVD: read3 cnt(0) rd(23552) wr(0) full(0) size(107520) ateof
2006-02-06 19:30:11.771 IVD: NVP::SetEof() at frame 311

The code probably needs a special case for when canwrite is not true.

comment:12 Changed 14 years ago by danielk

(In [8890]) References #1227.

Another fix for PVR-350 decoding. Issac did the coding for this, but asked me to apply it after testing. This is for the frozen input part of the problem reported in the ticket, the RingBuffer? readAhead was not being reset after a buffer switch completed so any subsequent buffer switches had the their ignore key mode turned on way too long.

This problem also may have applied to nuppelvideo decoded LiveTV; but there were no reports of this problem with nuppelvideo decoding.

comment:13 Changed 14 years ago by danielk

Resolution: fixed
Status: newclosed

(In [8893]) Fixes #1227.

  • This fixes the problem of ateof being set when the reason we couldn't

write data was because the ivtv video decoding buffer was full.

  • This also adds tracking of canwrite, so that if it is true for more than a second during regular playback, we reset playback. That should work around the driver bug where ivtv stops playback if it ever decodes the entire video decoding buffer, even if we immediately refill the buffer.

After the first fix, the canwrite tracking was never triggered for me with 20 second recordings. But you can trigger it if you stick some very short recordings into the livetv chain. This basically simulates the seeks L8r did to get out of the stuck playback with [8883].

Note: See TracTickets for help on using tickets.