Tunes to wrong sid

[mrfloppy82]

Hello,

i have another Problem with one Channel.

N24HD Germany and N24HD Austria (HD+). Both channels are on the same transponder and have the same Video/Audio PIDs. Only the service id is different (http://www.satindex.de/frequenz/10773/).

I have only N24HD Germany subscribed. Sometimes ffdecswrapper requests an ecm for N24Germany and sometimes for N24Austria. So sometimes I can watch the channel, sometimes not. I can see it in the oscam webif that the requests are for the wrong channel.

I use ffdecsawrapper master and mythtv 0.27 with newcamd protocol. I have also tested with stable branch and i changed the protocol to cccam2. Same problem.

Best regards.

[bas-t]

This does not seem to be FFdecsawrapper related. More like broken provider and/or mythtv related. Mind you: this is NOT a support forum. However, if you can point me to a bug in FFdecsawrapper, I'll try to fix it.

mrfloppy82 schreef op 02-08-14 01:31:

Hello,

i have another Problem with one Channel.

N24HD Germany and N24HD Austria (HD+). Both Channels are on the same Transponder and have the same Video/Audio PIDs. Only the ServiceID is different (http://www.satindex.de/frequenz/10773/).

I have only N24HD Germany subscribed. Sometimes, ffdecswrapper requests an ecm for N24Germany and sometimes for N24Austria. So sometimes I can watch the Channel, somtetimes not. I can see it in the oscam webif that the requests are for the wrong channel.

I use ffdecsawrapper master and mythtv 0.27 with newcamd protocol. I have also tested with stable branch and i changed the protocol to cccam2. Same problem.

Best regards.

— Reply to this email directly or view it on GitHub https://github.com/bas-t/ffdecsawrapper/issues/26.

[bas-t]

I'd like you to provide me with more details. What happens when you tune to another service in the same mux first, and afterwards you tune to N24HD and oscam gets the wrong ECM request. I mean: does the first tuned show finish recording (or does it stall the minute you try to record the N24HD show)? Does the N24HD show recording ends up with a 0 byte recording?

[mrfloppy82]

Thanks for your reply. I will test it this afternoon.

[bas-t]

When you are going to test, run FFdecsawrapper with:

--sid-ignore 21118

That'll probably solve your issue, 21118 being the sid of N24 HD Austria However, MythTV can still send wrong tuning params.

[mrfloppy82]

Hello,

first of all the --sid-ignore parameter solved my problems. For german users there some other channels where we have the problems:

N24HD DMAXHD TELE5HD NICK/CCHD

So we must call ffdecsawrapper with this parameter to ignore the Austria versions of the channels:

--sid-ignore 21117,21118,5421,5422

[mrfloppy82]

I have activated the debug logging for CHANNEL in ffdecsawrapper and i think i found the problem in "find sid for pid".

Here is a log where it does not work:

Reading 11 of 32 filters Aug 4 17:53:14.707 CHANNEL: polling 11 fds Aug 4 17:53:14.707 CHANNEL: Read 38 bytes Aug 4 17:53:14.707 CHANNEL: read_pmt: sid: 21112 pcrpid: 3071 skip: 0 count: 34 Aug 4 17:53:14.707 CHANNEL: read_pmt: epid 3071 (type 27) mapped to sid 21112 Aug 4 17:53:14.708 CHANNEL: read_pmt: epid 3072 (type 3) mapped to sid 21112 Aug 4 17:53:14.708 CHANNEL: polling 11 fds Aug 4 17:53:14.733 CHANNEL: Read 452 bytes Aug 4 17:53:14.733 CHANNEL: read_pmt: sid: 21108 pcrpid: 767 skip: 381 count: 448 Aug 4 17:53:14.733 CHANNEL: read_pmt: epid 34 (type 6) mapped to sid 21108 Aug 4 17:53:14.733 CHANNEL: read_pmt: epid 50 (type 134) mapped to sid 21108 Aug 4 17:53:14.733 CHANNEL: read_pmt: epid 767 (type 27) mapped to sid 21108 Aug 4 17:53:14.733 CHANNEL: read_pmt: epid 771 (type 6) mapped to sid 21108 ... Aug 4 17:53:14.734 CHANNEL: polling 11 fds Aug 4 17:53:14.761 CHANNEL: Read 84 bytes Aug 4 17:53:14.761 CHANNEL: read_pmt: sid: 21118 pcrpid: 767 skip: 24 count: 80 Aug 4 17:53:14.761 CHANNEL: read_pmt: epid 34 (type 6) mapped to sid 21118 Aug 4 17:53:14.761 CHANNEL: read_pmt: epid 767 (type 27) mapped to sid 21118 Aug 4 17:53:14.761 CHANNEL: read_pmt: epid 771 (type 6) mapped to sid 21118 Aug 4 17:53:14.761 CHANNEL: Read 89 bytes ... Aug 4 17:53:14.936 CHANNEL: returned: 0 Aug 4 17:53:14.936 CHANNEL: Got Pid: 8130 Aug 4 17:53:14.936 CHANNEL: Didn't find sid for pid: 8130 ... Aug 4 17:53:14.936 CHANNEL: Got Pid: 767 Aug 4 17:53:14.936 CHANNEL: Found sid: 21118 ... Aug 4 17:53:14.937 CAM(core.pids): 1: update SID 21118 (zero=0 noshift=0)

Here is the log where is does work:

Aug 4 18:05:01.874 CHANNEL: Reading 11 of 32 filters Aug 4 18:05:01.874 CHANNEL: polling 11 fds Aug 4 18:05:01.888 CHANNEL: Read 38 bytes ... Aug 4 18:05:01.943 CHANNEL: read_pmt: sid: 21118 pcrpid: 767 skip: 24 count: 80 Aug 4 18:05:01.943 CHANNEL: read_pmt: epid 34 (type 6) mapped to sid 21118 Aug 4 18:05:01.943 CHANNEL: read_pmt: epid 767 (type 27) mapped to sid 21118 Aug 4 18:05:01.943 CHANNEL: read_pmt: epid 771 (type 6) mapped to sid 21118 Aug 4 18:05:01.943 CHANNEL: Read 89 bytes ... Aug 4 18:05:02.024 CHANNEL: read_pmt: sid: 21108 pcrpid: 767 skip: 381 count: 448 Aug 4 18:05:02.024 CHANNEL: read_pmt: epid 34 (type 6) mapped to sid 21108 Aug 4 18:05:02.024 CHANNEL: read_pmt: epid 50 (type 134) mapped to sid 21108 Aug 4 18:05:02.024 CHANNEL: read_pmt: epid 767 (type 27) mapped to sid 21108 Aug 4 18:05:02.024 CHANNEL: read_pmt: epid 771 (type 6) mapped to sid 21108 Aug 4 18:05:02.024 CHANNEL: polling 11 fds ... Aug 4 18:05:02.060 CHANNEL: Got Pid: 767 Aug 4 18:05:02.060 CHANNEL: Found sid: 21108 ... Aug 4 18:05:02.060 CAM(core.pids): 1: now tuned to source 88c0(S19.2E) transponder 1b5c6 Aug 4 18:05:02.060 CAM: FFdecsawrapper completed Tune cmd Aug 4 18:05:02.060 CAM(core.pids): 1: update SID 21108 (zero=0 noshift=0)

I think it is a problem that the 2 channels have the same pcrpid (767) and ffdecsawrapper reads in the wrong sid in dependence of the order of the list of sids.

[bas-t]

Thanks for your effort. I'll look into this as soon as time permits.

mrfloppy82 schreef op 04-08-14 18:56:

I have activated the debug logging for CHANNEL in ffdecsawrapper and i think i found the problem in "find sid for pid".

Here is a log where it does not work:

Reading 11 of 32 filters Aug 4 17:53:14.707 CHANNEL: polling 11 fds Aug 4 17:53:14.707 CHANNEL: Read 38 bytes Aug 4 17:53:14.707 CHANNEL: read_pmt: sid: 21112 pcrpid: 3071 skip: 0 count: 34 Aug 4 17:53:14.707 CHANNEL: read_pmt: epid 3071 (type 27) mapped to sid 21112 Aug 4 17:53:14.708 CHANNEL: read_pmt: epid 3072 (type 3) mapped to sid 21112 Aug 4 17:53:14.708 CHANNEL: polling 11 fds Aug 4 17:53:14.733 CHANNEL: Read 452 bytes Aug 4 17:53:14.733 CHANNEL: read_pmt: sid: 21108 pcrpid: 767 skip: 381 count: 448 Aug 4 17:53:14.733 CHANNEL: read_pmt: epid 34 (type 6) mapped to sid 21108 Aug 4 17:53:14.733 CHANNEL: read_pmt: epid 50 (type 134) mapped to sid 21108 Aug 4 17:53:14.733 CHANNEL: read_pmt: epid 767 (type 27) mapped to sid 21108 Aug 4 17:53:14.733 CHANNEL: read_pmt: epid 771 (type 6) mapped to sid 21108 ... Aug 4 17:53:14.734 CHANNEL: polling 11 fds Aug 4 17:53:14.761 CHANNEL: Read 84 bytes Aug 4 17:53:14.761 CHANNEL: read_pmt: sid: 21118 pcrpid: 767 skip: 24 count: 80 Aug 4 17:53:14.761 CHANNEL: read_pmt: epid 34 (type 6) mapped to sid 21118 Aug 4 17:53:14.761 CHANNEL: read_pmt: epid 767 (type 27) mapped to sid 21118 Aug 4 17:53:14.761 CHANNEL: read_pmt: epid 771 (type 6) mapped to sid 21118 Aug 4 17:53:14.761 CHANNEL: Read 89 bytes ... Aug 4 17:53:14.936 CHANNEL: returned: 0 Aug 4 17:53:14.936 CHANNEL: Got Pid: 8130 Aug 4 17:53:14.936 CHANNEL: Didn't find sid for pid: 8130 ... Aug 4 17:53:14.936 CHANNEL: Got Pid: 767 Aug 4 17:53:14.936 CHANNEL: Found sid: 21118 ... Aug 4 17:53:14.937 CAM(core.pids): 1: update SID 21118 (zero=0 noshift=0)

Here is the log where is does work:

Aug 4 18:05:01.874 CHANNEL: Reading 11 of 32 filters Aug 4 18:05:01.874 CHANNEL: polling 11 fds Aug 4 18:05:01.888 CHANNEL: Read 38 bytes ... Aug 4 18:05:01.943 CHANNEL: read_pmt: sid: 21118 pcrpid: 767 skip: 24 count: 80 Aug 4 18:05:01.943 CHANNEL: read_pmt: epid 34 (type 6) mapped to sid 21118 Aug 4 18:05:01.943 CHANNEL: read_pmt: epid 767 (type 27) mapped to sid 21118 Aug 4 18:05:01.943 CHANNEL: read_pmt: epid 771 (type 6) mapped to sid 21118 Aug 4 18:05:01.943 CHANNEL: Read 89 bytes ... Aug 4 18:05:02.024 CHANNEL: read_pmt: sid: 21108 pcrpid: 767 skip: 381 count: 448 Aug 4 18:05:02.024 CHANNEL: read_pmt: epid 34 (type 6) mapped to sid 21108 Aug 4 18:05:02.024 CHANNEL: read_pmt: epid 50 (type 134) mapped to sid 21108 Aug 4 18:05:02.024 CHANNEL: read_pmt: epid 767 (type 27) mapped to sid 21108 Aug 4 18:05:02.024 CHANNEL: read_pmt: epid 771 (type 6) mapped to sid 21108 Aug 4 18:05:02.024 CHANNEL: polling 11 fds ... Aug 4 18:05:02.060 CHANNEL: Got Pid: 767 Aug 4 18:05:02.060 CHANNEL: Found sid: 21108 ... Aug 4 18:05:02.060 CAM(core.pids): 1: now tuned to source 88c0(S19.2E) transponder 1b5c6 Aug 4 18:05:02.060 CAM: FFdecsawrapper completed Tune cmd Aug 4 18:05:02.060 CAM(core.pids): 1: update SID 21108 (zero=0 noshift=0)

I think it is a problem that the 2 channels have the same pcrpid (767) and ffdecsawrapper reads in the wrong sid in dependence of the order of the list of sids.

— Reply to this email directly or view it on GitHub https://github.com/bas-t/ffdecsawrapper/issues/26#issuecomment-51086608.

[bas-t]

Just to make sure: the difference between the working and the not working config is --sid-ignore 21117,21118,5421,5422 right?

[mrfloppy82]

Yes, i only added the "--sid-ignore" parameter.

[bas-t]

Hmm, I'll sleep on it. It still looks like a 'broken provider' thing to me. Please prove me wrong, if you can.

[mrfloppy82]

Good morning,

i think it is not a broken provider. Both channels uses the same audio-/videostream. I think there are only different service ids because in Germany and Austria are different encryption systems. In Germany we have additionally Nagravision, in Austria only Irdeto and VideoGuard. Over the Austria Service id (21118) you can only decrypt via Irdeto/Videogurad, with the german service id (21108) you can decrypt with all three systems. I will look in the code this afternoon, maybe i find something.

[mrfloppy82]

Hello,

I have looked into the source code. I think we can not fix the problem because we must know the SID which mythtv is processing. Through the loopback device we have only the VPID. And on the transponder are 2 SIDs with the same VPID. I think the only solution is the sid-ignore parameter.

Maybe a solution for the future:

ffdecsawrapper must read in all SIDs for one VPID and check with which SID can be done a decryption.

Regards.

[bas-t]

Nah, don't think so. What happens when ffdecsawrapper can decrypt both sid's? You'll still have that shit. Best solution: don't broadcast both sid's on the same mux (that's why I call it a broken provider, it's just plain stupid to keep them on the same mux). But we cannot make that happen. Bottomline: just use --sid-ignore, that is what it is for.

[bas-t]

Speaking of the devil... I just discovered exactely what I described in my last comment: About 2 hours ago, FFdecsawrapper started to decript the wrong sid. Both sid's are decryptable, I end up with a 0 byte recording and MythTV only dicovers that the recording failed at the end time of that recording. Conlusion: total miscommunication between MythTV and FFdecsawrapper.

[bas-t]

@ mrfloppy82: I took the liberty to change the subject of your issue, FFdecsawrapper only requests the wrong ecm since it tries to decrypt the wrong sid. Reopening this one and close #27, marking it as duplicate.

Did you compile FFdecsawrapper with --compiltype=debug?

[mrfloppy82]

Hi,

no, I compiled with "--compiletype=release"

[bas-t]

I'm sure that tuning to the wrong sid caused several failed recordings for me too. However, it is an unpredictable event here, it could happen today or in about a month or 4.

Nevertheless, I think we are suffering from the same issue. Debugging this could take a very long time without your help. I'll have to wait for the next event , while you can reproduce it at will. To get into this, I need specific debug logs to start with. That implies compiling FFdecsawrapper with --compiletype=debug, and if you are running MythTV from a distro package, the debug package installed. To get the cleanest possible logs, a couple of minor (easy reversible) tweaks in the mythconverg database are most helpfull. Are you willing to do this?

[mrfloppy82]

Hi,

no problem. I will create the logs early next week.

[bas-t]

Before creating logs, please verify that you can reproduce the issue under these circumstances: In mythtv-setup -> input connections set 'Use quick tuning' to 'always' for all of your adapters, and run FFdecsawrapper without the --sid-ignore parameter. Please share the result with me.

[mrfloppy82]

Hi,

I did not have much time this week. But noew here are my Logs. I looks like mythtv tune too the right SID. The problem is at 11:28:51. Mythtv tunes to the right SID 21108, ffdecsawrapper requests ecms for SID 21118.

Sorry, I did not found an option to attach text files!

[mrfloppy82]

ffdecsawrapper.log

http://pastebin.com/M5fUaXHg

[mrfloppy82]

mythbackend.log

http://pastebin.com/QmxdcekP

[bas-t]

PLEASE USE PASTEBIN!

[bas-t]

Thanks for using pastebin. Since you editet your posts, I was not informed, so I discovered it just now. I'll try to find some time to look into the logs next week.

[bas-t]

I still can't reproduce this. So I'm closing this ticket.