home
products
contribute
download
documentation
forum
Home
Forums
New posts
Search forums
What's new
New posts
All posts
Latest activity
Members
Registered members
Current visitors
Donate
Log in
Register
What's new
Search
Search
Search titles only
By:
New posts
Search forums
Search titles only
By:
Menu
Log in
Register
Navigation
Install the app
Install
More options
Contact us
Close Menu
Forums
MediaPortal 1
MediaPortal 1 Talk
Bug/Crash submission system
Contact us
RSS
JavaScript is disabled. For a better experience, please enable JavaScript in your browser before proceeding.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an
alternative browser
.
Reply to thread
Message
<blockquote data-quote="krntea" data-source="post: 161430" data-attributes="member: 28550"><p>Hi infinityloop,</p><p> With all due respect, your post displays a lack of understanding of automatically generated bug submission systems, OR you have been mis-informed, and/or you have not had the pleasure of using one. In my posts here I only wish to try and introduce the MP developers to the pleasure that is an automated bug submission system...</p><p></p><p></p><p></p><p>An efficient automated bug reporting system is easy for the end user AND the developer... this thinking that it has to be either hard work for the end user OR the developer is mis-informed.</p><p></p><p>As a software engineer of 13 years, part of my duties were for many years to support a large complex legacy commercial c++ electrical engineering CAD product with many users spread across many countries. The system has the following crash bug submission system embedded in it: <a href="http://www.codeproject.com/debug/crash_report.asp" target="_blank">http://www.codeproject.com/debug/crash_report.asp</a></p><p></p><p>When the program crashed or hung in some part of the world, the user pressed one key: "send" and all <strong>dumps</strong> and machine state info are emailed. If the end user felt like it and had the extra 30 seconds, they also could type in a description of what they were doing. The developers inbox receives the automatically generated dumps and user report (here auto scripts can sort the reports by program version and other info into bug reports seen before or something new to save yet more time, but I wont go into that). The point is that the developer takes a minute to click on the dump file, and it loads up into your favorite debugger (Visual Studio, whatever) and the break point positions the on the offending line where the system crashed or hung. You are then usually minutes away from fixing the bug...</p><p></p><p></p><p></p><p>This is completely incorrect: You have the entire stack trace and all variables that caused and led upto the crash. You also can have system state information at the time of the crash and any third party products that might be influencing the problem - but in 98% of the cases it is usually not necessary to look at this information and neither is it necessary to read the users blurb, that is usually wrong or misleading anyway. All the evidence is before you in the debugger without user explanations necessary in almost all cases.</p><p></p><p></p><p></p><p>Both Incorrect: The report is emailed: you can email them back if you really wanted to: but this is almost never required.</p><p></p><p></p><p></p><p>I am a developer, and as a developer I am lazy: lazy in the way that I want the most fast and efficient algorithm or method of doing things. I do not want to waste time clicking around reading forums full of repeated bug reports all describing the same problem slightly differently, reading long winded reports in bad english from country X etc etc: that support model just <strong>does not scale up</strong> when you have many users to support. As a developer I want and need crash reports with everything that I need to debug them as fast as possible, so I can spend my time developing rather than reacting to bugs all the time. </p><p></p><p>Here is a quick simple test you can do to convince yourself and see that I am not inventing all this: Download <a href="http://www.codeproject.com/debug/crash_report.asp" target="_blank">http://www.codeproject.com/debug/crash_report.asp</a> either run his test program or in 5 minutes you can attach it to any c++ program. Now put in the most nasty hard to find bug you can imagine (or find demonstrated in Dr Dobbs journal), run and crash the program and debug it using the emailed report. You will be shocked how easy and quick it is. Compare that time saving to this forum bug report model... they just cannot compare.</p><p></p><p></p><p></p><p>I agree that a decent bugreport is critical. However MediaPortal does <strong>not</strong> have a decent bug reporting system, and submitting bug reports in a forum highly inefficient and time wasting for both the users AND the developers. What suffers as a result? The stability of Mediaportal: something everyone here wants to see improve, so we are all together on that one.</p><p></p><p></p><p></p><p>How many people have been watching TV in MP in their relax mode, relaxing time with their family and experienced a MP crash - only to restart and continue their relax mode... rather than get off the couch, interrupt the movie, search the forums and face this large complex <strong>barrier</strong> to reporting the problem: </p><p></p><p></p><p>The developers of MP have put the above wall up to <strong>reduce</strong> bad bug reports - which is normal and understandable since it is <strong>very</strong> had to process bug reports using forums even when they are very good. The MP core developers are so overworked under this inefficient system that I am sure they will not even have the time to read this thread! </p><p></p><p>At the moment I use MP at home on an experimental HTPC, had I the tools at home I would debug my crash problems myself (and in the future I hope to have more time to contribute developer skills to the project + get some some development tools on the htpc). However what I have done is looked at all the MP/TV Service generated logs and the source code to try see where MY crash problem is coming from - and I couldn't. Without the debugger and stack trace its extremely hard to do for all but the most obvious problems, as any programmer knows. So how can I or anyone else expect that a written bug report posted in the forum, without dump information and only logs is going to be enough for a MP developer to reproduce the end users environment enough to reproduce the crash, so that they can then use the debugger on it? Its extremely difficult, inefficient and cannot be scaled up. It is also why MP continues to have the same major crash and hang problems that it had months ago when I started using it.</p><p>It is also why major open source projects like Firefox, Azureus etc use automatic bug submission systems...</p><p></p><p>For MP's sake, please consider modernising the bug submission system.</p><p></p><p>Sincerely,</p><p></p><p>Keith</p></blockquote><p></p>
[QUOTE="krntea, post: 161430, member: 28550"] Hi infinityloop, With all due respect, your post displays a lack of understanding of automatically generated bug submission systems, OR you have been mis-informed, and/or you have not had the pleasure of using one. In my posts here I only wish to try and introduce the MP developers to the pleasure that is an automated bug submission system... An efficient automated bug reporting system is easy for the end user AND the developer... this thinking that it has to be either hard work for the end user OR the developer is mis-informed. As a software engineer of 13 years, part of my duties were for many years to support a large complex legacy commercial c++ electrical engineering CAD product with many users spread across many countries. The system has the following crash bug submission system embedded in it: [url]http://www.codeproject.com/debug/crash_report.asp[/url] When the program crashed or hung in some part of the world, the user pressed one key: "send" and all [B]dumps[/B] and machine state info are emailed. If the end user felt like it and had the extra 30 seconds, they also could type in a description of what they were doing. The developers inbox receives the automatically generated dumps and user report (here auto scripts can sort the reports by program version and other info into bug reports seen before or something new to save yet more time, but I wont go into that). The point is that the developer takes a minute to click on the dump file, and it loads up into your favorite debugger (Visual Studio, whatever) and the break point positions the on the offending line where the system crashed or hung. You are then usually minutes away from fixing the bug... This is completely incorrect: You have the entire stack trace and all variables that caused and led upto the crash. You also can have system state information at the time of the crash and any third party products that might be influencing the problem - but in 98% of the cases it is usually not necessary to look at this information and neither is it necessary to read the users blurb, that is usually wrong or misleading anyway. All the evidence is before you in the debugger without user explanations necessary in almost all cases. Both Incorrect: The report is emailed: you can email them back if you really wanted to: but this is almost never required. I am a developer, and as a developer I am lazy: lazy in the way that I want the most fast and efficient algorithm or method of doing things. I do not want to waste time clicking around reading forums full of repeated bug reports all describing the same problem slightly differently, reading long winded reports in bad english from country X etc etc: that support model just [B]does not scale up[/B] when you have many users to support. As a developer I want and need crash reports with everything that I need to debug them as fast as possible, so I can spend my time developing rather than reacting to bugs all the time. Here is a quick simple test you can do to convince yourself and see that I am not inventing all this: Download [url]http://www.codeproject.com/debug/crash_report.asp[/url] either run his test program or in 5 minutes you can attach it to any c++ program. Now put in the most nasty hard to find bug you can imagine (or find demonstrated in Dr Dobbs journal), run and crash the program and debug it using the emailed report. You will be shocked how easy and quick it is. Compare that time saving to this forum bug report model... they just cannot compare. I agree that a decent bugreport is critical. However MediaPortal does [B]not[/B] have a decent bug reporting system, and submitting bug reports in a forum highly inefficient and time wasting for both the users AND the developers. What suffers as a result? The stability of Mediaportal: something everyone here wants to see improve, so we are all together on that one. How many people have been watching TV in MP in their relax mode, relaxing time with their family and experienced a MP crash - only to restart and continue their relax mode... rather than get off the couch, interrupt the movie, search the forums and face this large complex [B]barrier[/B] to reporting the problem: The developers of MP have put the above wall up to [B]reduce[/B] bad bug reports - which is normal and understandable since it is [B]very[/B] had to process bug reports using forums even when they are very good. The MP core developers are so overworked under this inefficient system that I am sure they will not even have the time to read this thread! At the moment I use MP at home on an experimental HTPC, had I the tools at home I would debug my crash problems myself (and in the future I hope to have more time to contribute developer skills to the project + get some some development tools on the htpc). However what I have done is looked at all the MP/TV Service generated logs and the source code to try see where MY crash problem is coming from - and I couldn't. Without the debugger and stack trace its extremely hard to do for all but the most obvious problems, as any programmer knows. So how can I or anyone else expect that a written bug report posted in the forum, without dump information and only logs is going to be enough for a MP developer to reproduce the end users environment enough to reproduce the crash, so that they can then use the debugger on it? Its extremely difficult, inefficient and cannot be scaled up. It is also why MP continues to have the same major crash and hang problems that it had months ago when I started using it. It is also why major open source projects like Firefox, Azureus etc use automatic bug submission systems... For MP's sake, please consider modernising the bug submission system. Sincerely, Keith [/QUOTE]
Insert quotes…
Verification
Post reply
Forums
MediaPortal 1
MediaPortal 1 Talk
Bug/Crash submission system
Contact us
RSS
Top
Bottom
