TV Server freeze when changing channel (1 Viewer)

[georgius]

MediaPortal Version: 1.2.2
MediaPortal Skin: StreamedMP
Windows Version: Windows 7 Ultimate 32-bit SP1
CPU Type: Intel Core i5 2500K
HDD: 2x WD WD3200YS, 320 GB
Memory: 2x 2048 MB
Motherboard: Gigabyte GA-H61M-USB3-B3
Video Card: Intel HD Graphics 3000
Video Card Driver: 8.15.10.2559
Sound Card: Realtek, HDA
Sound Card AC3:
Sound Card Driver: 6.1.7600.16385, Microsoft
1. TV Card:
1. TV Card Type: DVB-IP
1. TV Card Driver:
2. TV Card:
2. TV Card Type:
2. TV Card Driver:
3. TV Card:
3. TV Card Type:
3. TV Card Driver:
4. TV Card:
4. TV Card Type:
4. TV Card Driver:
MPEG2 Video Codec: LAV Video Decoder
MPEG2 Audio Codec: ffdshow Audio Decoder
h.264 Video Codec: ffdshow DXVA Video Decoder
Satelite/CableTV Provider:
HTPC Case:
Cooling:
Power Supply:
Remote:
TV:
TV - HTPC Connection:

Hi,

I found serious bug in TV server which cause MP and TV server freeze, so both must be killed in Task Manager. This bug happend during channel change (or similar action like starting playing, starting recording, etc.). The logs are attached, problem happend at 2012-01-22 12:13:03.

I investigate the problem and probably found its cause. The problem is classic deadlock between channel (TvDvbChannel.cs) and TsWriter. Look at the end of tv server log file:

2012-01-22 12:13:03.321396 [(21)]: WaitForPMT: Waiting for PMT 20
2012-01-22 12:13:03.521407 [(9)]: subch:0 OnPMTReceived() pmt:20 ran:True dynamic:False
2012-01-22 12:13:03.523408 [(21)]: WaitForPMT: Found PMT after 0,2050117 seconds.
2012-01-22 12:13:03.525408 [(21)]: subch:0 SendPmt:CA found after 0 seconds
2012-01-22 12:13:03.528408 [(9)]: subch:OnCaReceived()
2012-01-22 12:13:03.542409 [(9)]: subch:0 OnPMTReceived() pmt:20 ran:True dynamic:True

The important line is this with 'CA found after 0 seconds'. It means that tv server code is in 'SendPmtToCam' method. Because in relevant part of log file is no line similar to 'subch:0 SendPmt:1 1 FFFFFFFF A', it means that tv server code is before line (in another case we would find another message in log)

Log.Log.Info("subch:{0} SendPmt:{1:X} {2:X} {3:X} {4:X}", _subChannelId, pmtProgramNumber, channel.ServiceId, _pmtVersion, version);

I think that only line which can cause freeze between messages mentioned above is

_pmtLength = _tsFilterInterface.PmtGetPMTData(_subChannelIndex, pmtMem);

If you look on shown part of log you can see that OnPMTReceived() is called twice. From TsWriter log we found

22-01-2012 12:13:03.539 pmtgrabber: got new pmt version:6 a, service_id:1
22-01-2012 12:13:03.540 pmtgrabber: do callback pid 20

that new PMT arrived, so TsWriter called callback and TsWriter is in critical section while calling callback. Because PmtGetPMTData() calls CPmtGrabber::GetPMTData() method, which tries to enter to critical section, we got classic deadlock. In attachements is sample TS file which demonstrate problem.

I prepared patch, but I'm not sure if I solved problem correctly (at least for me worked). The main idea of patch is to remove signaling of requested PMT from OnPMTReceived() callback to WaitForPMT() method (in this case the meaning of _pmtRequested variable is that WaitForPMT() method finished processing PMT). Possible problem with this patch is that any update of PMT will be stored into database, but tv server code may ignore update of PMT.

P.S. While investigating problem I also found that _eventCA event is never reset (that's why CA is found after 0 seconds).

 

[georgius]

@mm1352000, @gibman - will be this issue fixed in MP 1.3.0 or later?

 

[mm1352000]

Hi georgius

Sorry, I don't recall seeing this thread until now.
So to be clear, you have really only done two things:
1. Comment out "_pmtRequested = false;" in OnPMTReceived().
2. Wrap try-finally around the PMT processing and set _pmtRequested at the end.

Is that correct - I ask because the patch makes it hard to see exactly what has changed.

You can see that I reported an almost identical issue -->here<-- last year. In your case the SID and PMT PID are the same for the old and new channels, just like the symptoms I described.

The patch that I attached to the mantis is a one line fix, although your patch seems a little more robust (?).
I would have no problem with you adding your fix to MP 1.3b. Please create a branch for the issue that I reported and commit and merge your patch to master so that it can get as much testing as possible.

Thanks,
mm

 

[mm1352000]

Hi again georgius

I guess you're either away or missed my response. No problem - I will commit, merge and deal with mantis this evening if you don't do it before then...

mm

 

[mm1352000]

Branch created, merged to master, issue marked as fixed in MP 1.3b and closed. Thanks georgius