Tvheadend

I have now rolled back to 4.0.5-13~g7ca4286. And continued the same scan from where it left off. It's been going for about 10 minutes.

Waiting to see if 4.0.5 +13 ver also segfault. If not segfault, i don't report anything new or update this ticket after 1-2 day. Then it may be a new issue in the most recent commit(s). Please investigate if you can.

Could you run valgrind on 4.0.5-17 ? There are no changes which should invoke a segfault in diff 13-17..

Jaroslav Kysela wrote:

Could you run valgrind on 4.0.5-17 ? There are no changes which should invoke a segfault in diff 13-17..

Ok. Never used valgrind before. I tried to run valgrind but not sure if it worked properly. Because then there was no output from tvheadend-dbg. And it exited very fast.

https://gist.github.com/dreamcat4/af947209b3b031cf9008

Would like to try again / better. Just not very good at this.

Dreamcat 4 wrote:

And it exited very fast.

Ah. Maybe i need to remove `--fork` from my $tvheadend_args.

Dreamcat 4 wrote:

Maybe i need to remove `--fork` from my $tvheadend_args.

https://gist.github.com/dreamcat4/730507fba35919534c72

Another fast exit during startup. Again I apologise. Don't know if that was what you were looking for.

Ok. I eventually got valgrind to work while tvheadend continues to run. But then could no longer reproduce any segfault crash.

I am suspicious of my config. Since it turned out I had 3 bouquets enabled all together. the 'SD', 'HD' and 'G2' versions of same region. I disabled the 2 not-needed bouquets in subsequent testing. So it was only tuning with 1 bouquet in the subsequent sessions. Then no segfault has occurred since that time.

It looks like a memory corruption somewhere, but it's very difficult to trace it..

Ok perexg. Went back to ~17 with 1 bouquest enabled in config. It's been scanning fine. No crashes.

So I'm going to assume / attribute the issue to be because of scanning with multiple bouquets enabled (in my case it was 3 of them). The 3 bouquets were all very similar to each other, with 90% + same channels. So maybe there was some contention going on. For exaxmple perhaps if 2 different bouquet were trying to update the same channel simultaneously. It's just a speculation.

Anyway. I'm glad we have eliminate ~13 to ~17 changeset being anything to do with it. And for myself - it seems I only need 1 bouquet enabled. As terrestrial (DVB-T) my other input source don't use bouquets at all.

Many thanks for your help perexg. Please feel free to close this issue / as you wish.

I might also be so bold to ask you to please tag 4.0.6 from the release/4.0 branch. If there are not any other issues / pending changes. Because it includes an important fix regarding the seperate user DVR profiles / DVR access. Which came after the v4.0.5.