Tvheadend

https://tvheadend.org/projects/tvheadend/wiki/Debugging#Incorrect-not-useable-crash-reports

Flole Systems wrote:

https://tvheadend.org/projects/tvheadend/wiki/Debugging#Incorrect-not-useable-crash-reports

And what about it? You want me to compile debug version and do something with it? Why don't you simply do something about those symbol rates. Is it so hard to code an auto-correcting code to fill up three more zeros at the end if needed? Or at least stop it crashing entire application. Instead of throwing useless wiki link.

Victor - please have a short look at the code contributions from the persons which are currently answering on severe bug reports. I haven't found any and I haven't even even found one ticket which is currently solved from this side.

So: Yes - it is currently difficult to add code to catch the crashes.

But on the other hand it is very easy to compile tvh. "configure && make && make install"

I have seen a very similar behaviour - so it would be interesting to see if similar codepathes are used ....

@Tom W: You must have missed my contributions then. You might want to double-check that.

@Victor S: I can't even see what's going on because the crashdump is unusable. If you tell me what's wrong then I am sure that I can correct it. You should've read the wiki before opening a bug report, then I would not have to post a link that clearly explains you something that you didn't know before, otherwise you would not have opened an issue with an incorrect/unusable coredump. So it's not useless.

Other than that: As you think it's easy, this is fully open source software so you are more than welcome to fix this but and submit a pull request.

Oops - really ? Then I have overseen your changesets.

It may have happened that "update to latest" or "I don't even look into old version" is not considered as "contribution" from my side.

Do you have the rights to change the status of tickets ?

Check my commit history on GitHub, I think unfortunately not all changesets are displayed here. In fact the last commit was authored by me (and I think it's not shown here while some of my previous ones are). That was for an issue similar to this one by the way.

The reason I don't look into old versions is that sometimes the issue is already fixed but even more important the line numbers are often not accurate anymore, so I would have to go back in GitHub to the version that was used, check that out, then find the bug, then forward again to master, find out where I fixed the bug (which can be at multiple places) and then it's finally fixed. That's not only really annoying work but also it's super easy to prevent this. Anyways, this is for the latest version so it's all good.

I do not have the rights to change the status of tickets, otherwise I would have cleaned up a little already There are some already solved tickets that are still open for example.

Tom W wrote:

Victor - please have a short look at the code contributions from the persons which are currently answering on severe bug reports. I haven't found any and I haven't even even found one ticket which is currently solved from this side.

So: Yes - it is currently difficult to add code to catch the crashes.

But on the other hand it is very easy to compile tvh. "configure && make && make install"

I have seen a very similar behaviour - so it would be interesting to see if similar codepathes are used ....

Open DVBViewer, set device to via SAT>IP, open pre-defined Eutelsat 16E and run a scan of all freqs, right in the middle of process it will crash Tvheadend. Help yourself, I've reproduced it 3 times in a row and you don't need a real LNB pointed to that sat.

Flole Systems wrote:

Check my commit history on GitHub, I think unfortunately not all changesets are displayed here. In fact the last commit was authored by me (and I think it's not shown here while some of my previous ones are). That was for an issue similar to this one by the way.

If they are not displayed - than I cannot talk about. The borders of our repro are the.

The reason I don't look into old versions is that sometimes the issue is already fixed but even more important the line numbers are often not accurate anymore, so I would have to go back in GitHub to the version that was used, check that out, then find the bug, then forward again to master, find out where I fixed the bug (which can be at multiple places) and then it's finally fixed. That's not only really annoying work but also it's super easy to prevent this. Anyways, this is for the latest version so it's all good.

The reason is very clear to me. But from an CM POV this this doesn't makes sense. Your procedure assumes that every single revision is stable, that everyone can switch to latest, that everything works flawlessly with latest. This is not the case.

I do not have the rights to change the status of tickets, otherwise I would have cleaned up a little already There are some already solved tickets that are still open for example.

Victor S wrote:

Open DVBViewer, set device to via SAT>IP, open pre-defined Eutelsat 16E and run a scan of all freqs, right in the middle of process it will crash Tvheadend. Help yourself, I've reproduced it 3 times in a row and you don't need a real LNB pointed to that sat.

Wow - DVBviewer. Is this a windows something prog ?

"Help yourself" ? Actually I dont care if a "TurboSight TBS 6504 DVB-S/S2/S2X/T/T2/C/C2/ISDB" chinamade crap crashes.

You are aware that the error came from the kerneldriver of your card ? Sounds like they are using the outdated (deprecated) old Kernel driver for DVB.

....Holy shit: they are using the "media_built" method. ... and for another card you have to use a special kernel with bin firmware.

Please ask TBS for a working driver for your system. Obviously the card cannot be tuned.

Sure - tvh should not crash when tuning fails. But root cause is "buying china made crap without thinking about driver support".