SUMMARY *** NOTE: If you are reporting a crash, please try to attach a backtrace with debug symbols. See https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports *** STEPS TO REPRODUCE 1. Open KDenlive 2. Drop in some videos to edit 3. Try editing OBSERVED RESULT Crashes and stops responding and Microsoft close window reports to microsoft the issue... EXPECTED RESULT I am expecting it to work but like the previous version I was told to update from, the same issue exists. SOFTWARE/OS VERSIONS Windows: 10 ADDITIONAL INFORMATION I reported the same bug and got told to update. Did that and the same problem exists. It is clear to me that there is something fundamentally wrong in your development team as this problem was IMHO introduced by some smart Alec trying to show off their new found skill. All they are doing, much like in the google browser team, is cause problems for most people using software. The thing that got me was the fact that on an octa core machine with plenty of RAM took over 8 minutes to join three videos together in one single stream with MP4 compression as set by your guys, When I first used KDEnlive, it took less than 2 minutes for the same type of files, therefore you have introduced problems in to your rendering engine. I also find that I am having to clear out garbage left behind that your software should remove, I regained over 40GB of drive space because your housekeeping is frankly, crap.
Tried to render some files, this is what I get. Rendering of C:/Users/markg/Videos/clip02.mp4 crashed [mjpeg @ 0000018c6b393a40] error count: 67 [mjpeg @ 0000018c6b393a40] error y=27 x=39 Current Frame: 10341, percentage: 19 [mjpeg @ 0000018c6b60f780] Found EOI before any SOF, ignoring [mjpeg @ 0000018c6b60f780] No JPEG data found in image Current Frame: 29251, percentage: 56 [mp4 @ 0000018c64f3ec00] Timestamps are unset in a packet for stream 1. This is deprecated and will stop working in the future. Fix your code to set the timestamps properly [mp4 @ 0000018c64f3ec00] Encoder did not produce proper pts, making some up. SORT THIS OUT as in go back to your roots and back to a stable version that actually worked like last years...
It looks like you are on Windows 10. Correct? Please try the following if you have the install version of Kdenlive: delete the folder "C:\Program Files\kdenlive". Then re-install the latest Kdenlive version. Once done go to "Help -> Reset Configuration..". Then try again. The 40GB could be cached data. Go to "Settings -> Manage Cached Data.." and you can clean the cache as you need. Let's see if the render crash still occurs.
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
This needs no more info than I provided. If you want more info, then your bug tool needs some kind of memory dump feature that produces a set of data packets that can be automatically uploaded with the report from the "Report a bug" in the menu. This "bug" occured after an update, two versions ago and its annoying to put in processing a set of files that take an hour to process to have the resulting file output corrupt and unusable with KDE complaining that it crashed. How on earth am I supposed to tell you more information when your system does not provide that required information??? Tell me that sherlock.
(In reply to mark.giblin@yahoo.co.uk from comment #4) > This needs no more info than I provided. > > If you want more info, then your bug tool needs some kind of memory dump > feature that produces a set of data packets that can be automatically > uploaded with the report from the "Report a bug" in the menu. > > This "bug" occured after an update, two versions ago and its annoying to put > in processing a set of files that take an hour to process to have the > resulting file output corrupt and unusable with KDE complaining that it > crashed. > > How on earth am I supposed to tell you more information when your system > does not provide that required information??? > > Tell me that sherlock. Needs info means that you should give feedback to what was suggested in the comment above. Did you try that?
I found one possible problem and its to do with KDENLive itself, when there is an ethernet connection is when the problem occurs, when NO INTERNET the software renders video. So whatever it is in the software that is phoning home needs removing as it is the one possible issue thats causing the crash to occur.
Are you still experiencing this? If yes, please comment on issue 447854 since it is similar to this one but with more debug information. *** This bug has been marked as a duplicate of bug 447854 ***
First of all I kindly ask you to follow the Code of Conduct in your reports (https://kde.org/code-of-conduct/), we are not going to continue the conversation if you don't use a decent and respectful language. Kdenlive is an open-source project with a small developer team of 1-3 active devs spending their spare time and we are not able to fix everything we want as fast as we want. At least we are not aware of all bugs and we need reports like yours to make Kdenlive better. It is up to you to use a different software if you are not happy with Kdenlive and it's community. However coming to your problem: Kdenlive uses the network connection only for very few features and only on your explicit request (eg. if you download new render presets). Hence I would be really surprised if the problem is on Kdenlive's side. I rather suspect a different software (maybe malware?) using CPU or RAM resources if there is a network connection and Kdenlive can't use the resources for rendering then. I think it should be possible to investigate this thesis eg. with the Windows Taskmanager. Please check this and give us feedback and set the status back to REPORTED or to RESOLVED NOT A BUG Also please send us the link to your former bug report (the one where you "got told to update"). In general it would be good to continue the conversation in the original report if the issue is the same instead of opening a new one. Please read https://kdenlive.org/en/bug-reports/ and https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging if you have any questions about the bug reporting process.
I have supplied information about this problem yet your bug thing doesn't seem to grasp this fact. WHEN there is INTERNET the editor takes 30 minutes to render a file THEN crashes. WHEN there IS NO internet, the editor takes a couple of minutes to render the file WITHOUT CRASHING. The problem... YOUR SOFTWARE IS PHONING HOME AND CAUSING THIS ISSUE. Comprende?
If you would have read my comment above, you would know what info is missing and that Kdenlive is not "phoning home". The bug track does not send these remainders for no reason, but because you have neither replied to the comment not correct the reports status. However as annonced we are going to stop the conversation here now due to violation of the code of conduct and disrespectful language.
If you read the comment I made, the crashing happens when there is an internet connection available, it also takes a very long time compared to when no internet. There is an obvious issue with this on windows 10 when there is an internet connection available. The problem is not resolved.
(In reply to Julius Künzel from comment #12) > If you would have read my comment above, you would know what info is missing > and that Kdenlive is not "phoning home". The bug track does not send these > remainders for no reason, but because you have neither replied to the > comment not correct the reports status. However as annonced we are going to > stop the conversation here now due to violation of the code of conduct and > disrespectful language. There is no disrespectful language, this is pretty much a case I find with all Linux devs who don't want to fix their shoddy work.
If you'd like to help the developers get this issue resolved for you, you're going to need to be more respectful and provide answers to their specific technical questions, not repeat that you've already provided all the information. Evidently it's not enough if the developers are asking for more. Also if you open any more bug reports in the future, please try to avoid insulting people who are providing you with software for free; that's probably not the most effective way to get what you want. :) It may provide momentary catharsis, but as you can see, nobody wants to bend over backwards to help you with your problem.