dropouts when watching hd tv (1 Viewer)

[The_Stig]

@HomeY, did you now change anything in registry (except the bufferloggin) and do you have that registry entry?

 

[HomeY]

Only thing i changed was enabling the BufferLogging.

 

[Owlsroost]

@Owlsroost, from your point of view, what would be the best registry setting when having micro-stutter on recordings?

EDIT: Attached a log when watching a recording and microstutter occured. But I am not quite sure currently, which experimental TSreader version it was. Currently installed your 84_7c (and enabled Bufferloggin) and will try this evening again.

EDIT 2: doesn't the 84_7c have the registry value 'EnableAutoSpeedAdjust' ?

There is nothing unusual in the TsReader log, the evr.log might be more informative....

What do you mean by 'micro-stutter' ?

 

[The_Stig]

What do you mean by 'micro-stutter' ?

An example: best described with a landscape and a slow movement over the landscape. Micro-stutter now is a short stop in that movement about every second for a very short time.

Buuuuut: Testet the 84_7c on the same recording yesterday and all went perfect! I deleted the old reg-entries of the older TSReader to not mess up the settings. Pictures was without stutter and AV-Sync was pretty fine. Great work!

 

[HomeY]

@Owlsroost i'm running into issues after upgrading my CAM FW (AlphaCrypt Classic running FW v3.28), so this might be the cause.
The reason i'm posting here is that everything works fine in 75% of the tunes, but 25% result in a black screen. Audio is running fine then, system isn't frozen, just a black screen. Zapping

I'm under the impression that the problem is related to decryption, since i haven't been able to reproduce the issue on FTA channels. I did have 1 'zap' from FTA to FTA channel that wouldn't tune (long list of PES errors in TsReader log, similar to the onces in Log_BlackScreen+Audio.zip), so i cancelled that tune.
The Timeshift files created on my server play fine in MPC-HC, Video + Audio.

Could you take a peak at the attached logs (Log_BlackScreen+Audio.zip) and tell me if you see something strange going on?
The 'Log_Perfect.zip' is a succesful tune. I stopped the 'black screen' stream, deleted the logs and then tuned the same channel (which went fine).

I was on FW v3.25 before and i recall having similar issues with the 3.27 FW, so rolled back at that time, but the fact that it works more often than not, makes me wonder if it could be related to TsReader (or something else?).

TNX in advance

 

[Owlsroost]

@Owlsroost i'm running into issues after upgrading my CAM FW (AlphaCrypt Classic running FW v3.28), so this might be the cause.
The reason i'm posting here is that everything works fine in 75% of the tunes, but 25% result in a black screen. Audio is running fine then, system isn't frozen, just a black screen. Zapping

I'm under the impression that the problem is related to decryption, since i haven't been able to reproduce the issue on FTA channels. I did have 1 'zap' from FTA to FTA channel that wouldn't tune (long list of PES errors in TsReader log, similar to the onces in Log_BlackScreen+Audio.zip), so i cancelled that tune.
The Timeshift files created on my server play fine in MPC-HC, Video + Audio.

Could you take a peak at the attached logs (Log_BlackScreen+Audio.zip) and tell me if you see something strange going on?
The 'Log_Perfect.zip' is a succesful tune. I stopped the 'black screen' stream, deleted the logs and then tuned the same channel (which went fine).

I was on FW v3.25 before and i recall having similar issues with the 3.27 FW, so rolled back at that time, but the fact that it works more often than not, makes me wonder if it could be related to TsReader (or something else?).

TNX in advance

You have more than 25s of this in TsReader log:

[2014-12-17 17:58:26,499] [1cc30048] [1114] - PES audio 0-0-1 fail
[2014-12-17 17:58:26,524] [1cc30048] [1114] - PES audio 0-0-1 fail
[2014-12-17 17:58:26,524] [1cc30048] [1114] - PES H264 0-0-1 fail
[2014-12-17 17:58:26,534] [1cc30048] [1114] - PES H264 0-0-1 fail
[2014-12-17 17:58:26,535] [1cc30048] [1114] - PES H264 0-0-1 fail
[2014-12-17 17:58:26,545] [1cc30048] [1114] - PES H264 0-0-1 fail
[2014-12-17 17:58:26,545] [1cc30048] [1114] - PES H264 0-0-1 fail
[2014-12-17 17:58:26,546] [1cc30048] [1114] - PES audio 0-0-1 fail

