No IPTV for Switzerland, no DVB-C for Zug (1 Viewer)

[mm1352000]

Hi rsbrux

Sorry for the long delay...

No problem.

After a virgin install of MP 1.21, I first performed a scan with your XML file, which only turned up 232 channels this time...
In hope of a different result, I deleted all of the channels and rescanned using "search all transponders". This came up with 253 channels, as before, of which all but 3 show as scrambled.

The difference here is that my XML file was missing 3 frequencies. Perhaps the provider list was out of date or they are test channels. Anyhow here they are:
546 MHz, 6900 ksps, 256 QAM (18 channels)
642 MHz, 6900 ksps, 256 QAM (2 channels - ORF eins HD and ORF 2 HD)
698 MHz, 6900 ksps, 256 QAM (1 channel - 3D test channel)

Note that the "search all transponders scan" would take longer than the XML scan as it scans quite a lot of frequencies that aren't used.

All of the channels except 1 were marked scrambled (shown in red), which is technically speaking probably true. It isn't very helpful however, because I would like to deselect just the ones I can't decode with my CAM, and don't fancy previewing each of the 200+ channels to figure out which ones they are. ;-)
...My trial periond has presumably expired, so I would be very interested in some way to automatically exclude the channels I can't decode.

Yes, I can understand how that would be helpful. I don't know of any way to check whether a channel can be decrypted except to try and view it. Perhaps we could think about adding a function that goes through all channels attempting to timeshift them, and if timeshifting fails then delete them. Having said that, I'm not very knowledgeable about CAMs and subscriptions. Perhaps there is a better way...

The (2nd set of) logs includes 2 (preview) tuning attempts, 1 successful and 1 with the pmt error. Both channels are scrambled, but the successfully previewed one (SF1) definitely belongs to my subscription, whereas the one producing the PMT error may not.

Hmm, okay - this is unexpected CAM behaviour from my perspective. I would have expected the CAM to pass the PMT and then reject the decryption request. If it doesn't even pass the PMT then it makes things difficult for us.

BTW, I would also like to get IPTV working. Do I still need to apply the patches described in this thread, or has this already been rolled into MP v1.21?

That patch is not in 1.2.1 but we'd like to add it for 1.3.0 so I'd encourage you to try it and report to georgius.

mm

 

[rsbrux]

I don't know of any way to check whether a channel can be decrypted except to try and view it. Perhaps we could think about adding a function that goes through all channels attempting to timeshift them, and if timeshifting fails then delete them. Having said that, I'm not very knowledgeable about CAMs and subscriptions. Perhaps there is a better way...

Actually, MP TVsetup already has a perfectly good solution. If I run the "Test" on all channels, it simply unchecks the channels it can't decode, so they won't appear in the guide. Since TVsetup doesn't provide a "total checked", I'll have to check the guide against the Telezug channel list to see if the result makes sense.

Hmm, okay - this is unexpected CAM behaviour from my perspective. I would have expected the CAM to pass the PMT and then reject the decryption request. If it doesn't even pass the PMT then it makes things difficult for us.

The log from the channel test run unexpectedly shows:

 WaitForPMT: Found PMT after 0.21875 seconds.

for Liberty, which gave the PMT error on the last attempt. However, it also shows

***** SIGNAL LEVEL: 0, SIGNAL QUALITY: 0 *****

and leaves the channel unchecked.
SInce Liberty isn't on the list of channels I am supposed to have, I don't really care, but it does look as though TV server's error detection around CAM decoding might be inconsistent.

That patch is not in 1.2.1 but we'd like to add it for 1.3.0 so I'd encourage you to try it and report to georgius.

Will do. Thanks again for your help!

 

[mm1352000]

Just a quick comment:

The log from the channel test run unexpectedly shows:

 WaitForPMT: Found PMT after 0.21875 seconds.

for Liberty, which gave the PMT error on the last attempt. However, it also shows

***** SIGNAL LEVEL: 0, SIGNAL QUALITY: 0 *****

and leaves the channel unchecked.
SInce Liberty isn't on the list of channels I am supposed to have, I don't really care, but it does look as though TV server's error detection around CAM decoding might be inconsistent.

This behaviour is more what I expected. If TV Server can't find the PMT (which depends entirely on the tuner and CAM) then it should do what it did in the previous case. If it finds the PMT as it did in this latest test then it should send the PMT to the CAM to request that the CAM start decrypting the channel... which is exactly what TV Server did:

