https://bugs.kde.org/show_bug.cgi?id=407778
--- Comment #10 from Robert <rob...@robertelder.org> --- Hi, Thanks for the response. For the ordering of the group encodings, I would like to cast a vote that the ordering be canonicalized somehow, or at least made predictable so that doing 'save as' with a project with no changes produces a new .kdenlive project with idential hash checksums (just for debugability). I'm fairly sure it's not a bad disk problem, I've experienced this in testing from my SSD and larger spinning disk. Here's the one I'm using now: After doing sudo smartctl -a /dev/sdb SMART overall-health self-assessment test result: PASSED ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000b 100 100 062 Pre-fail Always - 0 2 Throughput_Performance 0x0005 100 100 040 Pre-fail Offline - 0 3 Spin_Up_Time 0x0007 122 122 033 Pre-fail Always - 2 4 Start_Stop_Count 0x0012 098 098 000 Old_age Always - 3200 5 Reallocated_Sector_Ct 0x0033 100 100 005 Pre-fail Always - 0 7 Seek_Error_Rate 0x000b 100 100 067 Pre-fail Always - 0 8 Seek_Time_Performance 0x0005 100 100 040 Pre-fail Offline - 0 9 Power_On_Hours 0x0012 068 068 000 Old_age Always - 14199 10 Spin_Retry_Count 0x0013 100 100 060 Pre-fail Always - 0 12 Power_Cycle_Count 0x0032 099 099 000 Old_age Always - 1990 191 G-Sense_Error_Rate 0x000a 100 100 000 Old_age Always - 0 192 Power-Off_Retract_Count 0x0032 100 100 000 Old_age Always - 28 193 Load_Cycle_Count 0x0012 097 097 000 Old_age Always - 32587 194 Temperature_Celsius 0x0002 115 115 000 Old_age Always - 52 (Min/Max 12/64) 196 Reallocated_Event_Count 0x0032 100 100 000 Old_age Always - 0 197 Current_Pending_Sector 0x0022 100 100 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0008 100 100 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x000a 200 200 000 Old_age Always - 0 223 Load_Retry_Count 0x000a 100 100 000 Old_age Always - 0 SMART Error Log Version: 1 No Errors Logged So, I spent the entire day messing around with this to try and figure out why it was getting corrupted, and I'm pretty sure I've found *a* bug. Not sure if it's the one we're looking for. Long story short is that you should be looking for reproducibility in the ability to open a project, make *absolutely no changes*, then save the file. What I see happening is I can create a new project, add a single clip. Don't add it to timeline, add to project. Save project as. Re-open new project, change nothing, save as. Repeat this like 6 times, then diff the project files and you'll see a trend like this: a.kdenlive: <producer id="producer0" in="00:00:00.000" out="00:21:54.121"> b.kdenlive: <producer id="producer0" in="00:00:00.000" out="00:21:54.087"> c.kdenlive: <producer id="producer0" in="00:00:00.000" out="00:21:54.054"> d.kdenlive: <producer id="producer0" in="00:00:00.000" out="00:21:54.021"> e.kdenlive: <producer id="producer0" in="00:00:00.000" out="00:21:53.987"> f.kdenlive: <producer id="producer0" in="00:00:00.000" out="00:21:53.954"> g.kdenlive: <producer id="producer0" in="00:00:00.000" out="00:21:53.921"> Note that the time length keeps going down. If you add the clip to the timeline, you can see it move around and if you add multiple clips, empty spots slowly creep in. I did some tests to see if the change is deterministic, and doing 6 tries of save as from a single point seem to deterministicly change the track length. I also noticed that sometimes when I add a clip there is a message about creating a 'profile' for the clip. Sometimes it is a popup dalog you have answer, and sometimes it's a small sub-window in the clips area (why the difference?). I found that if you click cancel or ignore the message you get this time 'drifting' effect after save, but it never asks for a profile again. If I click 'create' the profile, it seems to stop drifting on multiple saves, so perhaps I really *have* to create a profile? If so, that message should be much more forceful rather than allowing subtle drifting and blank parts in the track. Another important point: Sometimes, I don't get that 'create profile' message at all. For example, if I add the Screencast 2019-05-21 14:55:40.mp4 video, then save exit. Re-open project, then add VID_20190520_093206251.mp4, I get *absolultely no* message about creating profiles. Whereas, if I add VID_20190520_093206251.mp4 first I get a mandatory prompt for it. Here are the source videos to test with: wget "http://www.robertelder.ca/Screencast 2019-05-21 14:55:40.mp4" wget "http://www.robertelder.ca/VID_20190520_093206251.mp4"; No project file is necessary, create a new project from scratch. Now, that's one definite issue, but unfortunately, I was not able to reproduce the corruption issue all day today when launching kdenlive appimage from the command-line. I can often re-produce it when launching kdenlive by double-clicking on a .kdenlive project though. I have install .desktop file associated as document above in the first post. I don't know what the difference is between opening via command-line, and through the 'open with' association. Sometimes, I can open a project no problems from the 'open with' file association, and edit, encode whatever no problems. I even logged the environment variables from using the open with method, then set them manually in shell and tried to reproduce that way. Could this be a race condition? My working theory is that upon opening the project, kdenlive is somehow re-computing the 'lengths' of videos in some non-determinstic way. Most of the time, I see the clip length trend down after re-saving multiple times, but I have logged at least one instance of it going up. If one clip ends up with an impossible overlap, impossible high length, can that cause the 'Invalid clip' error? -- You are receiving this mail because: You are watching all bug changes.
