Bug #5900
TVH does not answer to PIN query
0%
Description
Latest master does not answer to PIN query from CAM.
2020-05-15T16:27:32.770724+02:00 deepserver kernel: [ 5876.480241] dvb_ca_en50221: dvb_ca adapter 2: DVB CAM detected and initialised successfully
2020-05-15T16:27:32.924510+02:00 deepserver tvheadend8468: en50221: dvbca2: received sb but slot is not ready
2020-05-15T16:27:33.174957+02:00 deepserver tvheadend8468: linuxdvb: dvbca0-0: CAM slot 0 status changed to module init
2020-05-15T16:27:33.499004+02:00 deepserver tvheadend8468: linuxdvb: dvbca0-0: CAM slot 0 status changed to module connected
.....enable tracing in log file for ddci and eb50221 ... tune on encrypted channel with PIN Query:
2020-05-15 16:30:38.809 [ INFO]:subscription: 0039: "HTTP" subscribing on channel "WELT HD", weight: 100, adapter: "CXD2854 DVB-C #0", network: "DVB-C DS", mux: "354MHz", provider: "Digital Free", service: "WELT HD", profile="pass", hostname="192.168.1.9", username="admin", client="VLC/3.0.8 LibVLC/3.0.8"
....
2020-05-15 16:30:44.179 [ TRACE]:en50221: 00 01 A0 35 01 90 02 00 05 9F 88 07 2C 01 04 42 ...5........,..B
2020-05-15 16:30:44.179 [ TRACE]:en50221: 69 74 74 65 20 67 65 62 65 6E 20 53 69 65 20 49 itte geben Sie I
2020-05-15 16:30:44.179 [ TRACE]:en50221: 68 72 65 20 4A 75 67 65 6E 64 73 63 68 75 74 7A hre Jugendschutz
2020-05-15 16:30:44.179 [ TRACE]:en50221: 2D 50 49 4E 20 65 69 6E 2E 80 02 01 00 -PIN ein.....
2020-05-15 16:30:44.179 [ TRACE]:en50221: dvbca2-slot0-app00400041/0005: enquiry
2020-05-15 16:30:44.179 [ TRACE]:en50221: dvbca2-slot0-app00400041/0005: enquiry data 01 04 'Bitte geben Sie Ihre Jugendschutz-PIN ein.'
2020-05-15 16:30:44.179 [ INFO]:en50221: dvbca0-0: ops enquiry: {"blind":true,"explen":4}
2020-05-15 16:30:44.179 [ TRACE]:en50221: dvbca2: write
2020-05-15 16:30:44.179 [ TRACE]:en50221: 00 01 A0 09 01 90 02 00 05 9F 88 00 00 .............
2020-05-15 16:30:44.284 [ TRACE]:en50221: dvbca2: read
2020-05-15 16:30:44.284 [ TRACE]:en50221: 00 01 80 02 01 00 ......
2020-05-15 16:30:44.284 [ TRACE]:en50221: dvbca2: write
2020-05-15 16:30:44.284 [ TRACE]:en50221: 00 01 A0 01 01 .....
2020-05-15 16:30:44.388 [ TRACE]:en50221: dvbca2: read
2020-05-15 16:30:44.388 [ TRACE]:en50221: 00 01 80 02 01 80 ......
2020-05-15 16:30:44.388 [ TRACE]:en50221: dvbca2: write
2020-05-15 16:30:44.388 [ TRACE]:en50221: 00 01 81 01 01 .....
2020-05-15 16:30:44.493 [ TRACE]:en50221: dvbca2: read
2020-05-15 16:30:44.493 [ TRACE]:en50221: 00 01 A0 05 01 95 02 00 05 80 02 01 00 .............
2020-05-15 16:30:44.493 [ TRACE]:en50221: dvbca2-slot0-app00400041/0005: destroyed (mmi)
--> "Reply to CAM PIN inquiries" has been set to enable and I have already tested with
different Strings like "-PIN" , "Bitte".
Obviously TVH does not answer to the query, otherwise we would see from linuxdvb_ca_ops_enquiry:
"tvhtrace(LS_EN50221, "%s: answering to PIN enquiry", lca->lca_name);"
History
Updated by Flole Systems over 4 years ago
Was this working before or did you never test it before? The issue seems to be that the enquiry does not contain a "text" attribute which the code checks for. You need to figure out why in src/input/mpegts/en50221/en50221_apps.c:571 it is never added.
Updated by Anonymous over 4 years ago
I have never seen the "answering to PIN enquiry" despite the fact that I have traced a lot end of last year. The issue came up because I've seen this error over at kodinerds - so I tried again.
It doesn't matter if there is the real PIN stored or not in TVH: it seems that this is never used.
(I can test if there is a hint - but I've terminated my HD Contract due to the unsolved Continuity Counter Errors when descrambling HD Content: so only for a couple of weeks.=)
Updated by Flole Systems over 4 years ago
You can try to use gdb and add a breakpoint in the above-mentioned line and see if that is called. In case it isn't, please break one line above and dump every variable of the if condition right above to see why it is never called. You could also add debug strings if you don't want to use gdb. I'm pretty confident that we can get at least this issue figured out, the continuity errors are a different story though and are usually caused at driver or Signal level.
Updated by Anonymous over 4 years ago
Flole Systems wrote:
I'm pretty confident that we can get at least this issue figured out, the continuity errors are a
different story though and are usually caused at driver or Signal level.
Will try - reenable ddd..
CC Errors: only encrypted channels are affected. Not encrypted channels never have an error - and their bandwidth is higher.
If it would be an driver or signal issues than all channels would be affected - at least if they reach a certain BW level.
Updated by Anonymous over 4 years ago
Finished writing and: OOPS - seems that descrambling crashed.
2020-05-17T23:30:37.770895+02:00 deepserver tvheadend1544: CRASH: STACKTRACE
2020-05-17T23:30:37.818516+02:00 deepserver tvheadend1544: CRASH: /usr/src/tvheadend/src/trap.c:176 0x7fcaaa87233a 0x7fcaaa660000
2020-05-17T23:30:37.866725+02:00 deepserver tvheadend1544: CRASH: ??:0 0x7fcaa94f32d0 0x7fcaa94e0000
2020-05-17T23:30:37.868438+02:00 deepserver tvheadend1544: CRASH: pthread_mutex_lock+0x0 (/lib64/libpthread.so.0)
2020-05-17T23:30:37.905410+02:00 deepserver tvheadend1544: CRASH: /usr/src/tvheadend/src/input/mpegts/mpegts_input.c:1632 (discriminator 1) 0x7fcaaa8f4b68 0x7fcaaa660000
2020-05-17T23:30:37.945358+02:00 deepserver tvheadend1544: CRASH: /usr/src/tvheadend/src/input/mpegts/linuxdvb/linuxdvb_ddci.c:681 0x7fcaaa96d63e 0x7fcaaa660000
2020-05-17T23:30:37.976588+02:00 deepserver tvheadend1544: CRASH: /usr/src/tvheadend/src/tvh_thread.c:91 0x7fcaaa834594 0x7fcaaa660000
2020-05-17T23:30:38.020458+02:00 deepserver kernel: [ 1162.943065] show_signal_msg: 3 callbacks suppressed
2020-05-17T23:30:38.020480+02:00 deepserver kernel: [ 1162.943071] tvh:ldvb-ddci-r1685: segfault at 2b8 ip 00007fcaa94eae40 sp 00007fcaa59e5978 error 4 in libpthread-2.26.so[7fcaa94e0000+19000]
Updated by Flole Systems over 4 years ago
That seems to be some kind of memory corruption. If you are not using latest this would be a great time to upgrade because a possible buffer overflow was fixed which could cause something like this. If that doesn't help and you can reliably reproduce this valgrind would tell what's going on. I know how annoying this is, I had random crashes for a year when I was new to this project and nobody else had those and it was impossible to find the issue as it seemed to be coming out of nowhere. Turned out it happened whenever a SAT>IP client was watching a channel and something else was subscribed to the same frequency and the SAT>IP Client unsubscribed. The issue was a sorting issue in a tree which caused a subscription that's supposed to be deleted to never be found, once that was fixed it was working great.
If you can't reliably reproduce this it's more difficult, there should be a mutex corruption check which didn't catch this one for some reason. Either you have trace disabled at compile time or something else is wrong.
Updated by Anonymous over 4 years ago
Flole Systems wrote:
I know how annoying this is, I had random crashes for a year when I was new to this project and nobody else had those and it was impossible to find the issue as it seemed to be coming out of nowhere. Turned out it happened whenever a SAT>IP client was watching a channel and something else was subscribed to the same frequency and the SAT>IP Client unsubscribed. The issue was a sorting issue in a tree which caused a subscription that's supposed to be deleted to never be found, once that was
There is a difference. Your setup works until an external event (subscription) is chrashing tvh - so it may happen that your setup is stable for hours.
The CC errors within tvh drops every few seconds the sound output: so it is basically unusable.