[COLLAPSE]2011-10-07 15:33:09.348632 [(17)]: dvb: LockedInOnSignal ok
2011-10-07 15:33:09.348632 [(17)]: subch:0 OnGraphStarted
2011-10-07 15:33:09.348632 [(17)]: subch:0 SetupPmtGrabberid 866 sid:AAC
2011-10-07 15:33:09.348632 [(17)]: subch:0 set pmt grabber pmt:866 sid:AAC
2011-10-07 15:33:09.348632 [(17)]: TimeShifter.OnAfterTune: resetting audio/video time
2011-10-07 15:33:09.364257 [(17)]: WaitForPMT: Waiting for PMT 866
2011-10-07 15:33:09.567382 [(13)]: subch:0 OnPMTReceived() pmt:866 ran:True dynamic:False
2011-10-07 15:33:09.567382 [(17)]: WaitForPMT: Found PMT after 0.21875 seconds.
2011-10-07 15:33:09.567382 [(17)]: subch:0 SendPmt:AAC AAC FFFFFFFF 3
2011-10-07 15:33:09.567382 [(17)]: Decode pmt
2011-10-07 15:33:09.567382 [(17)]: descr1 len:6 9 4 b 0 e4 2a
2011-10-07 15:33:09.583007 [(17)]: descr1 len:6 9 4 56 1 e6 1e
2011-10-07 15:33:09.583007 [(17)]: Set descriptor data with length 6
2011-10-07 15:33:09.583007 [(17)]: subch:0 SendPMT version:3 len:41 2732
2011-10-07 15:33:09.583007 [(17)]: Decode pmt
2011-10-07 15:33:09.583007 [(17)]: descr1 len:6 9 4 b 0 e4 2a
2011-10-07 15:33:09.583007 [(17)]: descr1 len:6 9 4 56 1 e6 1e
2011-10-07 15:33:09.583007 [(17)]: Set descriptor data with length 6
2011-10-07 15:33:09.583007 [(17)]: Twinhan: Send PMT, len: 29
2011-10-07 15:33:09.598632 [(17)]: capmt:
2011-10-07 15:33:09.598632 [(17)]: 0000|03 0A AC C7 00 0D 01 09 04 0B 00 E4 2A 09 04 56 |____________*__V
2011-10-07 15:33:09.598632 [(17)]: 0010|01 E6 1E 02 E8 68 00 00 03 E8 69 00 00 |_____h____i__
2011-10-07 15:33:10.598632 [(17)]: Twinhan: CAM returned ok 0x0[/COLLAPSE]

As you can see, the CAM responded with "OK", which is meant to mean that the channel is being decrypted. TV Server proceeds to try and start timeshifting:

[COLLAPSE]2011-10-07 15:33:10.614257 [(17)]: **************************************************
2011-10-07 15:33:10.629882 [(17)]: ***** SIGNAL LEVEL: 0, SIGNAL QUALITY: 0 *****
2011-10-07 15:33:10.629882 [(17)]: **************************************************
2011-10-07 15:33:10.629882 [(17)]: card: tuned user: ScaleoE subchannel: 0
2011-10-07 15:33:10.629882 [(17)]: usercaleoE add
2011-10-07 15:33:10.629882 [(17)]: card2caleoE 2 0
2011-10-07 15:33:10.629882 [(17)]: Controller: ScaleoE 2 0
2011-10-07 15:33:10.629882 [(17)]: control2caleoE 2 0
2011-10-07 15:33:10.645507 [(17)]: Controller: delete timeshift files C:\ProgramData\Team MediaPortal\MediaPortal TV Server\timeshiftbuffer\live2-0.ts
2011-10-07 15:33:10.645507 [(17)]: card: StartTimeShifting 2 C:\ProgramData\Team MediaPortal\MediaPortal TV Server\timeshiftbuffer\live2-0.ts
2011-10-07 15:33:10.661132 [(17)]: card: CAM enabled : True
2011-10-07 15:33:10.661132 [(17)]: subch:0 SetTimeShiftFileName:C:\ProgramData\Team MediaPortal\MediaPortal TV Server\timeshiftbuffer\live2-0.ts
2011-10-07 15:33:10.661132 [(17)]: Set video / audio observer
2011-10-07 15:33:10.661132 [(17)]: subch:0 SetTimeShiftFileName fill in pids
2011-10-07 15:33:10.676757 [(17)]: subch:0-0 tswriter StartTimeshifting...
2011-10-07 15:33:10.692382 [(17)]: card: WaitForTimeShiftFile - waiting _eventAudio & _eventVideo
2011-10-07 15:33:25.692382 [(17)]: card: WaitForTimeShiftFile - no audio was found after 15 seconds
2011-10-07 15:33:25.692382 [(17)]: card: WaitForTimeShiftFile - audio and video stream is scrambled[/COLLAPSE]

TV Server detects that the signal is still encrypted. It gives the CAM some time to start doing its job but after 15 seconds when the channel is still encrypted TV Server says "enough is enough" and gives up. I'm not sure what more we could do than that. One thing you could do to verify this result is to copy the timeshift file created in those 15 seconds and see if it plays in VLC or similar....

In any case, all that is to say that TV Server behaves as consistently as possible. In the first case the channel wasn't even found for whatever reason so TV Server has little help of telling you it is encrypted. In the second case, the tuner and CAM behave like they will decrypt the signal but TV Server finds that the signal is still encrypted. We do the best that we can.

mm