TV stream stops every day at certain time, certain channel (3 Viewers)

[Cumpy Rules]

I've asked our developers today, he said that this should work.

Greetz CR

 

[mm1352000]

Thank you Cumpy Rules

I'll try to create a patch for Schaussi to test sometime in the next few days.

 

[mm1352000]

@Schaussi
The patch is attached. Please could you try it.

Installation instructions:

1. Open TV Server configuration.
2. Go to the "manual control" section.
3. Click "stop service".
4. Close TV Server configuration.
5. Open Windows/File Explorer.
6. Navigate to the TV Server install directory (default = c:\Program Files (x86)\Team MediaPortal\MediaPortal TV Server).
7. Take a backup of the TVLibrary.dll file.
8. Download and extract the attached TVLibrary.dll to replace the standard one.
9. Open TV Server configuration (click "yes" to start the TV service).

Test instructions:

1. Start a recording on any other encrypted channel at 6:50 PM.
2. Start a recording of the local news on ORF2O HD at 6:55 PM.
3. After the local news recording finishes, stop the other recording too.
4. Check whether both recordings are complete, and post your log files.

Thanks in advance.

P.S.
@HTPC_Sourcer and @Stéphane Lenclud
You may also be interested to test this patch if you remember the problem with Sky Cinema:
https://forum.team-mediaportal.com/threads/tv-missing-audio-stream-in-records-sky.123748/

It's the same issue again, in a different way.

 

[HTPCSourcer]

@HTPC_Sourcer and @Stéphane Lenclud
You may also be interested to test this patch if you remember the problem with Sky Cinema:
https://forum.team-mediaportal.com/threads/tv-missing-audio-stream-in-records-sky.123748/

I did not have problems anymore since I use a Deltacam. Also I can't decrypt ORF2 and can therefore not verify if it works. The only thing I could do is to see, if there is any regression.

 

[mm1352000]

I did not have problems anymore since I use a Deltacam.

Wow, that's interesting.
What CAM were you using in the past?
Would it be possible to capture some screenshots of the Deltacam settings? (I assume these are in the CA menu...)

[edit: I assume you no longer have the old CAM?]

Also I can't decrypt ORF2 and can therefore not verify if it works.

I understand. Was only wondering if you might be able to test the Sky Cinema issue.

The only thing I could do is to see, if there is any regression.

Sure. Regression is certainly a possibility, so it definitely makes sense to test for it. The biggest thing I'm concerned about is the effect on decryption for other channels. So for example...

1. Start recording encrypted channel A with tuner 1.
2. Start timeshifting/recording encrypted channel B with tuner 2.
3. Audio stream added/removed for channel B => PMT change.

...now, the questions are:

1. What happens to channel A?
2. What happens to channel B?

What we hope the answers should be are:

1. Nothing. No interruption of any kind... or maybe at worst a short interruption (less than 1 second).
2. The new audio stream becomes available and is decrypted properly.

I worry that the answer to the first question will actually be that decryption stops. This is what I thought DD said would happen in the past. Perhaps some improvements have been included in the driver since that time...

So, any testing you could do would be much appreciated.

 

[HTPCSourcer]

What CAM were you using in the past?

A Maxcam Twin 1.0, which I now replaced by a Deltacam Twin 2.0

Would it be possible to capture some screenshots of the Deltacam settings? (I assume these are in the CA menu...)

Sure. I will post them tonight or tomorrow.

I assume you no longer have the old CAM?

It's still lying on my desk and I see it every day

Regression is certainly a possibility, so it definitely makes sense to test for it.

I'll run some tests when I have a minute and the system is "idle", i.e. W not watching TV.

 

[HTPCSourcer]

Would it be possible to capture some screenshots of the Deltacam settings? (I assume these are in the CA menu...)

Not sure what exactly you are looking for. Python 1.72 has entries for the smartcard, the SIM and the CAM itself. The latter are

 

[HTPCSourcer]

Hi mm,

I started some testing. First step is to test the "blank", i.e verify the behavior with unpatched files and the most recent DD driver (2.6.1.118).

Start recording encrypted channel A with tuner 1.

1. Start timeshifting/recording encrypted channel B with tuner 2.
2. Audio stream added/removed for channel B => PMT change.

...now, the questions are:

1. What happens to channel A?
2. What happens to channel B?

Recording on channel A is "Expendables 3", recording on channel B is "Planet der Affen" - both started at 20:43.

@ +12min (ca. 20:55) channel B does an audio channel change, i.e. no longer on AC3, switching to standard stereo
@ +30min (ca. 21:13) channel B switches back to AC3

I verified the parallel recording of channel A and there is no interruption at all, not even a short one, around the indicated times and decryption continues. I will wait for your comments and further advice before moving on and replace the standard file with the patched one.

 

[mm1352000]

Thanks HTPC_Sourcer

Unfortunately I think this test does not actually check the behaviour due to the nature of the PMT changes.

