Adjust PAT/PMT

[jirim100]

Good day,

 

when is enabled "Adjust PAT/PMT" and in recording log is "Channel update tcPMT tcVideo tcAudio tcVideotext tcPCR" then PAT/PMT is in ts file wrong. Log of recording:

 

CT 2 26.6.2016
W:\For The Record\2016-06-26 (2009); Život na Zemi Primáti.ts
Device: TERRATEC T5 Rev.2 Tuner 1 (7)
EventID: 4768
Timer Name: Život na Zemi: Primáti
Timer Start: 26.6.2016 17:05:00
Timer Duration: 1:30:00 (90 min. incl. 20 min. lead time, 20 min. follow-up time)
Timer Options: Teletext=1, DVB Subtitles=1, All Audio Tracks=1, Adjust PAT/PMT=1, EIT EPG Data=1, Transponder Dump=0
Timer Source: Search:Život na zemi

17:05:02 / 0:00:00 (~ 0,00 MB) Start Recording
17:05:02 Channel update tcPMT tcVideo tcAudio tcVideotext tcPCR
17:05:03 / 0:00:01 (~ 0,00 MB) Život na Zemi: Primáti not running | EventID: 4768 PDC: 0x00000
17:05:04 / 0:00:01 (~ 0,98 MB) PID 1365: MPEG Audio Stereo, 48 khz, 192 kbps
17:05:04 / 0:00:01 (~ 0,98 MB) PID 1366: MPEG Audio Mono, 48 khz, 64 kbps
17:05:04 / 0:00:01 (~ 0,98 MB) PID 1364: MPEG2 Video, 16:9, 720x576, 25 fps
17:05:05 / 0:00:02 (~ 1,55 MB) Až na kraj světa: Poslední stopa Butche a Sundance running | EventID: 4769 PDC: 0x00000
17:24:58 / 0:19:56 (~ 616,88 MB) Život na Zemi: Primáti running | EventID: 4768 PDC: 0x00000
17:25:00 / 0:19:57 (~ 617,65 MB) Krajinou domova (8. díl) not running | EventID: 4767 PDC: 0x00000
18:14:58 / 1:09:56 (~ 2075,09 MB) Krajinou domova (8. díl) running | EventID: 4767 PDC: 0x00000
18:15:00 / 1:09:58 (~ 2075,70 MB) Večerníček not running | EventID: 4766 PDC: 0x00000
18:35:00 / 1:29:58 (~ 2664,52 MB) Stop

Average Data Rate: 0,494 MB/s
Total Size: 2664,5 MB (2793952788 Bytes)
--------------------------------------------------------------------------

 

First 100 MB of recording (raw cutted with TS Doctor) you can download from here:

https://ulozto.cz/!p2MaQCKVd/new-cutted-ts

 

 

[jirim100]

Even when "Adjust PAT/PMT" is disabled, when is in log "Channel update XXX" then is something wrong in PAT/PMT.

 

Log file:

CT / CT 27.6.2016
W:\For The Record\aaa; nahráno 2016-06-27.ts
Device: TERRATEC T5 Rev.2 Tuner 1 (7)
Timer Name: aaa
Timer Start: 27.6.2016 13:28:00
Timer Duration: 0:30:00 (30 min.)
Timer Options: Teletext=1, DVB Subtitles=1, All Audio Tracks=1, Adjust PAT/PMT=0, EIT EPG Data=1, Transponder Dump=0
Timer Source: Web

13:28:38 / 0:00:00 (~ 0,00 MB) Start Recording
13:28:38 Channel update tcPMT tcVideo tcAudio tcVideotext tcPCR
13:28:39 / 0:00:01 (~ 0,26 MB) PID 1377: MPEG Audio Stereo, 48 khz, 192 kbps
13:28:39 / 0:00:01 (~ 0,26 MB) PID 1378: MPEG Audio Mono, 48 khz, 64 kbps
13:28:39 / 0:00:01 (~ 0,26 MB) PID 1376: MPEG2 Video, 16:9, 720x576, 25 fps
13:31:40 / 0:03:01 (~ 51,47 MB) Stop

Average Data Rate: 0,283 MB/s
Total Size: 51,5 MB (53972732 Bytes)

------------

And complete recording you can download from here https://ulozto.cz/!EGvniRuEG/nove4-ts

[Griga]

The PMT isn't wrong in your files. It's missing completely.

 

This is a known bug in DVBViewer Pro 5.6.2. But your logs have obviously been created by the Recording Service 1.33, where it is fixed. I have tried to reproduce the issue, but here it works. So I don't know where to look for the cause.

 

Anyway, channel data changes are difficult to handle in ongoing recordings, so you may want to try Service Options -> Recorder -> Auto spilt on channel data change. It let's the Recording Service start a new recording with the corrected channel data. Or even better: Update the channel in the channel list that is used by the Recording Service, so there is no need to correct it on the fly.

[jirim100]

But why PMT missing even when Adjust PAT/PMT=0 ?

 

I don't want enable "Auto split on channel data change". It not suits me.

 

My tv provider very often change IDs in transport stream, therefore it would be good to work it successfully in recording service.

 

You can simulate it: change in channel editor in DVBViewer Pro PID identifiers to bad values, then restart recording service and then start recording. Recording service then try correcting PID identifiers (in log will be "Channel update XXX").

[Griga]

But why PMT missing even when Adjust PAT/PMT=0 ?

 

Most likely because the PMT PID in the channel list is wrong. However, it should be corrected and recorded in RS 1.33. That's what happens here.

 

You can simulate it: change in channel editor in DVBViewer Pro PID identifiers to bad values

 

That's what I've done. I've set all PIDs of the recorded channel to 0, then in a second test the PMT PID to a wrong value > 0.

 

I just found a bug in this part of the code (and fixed it, of course). However, as far as I can see it only affects logging. Dunno if it can cause other side effects. I will continue my researches later and report the results here, if there are any...

[Griga]

It would be interesting to compare the wrong channel data (as uses by the RS for recording) with corrected data. Proceed as follows:

 

- Launch DVBViewer on the PC where the RS is installed. Take care that it does not tune the channel in question yet.

- Go to the channel list editor, select the channel and export it as ini file.

- Now tune the channel. The DVBViewer channel auto update should correct the channel data. Then export it again as ini file.

- Attach both files here.

[jirim100]

I did as you advised mi, here are the ini files, both contain affected channels "CT 2" and "CT / CT"

 

In both channels was changed PMTPID, VPID, APID, PCRPID, TelePID.

CT_channels_before_update.ini

CT_channels_after_update.ini

Edited June 27, 2016 by jirim100

[Griga]

Got it!

 

before update: PMTPID=1373, VPID=1368, APID=1369, PCRPID=1368, TelePID=1371

after update: PMTPID=1369, VPID=1364, APID=1365, PCRPID=1364, TelePID=1367

 

The RS didn't record the PMT because the PID was already registered as audio stream. In technical terms: It was directed to the wrong callback. Correcting such a wrong setup requires a recording restart, or with other words, auto split on channel data change.

 

Please note that before RS 1.33 auto-correction without a recording restart was not considered at all. In 1.33 I've changed it so at least some cases can be handled successfully. If PIDs turn out to be missing, the recorder adds them to its collection, hoping that it will yield a useful result. But without a restart it does not remove or redirect PIDs that are already allocated. In short: It is not expectable that the recorder can cope with all issues resulting from wrong channel data.

 

Maybe there will be some solution for cases like yours in future, but at the moment I see no possibility for a short-term fix.