dropouts when watching hd tv (3 Viewers)

[HomeY]

Have you observed any pattern in terms of channels? Channels which seem to cause the problem semi-consistently?

Unfortunately not.
I'm playing around with the above TsReader as we speak, and so far tuning hasn't failed yet (about 20 zaps, FTA included).
I've attached the TsReader log.

Either way, do you still have TransEdit installed and could you grab a screenshot of a hex view of the video/audio packets for one of these channels?

Sure, still have TransEdit on my server, but would need guidance/instructions on how to do that.

 

[HomeY]

Is this what you need?

RTL 7 HD (Video HEX)

RTL 7 HD (Audio HEX)

RTL 7 HD is a channel of which i'm sure of that tuning has failed (once or several times).

 

[mm1352000]

Sure, still have TransEdit on my server, but would need guidance/instructions on how to do that.

Tune ("analyse") the transmitter as it looks like you have done.
Then, in the right hand pane find the video or audio PID for RTL 7 HD. I'd expect the text in the row to be red (meaning = encrypted).
Right click on the PID row and select hex view. I think it is called that. Sorry, don't have access to TransEdit right now.
As I recall, there's a checkbox in the bottom of the hex view window that says something like "wait for payload start indicator". That needs to be ticked. If it is not, close the hex view window and reopen it.
Then, just take a screenshot of the hex view window.

 

[HomeY]

Think i found it

I'd expect the text in the row to be red (meaning = encrypted).

Correct, Video & Audio are the only parts showing encrypted.

 

[mm1352000]

Right, so that channel seems to be scrambled at TS level. Very interesting that you would have experienced problems with it. As Owlsroost said, that would mean the CAM was marking the TS packets as not encrypted, apparently without actually decrypting them. Very very interesting...

 

[HomeY]

It was going great whole day (about 25 zaps).
Just now i stopped Radio playback, went into EPG and directly started TV, and it delayed (but tunes in the end).
Logs attached.

I also notice a whole bunch of 'Seek failed' entries from this afternoon. Not sure what it was, but i can't recall seeing anything weird around that time.

 

[Owlsroost]

I also notice a whole bunch of 'Seek failed' entries from this afternoon. Not sure what it was, but i can't recall seeing anything weird around that time.

It was having problems reading the timeshift buffer files occasionally - there are these messages in the log as well:

[2014-12-23 12:52:52,334] [1c05d6c8] [ 968] - FileReader::OpenFile() unbuff, 13 tries to open \\SERVER\Timeshifting\live4-0.ts.tsbuffer6.ts
[2014-12-23 12:52:52,648] [1c05d6c8] [ 968] - FileReader::OpenFile(), dummy file write 16 bytes to \\SERVER\Timeshifting\live4-0YpZUYsfcdtOg6.ts
[2014-12-23 12:52:52,649] [1c05d6c8] [ 968] - FileReader::OpenFile() unbuff, 14 tries to open \\SERVER\Timeshifting\live4-0.ts.tsbuffer6.ts
[2014-12-23 12:52:52,899] [1c05d6c8] [ 968] - FileReader::OpenFile(), open file failed. Error 0x80070002, The system cannot find the file specified., filename = \\SERVER\Timeshifting\live4-0.ts.tsbuffer6.ts
[2014-12-23 12:52:52,899] [1c05d6c8] [ 968] - MultiFileReader::SEEK FAILED
[2014-12-23 12:52:53,009] [1c05d6c8] [ 968] - MultiFileReader::SEEK FAILED

Looks like SMB (remote file access) was having a hard time....server load or network issues maybe ?

 

[HomeY]

As Owlsroost said, that would mean the CAM was marking the TS packets as not encrypted, apparently without actually decrypting them.

And this seems to happen at random. With the latest TsReader from Owlsroost i only had 2 fails so far (on about 40 tunes/zaps).

Very very interesting...

Please explain your thoughts

server load or network issues maybe ?

Hard to tell, but i don't see anything around that time in TsWriter.log
I also can't recall seeing issues on the HTPC, only noticed when i checked the logs.

Can't really match those times with the TVService.log either (attached). Looks like there was a tuning attempt/zap @ 12:53:39 but before that, there's a 10 minutes 'gap' in the logs:

[2014-12-23 12:43:56,675] [Log    ] [36       ] [DEBUG] - Detect BDA source devices
[2014-12-23 12:53:39,012] [Log    ] [17       ] [INFO ] - Controller: TimeShiftingWouldUseCard RTL 4 HD 812

 

[mm1352000]

Please explain your thoughts

Oh, it is relatively simple - I'm just puzzled, as it is something I haven't seen before. AFAIK such a situation shouldn't occur if the CAM is working correctly.

 

[HomeY]

as it is something I haven't seen before.

Welcome to my world. If you need 'exotic' bugs, give me a call.
Seems i often run into the weird ones / strange stuff