[Bug] TV: missing audio stream in records (Sky) (1 Viewer)

[Zoidberg77]

Could somebody please be so kind as to upload the first 50 MB of a "failed" recording to our FTP server?

I can do that, just tell me where to upload...

 

[mm1352000]

I can do that, just tell me where to upload...

Connection details are at the bottom of this page in the wiki:
http://wiki.team-mediaportal.com/1_MEDIAPORTAL_1/18_Contribute/4_Development/Debugging/TS_Dumps

 

[Zoidberg77]

upload the first 50 MB of a "failed" recording

done
edit: If it helps I could also provide you the part where the new PMT pops up...

 

[mm1352000]

Thanks everyone

Attached is a replacement TV library which might help with the problem if you're using the-plugin-which-shall-not-be-named ( ). There seems to be a genuine bug when the plugin is used: updated PMT is not passed to the plugin (!!!) so it probably has no way to know that it needs to start decrypting the new audio stream.

https://github.com/MediaPortal/Medi...rary/Implementations/DVB/Graphs/MDPlug.cs#L53

 if (!isChannelAlreadyDecoding)
 {
   SetChannel(currentChannel, channelInfo, update);
 }

...changed to:

 if (!isChannelAlreadyDecoding || update)
 {
   SetChannel(currentChannel, channelInfo, update);
 }

mm
PS: I hope from my response you can see that we are sensible about providing support for the plugin when there is a bug. My point is: please in future don't hesitate to post a bug report. I will tell you at the time whether logs without the plugin are required. Each report is taken on a case-by-case basis.
PPS: This patch is for MP 1.6. Please don't ask for patches for MP 1.5. I also make no commitment about providing updates. Finally, since TVE 3 is in code freeze, I also make no commitment about getting this change into future versions of MP.
PPPS: This patch won't help for people using DD CIs with a CAM. Still can't see anything wrong with that scenario...

 

[HTPCSourcer]

mm,

Thx, but I am not using any (in)famous plugins of this kind. I have a standard CI/CAM setup as addressed in your PPPS. Hence I wonder why I have observed similar issues. Did my log contain anything of interest?

 

[mm1352000]

Thx, but I am not using any (in)famous plugins of this kind. I have a standard CI/CAM setup as addressed in your PPPS.

I know... but @Zoidberg77 is, and other people may be also.

Hence I wonder why I have observed similar issues.

Me too.

Did my log contain anything of interest?

It looked the same as the logs from @Brette provided on the first page. As per my PPS, I can't see why the stream is not decrypted.
From here I think what we can do is:
1. Wait and see whether the patch solves the problem for people using the plugin. Then we at least know that TV Server has the ability to successfully perform these recordings, and that the reason for failure with a DD tuner + CI + CAM must be something to do with the DD driver, CI or CAM (or the corresponding code).
2. As mentioned previously, logs showing a successful recording (ie. short pre-record) with the DD tuner + CI would be helpful for analysis. If I can compare what happens in the success and failure cases then any differences might lead to finding the cause.
3. The recording segment provided by Zoidberg was too short to show the change in PMT (sorry, my fault for thinking 50 MB would be enough ). A longer failed recording showing the PMT changes would be helpful.

 

[mm1352000]

@HTPC_Sourcer
Maybe you could try the attached patch for MP 1.6. I've assumed that the problem is that the DD driver ignores the decrypt request because it thinks the channel is already being decrypted. To attempt to solve the problem, I send a "fake" decrypt request when this situation is detected.

mm
[edit: Made a mistake. Patch updated. Sorry for any inconvenience.]
[edit2: <sigh> another mistake. Really sorry! I must be tired - will go to bed early tonight. Third time for the win!]

 

[HTPCSourcer]

I am wondering if you ever sleep

But seriously, I did a recording this morning a 7:43-8:19 that includes ads between two movies on Sky. THis time I did not wach any other chanel in parallel. The recording is fully OK, no issues with 2nd audio stream, but I don't know if any PMT change took actually place. Maybe the issue is linked to the CAM. This would also explain why I never experienced the problem so far since I usually record Sky movies during the night or at times when nobody watches TV.

How can we track this down now? I would prefer to identify conditions where the second stream is never decrypted before testing your patch. Otherwise there is no way to tell if there really was a problem that has been solved.

 

[mm1352000]

I am wondering if you ever sleep

Heh, yes - sometimes it feels like I never sleep.

But seriously, I did a recording this morning a 7:43-8:19 that includes ads between two movies on Sky. THis time I did not wach any other chanel in parallel. The recording is fully OK, no issues with 2nd audio stream, but I don't know if any PMT change took actually place.

There were no PMT changes, and both audio streams were present when the recording started. I think that is probably why it succeeded.

[2014-01-05 07:43:11,185] [Log ] [scheduler thread] [DEBUG] - Digital Devices:--> Setting service id 131 for decrypting returned 0
[2014-01-05 07:43:11,186] [Log ] [scheduler thread] [INFO ] - subch:0 cam flags:True
[2014-01-05 07:43:11,191] [Log ] [scheduler thread] [INFO ] - subch:0 SetMpegPidMapping
[2014-01-05 07:43:11,191] [Log ] [scheduler thread] [INFO ] - subch:0 pid:4FF pcr
[2014-01-05 07:43:11,191] [Log ] [scheduler thread] [INFO ] - subch:0 pid:64 pmt
[2014-01-05 07:43:11,193] [Log ] [scheduler thread] [INFO ] - subch:0 pid:20 teletext type:6
[2014-01-05 07:43:11,193] [Log ] [scheduler thread] [INFO ] - subch:0 map pid:20 teletext type:6
[2014-01-05 07:43:11,193] [Log ] [scheduler thread] [INFO ] - subch:0 pid:4FF video type:H.264
[2014-01-05 07:43:11,193] [Log ] [scheduler thread] [INFO ] - subch:0 map pid:4FF video type:H.264
[2014-01-05 07:43:11,194] [Log ] [scheduler thread] [INFO ] - subch:0 pid:503 audio lang:deu type:AC3
[2014-01-05 07:43:11,194] [Log ] [scheduler thread] [INFO ] - subch:0 map pid:503 audio lang:deu type:AC3
[2014-01-05 07:43:11,194] [Log ] [scheduler thread] [INFO ] - subch:0 pid:504 audio lang:eng type:AC3
[2014-01-05 07:43:11,194] [Log ] [scheduler thread] [INFO ] - subch:0 map pid:504 audio lang:eng type:AC3

Maybe the issue is linked to the CAM. This would also explain why I never experienced the problem so far since I usually record Sky movies during the night or at times when nobody watches TV.

Maybe. Every test you can think of to narrow the problem would be helpful. Currently we only know that the pre-record time makes a difference...

How can we track this down now? I would prefer to identify conditions where the second stream is never decrypted before testing your patch. Otherwise there is no way to tell if there really was a problem that has been solved.

Yes, it would be nice to have a method to reproduce, apply the patch and see the problem go away.
As mentioned above, if I've understood the reports correctly I think currently the long pre-record is the only way we have to reliably reproduce the problem. The reason using a long pre-record would trigger the problem is that it allows the recording to include audio stream changes.

The process we can use to track down the problem starts with the 3 points in my earlier post ("From here I think what we can do is..."). Once we understand the cause of the problem we can understand how to solve it.

mm

 

[HTPCSourcer]

Ok, first thing to do will then be a recording of a "zapping" or "Making of" preceding a regular movie. Unfortunately these are not often broadcasted, so this may take some time.