"Planet der Affen - Revolution" starts with the following streams:
[collapse]
[2015-07-17 20:43:38,977] [Log ] [scheduler thread] [INFO ] - subch:0 pid:FF pcr
[2015-07-17 20:43:38,977] [Log ] [scheduler thread] [INFO ] - subch:0 pid:60 pmt
[2015-07-17 20:43:38,977] [Log ] [scheduler thread] [INFO ] - subch:0 pid:20 teletext type:6
[2015-07-17 20:43:38,977] [Log ] [scheduler thread] [INFO ] - subch:0 map pid:20 teletext type:6
[2015-07-17 20:43:38,977] [Log ] [scheduler thread] [INFO ] - subch:0 pid:30 type:5
[2015-07-17 20:43:38,977] [Log ] [scheduler thread] [INFO ] - subch:0 pid:FF video type:H.264
[2015-07-17 20:43:38,977] [Log ] [scheduler thread] [INFO ] - subch:0 map pid:FF video type:H.264
[2015-07-17 20:43:38,977] [Log ] [scheduler thread] [INFO ] - subch:0 pid:103 audio lang:deu type:AC3
[2015-07-17 20:43:38,977] [Log ] [scheduler thread] [INFO ] - subch:0 map pid:103 audio lang:deu type:AC3
[2015-07-17 20:43:38,977] [Log ] [scheduler thread] [INFO ] - subch:0 pid:104 audio lang:eng type:AC3
[2015-07-17 20:43:38,977] [Log ] [scheduler thread] [INFO ] - subch:0 map pid:104 audio lang:eng type:AC3
[/collapse]

At 20:55 we have the first change as you say:
[collapse]
[2015-07-17 20:55:46,120] [Log ] [26 ] [INFO ] - subch:0 pid:FF pcr
[2015-07-17 20:55:46,120] [Log ] [26 ] [INFO ] - subch:0 pid:60 pmt
[2015-07-17 20:55:46,120] [Log ] [26 ] [INFO ] - subch:0 pid:20 teletext type:6
[2015-07-17 20:55:46,120] [Log ] [26 ] [INFO ] - subch:0 map pid:20 teletext type:6
[2015-07-17 20:55:46,120] [Log ] [26 ] [INFO ] - subch:0 pid:30 type:5
[2015-07-17 20:55:46,120] [Log ] [26 ] [INFO ] - subch:0 pid:FF video type:H.264
[2015-07-17 20:55:46,120] [Log ] [26 ] [INFO ] - subch:0 map pid:FF video type:H.264
[2015-07-17 20:55:46,120] [Log ] [26 ] [INFO ] - subch:0 pid:103 audio lang:deu type:AC3
[2015-07-17 20:55:46,120] [Log ] [26 ] [INFO ] - subch:0 map pid:103 audio lang:deu type:AC3
[/collapse]

Note that the English AC3 audio is removed but the other streams remain the same. This scenario has never been a problem for DD. It is only when a new stream is added (or PID changes) that a problem occurs.

At 21:15 we have the second change exactly as you said:
[collapse]
[2015-07-17 21:15:16,033] [Log ] [26 ] [INFO ] - subch:0 pid:FF pcr
[2015-07-17 21:15:16,033] [Log ] [26 ] [INFO ] - subch:0 pid:60 pmt
[2015-07-17 21:15:16,033] [Log ] [26 ] [INFO ] - subch:0 pid:20 teletext type:6
[2015-07-17 21:15:16,033] [Log ] [26 ] [INFO ] - subch:0 map pid:20 teletext type:6
[2015-07-17 21:15:16,033] [Log ] [26 ] [INFO ] - subch:0 pid:30 type:5
[2015-07-17 21:15:16,033] [Log ] [26 ] [INFO ] - subch:0 pid:FF video type:H.264
[2015-07-17 21:15:16,033] [Log ] [26 ] [INFO ] - subch:0 map pid:FF video type:H.264
[2015-07-17 21:15:16,033] [Log ] [26 ] [INFO ] - subch:0 pid:103 audio lang:deu type:AC3
[2015-07-17 21:15:16,033] [Log ] [26 ] [INFO ] - subch:0 map pid:103 audio lang:deu type:AC3
[2015-07-17 21:15:16,033] [Log ] [26 ] [INFO ] - subch:0 pid:104 audio lang:eng type:AC3
[2015-07-17 21:15:16,033] [Log ] [26 ] [INFO ] - subch:0 map pid:104 audio lang:eng type:AC3
[/collapse]

This change reverses the previous change. In other words, the English AC3 stream is back using the same PID as before. I think since the CAM was previously configured to decrypt that stream, it would automatically start again even without any notification from TV Server. That means the DD driver doesn't have to handle this situation - it should just work.

So, as I said, I don't think this test captures the scenario that we need. You're close... but not quite. The scenario we need is to have [for example] the recording start at 21:00 when the English audio stream is missing, and then observe what happens to channel A and B at 21:15. I hope this makes sense, and please feel free to ask if anything is not clear.

Thanks again for taking the time to test.

 

[HTPCSourcer]

Ah, I see. No problem, next possibility tomorrow same time. There are just not that many broiadcasts with such patterns.