Tvheadend

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.

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.=)

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.

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.

Finished writing and: OOPS - seems that descrambling crashed.

2020-05-17T23:30:37.770895+02:00 deepserver tvheadend¹⁵⁴⁴: CRASH: STACKTRACE
2020-05-17T23:30:37.818516+02:00 deepserver tvheadend¹⁵⁴⁴: CRASH: /usr/src/tvheadend/src/trap.c:176 0x7fcaaa87233a 0x7fcaaa660000
2020-05-17T23:30:37.866725+02:00 deepserver tvheadend¹⁵⁴⁴: CRASH: ??:0 0x7fcaa94f32d0 0x7fcaa94e0000
2020-05-17T23:30:37.868438+02:00 deepserver tvheadend¹⁵⁴⁴: CRASH: pthread_mutex_lock+0x0 (/lib64/libpthread.so.0)
2020-05-17T23:30:37.905410+02:00 deepserver tvheadend¹⁵⁴⁴: CRASH: /usr/src/tvheadend/src/input/mpegts/mpegts_input.c:1632 (discriminator 1) 0x7fcaaa8f4b68 0x7fcaaa660000
2020-05-17T23:30:37.945358+02:00 deepserver tvheadend¹⁵⁴⁴: CRASH: /usr/src/tvheadend/src/input/mpegts/linuxdvb/linuxdvb_ddci.c:681 0x7fcaaa96d63e 0x7fcaaa660000
2020-05-17T23:30:37.976588+02:00 deepserver tvheadend¹⁵⁴⁴: 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-r¹⁶⁸⁵: segfault at 2b8 ip 00007fcaa94eae40 sp 00007fcaa59e5978 error 4 in libpthread-2.26.so[7fcaa94e0000+19000]

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.

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.