.....which usually means that the stream payload is encrypted. Eventually it starts to see audio (and some video) but that's 25s after the start....

Note that playing 'recorded' timeshift afterwards isn't the same situation, because the splitter filter can skip over the encrypted junk at the start so they will appear to start playing very quickly.

 

[HomeY]

You have more than 25s of this in TsReader log:

Correct. @mm1352000 told me in the past i shouldn't worry (too much) about these errors, so i never have, but now it's resulting in a black screen/no Video.
When i stop playback when i see the black screen, then tune the channel again, i get the TV picture fine, so somehow MP is in at least 50% of the times able to decrypt it.

I'm wondering if my CAM (or the FW update) is the issue or MP code is causing this. The strange thing is that it simply works as expected in at least 50% of the tuning attempts.
If it's the FW update, then i don't understand why 3.25 FW works fine, and i have the same (decryption?) problems with 3.27 & 3.28. Also i would have expected more user reports with similar issues. If the CAM is buggy, then i need to buy me a new one. Unless something is going wrong with decryption in MP

Any ideas/suggestions?

 

[HTPCSourcer]

When i stop playback when i see the black screen, then tune the channel again, i get the TV picture fine, so somehow MP is in at least 50% of the times able to decrypt it.

I had a similar discussion with mm about two Sky channels that sometimes decode but often lead to a dark screen. mm analyzed my TV logs and explained that there was a timing problem with respect to the card signaling successful decryption and MP managing streams. He mentioned that he knew where the code issue in TV Server was but that he was not planning to correct it.

 

[HomeY]

He mentioned that he knew where the code issue in TV Server was but that he was not planning to correct it.

Not sure if it's the same, but sounds alike.
And i assume you're talking about a fix in TVE3? Maybe it's fixed in TVE3.5?

 

[mm1352000]

Correct. @mm1352000 told me in the past i shouldn't worry (too much) about these errors, so i never have, but now it's resulting in a black screen/no Video.

Yes, but in the past you only had a few of these messages for a second or two. That's very different to 25+ seconds. I would not say don't worry about it if you had/have 25+ seconds of message logging.

When i stop playback when i see the black screen, then tune the channel again, i get the TV picture fine, so somehow MP is in at least 50% of the times able to decrypt it.

Probably the CAM is already configured to decrypt the channel. Therefore there is minimal effort for the CAM to start decrypting the channel, and therefore no problem.

I'm wondering if my CAM (or the FW update) is the issue or MP code is causing this. The strange thing is that it simply works as expected in at least 50% of the tuning attempts.

I pick the CAM or CI driver. Surely it should not take so long for decryption to kick in?!?
Also, I can't imagine how MP code could cause this. If the stream is encrypted then we simply have to throw away packets while we wait for the CAM to do its job.

If it's the FW update, then i don't understand why 3.25 FW works fine, and i have the same (decryption?) problems with 3.27 & 3.28.

Probably only the people who created the CAM firmware would be able to explain it. Don't make the common mistake of assuming newer is better.

Also i would have expected more user reports with similar issues.

Why?
How many people have the same provider, CAM, CI, driver and firmware combination?

Any ideas/suggestions?

Stay with the working firmware, and report the problem to the CAM and/or CI/tuner vendor.

I had a similar discussion with mm about two Sky channels that sometimes decode but often lead to a dark screen. mm analyzed my TV logs and explained that there was a timing problem with respect to the card signaling successful decryption and MP managing streams. He mentioned that he knew where the code issue in TV Server was but that he was not planning to correct it.

There is such an issue when channels use PES level encryption. TVE 3's TsWriter is not able to detect it. Usually it doesn't matter because the CAM only takes a second or so to start decrypting.

Not sure if it's the same, but sounds alike.
And i assume you're talking about a fix in TVE3? Maybe it's fixed in TVE3.5?

Maybe it is the same or alike. Either way, it shouldn't take so long for your CAM to start decrypting.
For the record, TVE 3.5's TsWriter can indeed detect PES level encryption. As usual, I don't intend to spend time implementing the same in TVE 3 where it would take longer and be more complex to implement.