Opened 18 years ago
Closed 18 years ago
#1227 closed defect (fixed)
mythfrontend video output stops during livetv program changes with PVR350.
Reported by: | 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)
Change History (16)
Changed 18 years ago by
Attachment: | svn8873.5feb.mythfrontend.txt added |
---|
comment:1 Changed 18 years ago by
Summary: | mythfrontend video output stops during livetv program changes → mythfrontend video output stops during livetv program changes with PVR350. |
---|
comment:2 Changed 18 years ago by
comment:3 Changed 18 years ago by
Milestone: | → 0.19 |
---|---|
Owner: | changed from Isaac Richards to danielk |
Version: | → head |
comment:4 Changed 18 years ago by
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 18 years ago by
comment:6 Changed 18 years ago by
comment:7 Changed 18 years ago by
(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 18 years ago by
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 18 years ago by
(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 18 years ago by
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 18 years ago by
Attachment: | mythtv.frontend.svn8884.6Feb.log added |
---|
Changed 18 years ago by
Attachment: | mythtv.frontend.svn8884.6Feb.extradebug.log added |
---|
new log, with extra debugging enabled as requested...
comment:11 Changed 18 years ago by
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 18 years ago by
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 18 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
- 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].
In this log, do you happen to remember what you were doing approx. when, seeking wise?
Also, if this happens again, does the following:
sequence only seem happen for the bad transition, or for all?