Opened 18 years ago

Closed 18 years ago

#1872 closed defect (fixed)

Backend stops recording in middle of program

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

Description

Attached is a log for a USA DVB recording which should have run from 9:30 - 10:00. The log indicates the show is being recorded properly, but the file stops being written at 9:46. As well, there are a slew of "Writing PAT & PMT" messages in the log files until 9:46. After that time there are none of these messages.

This is on SVN 10005. If there is anything else useful let me know.

Attachments (5)

log.recstopped (56.8 KB) - added by anonymous 18 years ago.
RemovePID.log (12.8 KB) - added by anonymous 18 years ago.
Log showing early call to "RemovePIDFilter"
log.be.0602.060256.bz2 (42.1 KB) - added by anonymous 18 years ago.
Log of backend with _reset_pid_filters line commented
log.be.0701.124158.bz2 (73.5 KB) - added by cizek@… 18 years ago.
log.be.0705.150106.bz2 (112.1 KB) - added by cizek@… 18 years ago.

Download all attachments as: .zip

Change History (16)

Changed 18 years ago by anonymous

Attachment: log.recstopped added

comment:1 Changed 18 years ago by danielk

Milestone: 0.20
Version: head

comment:2 Changed 18 years ago by danielk

Can you comment out the line:

_reset_pid_filters |= _stream_data->HasEITPIDChanges(_eit_pids);

in DVBRecorder, and create a new '-v record' log, but without any of your other changes to the code.

comment:3 Changed 18 years ago by cizek@…

I'll make the change and post the log if it fails.

In the meantime, I found something that I believe is related to this. The last five times the recording failed, there is a log message saying "DVBSM(1)::RemovePIDFilter(0x1ffb)". This gets logged after the VCT & TVCT are seen, but before the MGT is seen. Is the MGT contained in 0x1ffb and are we filtering it out?

I've attached a log with the above condition. I'll post more when I can test the patch you suggested.

Changed 18 years ago by anonymous

Attachment: RemovePID.log added

Log showing early call to "RemovePIDFilter"

Changed 18 years ago by anonymous

Attachment: log.be.0602.060256.bz2 added

Log of backend with _reset_pid_filters line commented

comment:4 Changed 18 years ago by cizek@…

Attached is a log with the _reset_pid_filters line commented out. There were no "stopped in the middle" recordings, but there were total recording failures at 7:00, 9:30, 11:00 & 14:00. Let me know if there's anything else the I can do.

comment:5 Changed 18 years ago by cizek@…

Updated from dev list. The below condition is shown in the attachment "RemovePID.log"

Today I was just playing with svn 10180 and got a similar result:

  • If MythTV receives the MGT and then the VCT the recording works fine.
  • If the VCT arrives before the MGT, the recording logic waits forever for the MGT. I've looked at the raw stream and the MGT is there, but it seems like MythTV is either ignoring it or filtering it out.

comment:6 Changed 18 years ago by danielk

Cizek, I can't reproduce the RemovePID behavior. I've tried both disabling MGT processing altogether, and I've tried disabling just MGT matching.

Also, you are using a modified version of MythTV.

Can you reproduce the logs with SVN head without ANY modifications to MythTV using "-v channel,record,siparser"

Changed 18 years ago by cizek@…

Attachment: log.be.0701.124158.bz2 added

comment:7 Changed 18 years ago by cizek@…

Attached is a log with the above issue using vanilla svn 10356 -- none of my patches.

The recording that failed is "House of Payne - No Place Like Home" at 12:57, and from a quick look at the log it was the same scenario as above. The recording shows up in mythtv but the file is not created. This only happens occasionally -- other programs on the same channel record ok, and programs on other channels fail as well.

FWIW: libs/libmythtv/dvbsignalmonitor.cpp has the following comment at line 203:

// TODO as is this will break for ATSC streams, where the
// MGT is on pid 0x1ffb and the VCTs can be on any pid like
// PMTs, but is usually on 0x1ffb.

I don't know if this is related or not, but this looks suspicious. If there's anything else I can provide, or patches to test, let me know.

Thanks

comment:8 Changed 18 years ago by danielk

Cizek, can you try the patch on #2006 and report back with the logs I requested there?

I believe this may be the same problem as #1981 and #2006.

Changed 18 years ago by cizek@…

Attachment: log.be.0705.150106.bz2 added

comment:9 Changed 18 years ago by anonymous

Attached log file "log.be.0705.150106.bz2". The recording "The King of Queens" at 21:57 failed. This was run with the patch from 2006.

comment:10 Changed 18 years ago by danielk

Cizek, it looks like you have a different problem.

These are probably the key parts:

2006-07-05 21:57:32.296 SM(1)::AddFlags: Seen() Match() Wait(MGT,)
2006-07-05 21:57:32.863 SM(1)::AddFlags: Seen() Match(VCT,TVCT,) Wait()
2006-07-05 21:57:32.868 DVBSM(1)::RemovePIDFilter(0x1ffb): 

It looks like we require the MGT, but then remove that PID from the list of PIDs we're listening to. I don't know why the MGT is needed, the MGT should only be required the first time we tune to a channel.

But I think I know why the filter is being deleted. HandleTVCT() and HandleCVTC() both call DTVSignalMonitor::SetProgramNumber?(). This in turn calls MPEGStreamData::SetProgramNumber?(), which under some circumstances calls MPEGStreamData::Reset(). And the reset clears out the Listening PIDs..

I'll fix this..

comment:11 Changed 18 years ago by danielk

Resolution: fixed
Status: newclosed

(In [10437]) Fixes #1872. Fixes a tuning problem that caused failed tuning under some circumstances.

An overzealous MPEGStreamData::Reset() was removing the ATSC PSIP PID from the list of PIDs we were listening to if we got a VCT table before we got a PAT table. When we had also not gotten an MGT table and this was a channel we had never gotten an MGT on before, then we would never get a lock without switching to another channel on the same transport and then switching back to the problem channel.

Note: See TracTickets for help on using tickets.