Bug 508759

(Will explore this further, and report my progress here)

While the timeline shows the video track, and I can as always scroll and play the video track in the Project Monitor before rendering, this is not the case after an Open Recent of that project: the video track will show as all white. 

If anything you want me to try, inform me.
My next steps will be to try another clip, and not render different tracks, and also start the whole project from scratch.

I can't change it myself to "minor", sorry.
Other clips still work perfectly well. Only this one fails.

Going on ... after a dozen of good clips, in a batch of some 8 clips, another one turned out all white. 
It also created a crash report, but kept rendering, despite stating it wouldn't continue after closing the kdenlive window. All those are white, respectively with empty audio tracks (this time).

Therefore, I can't completely exclude that the Anaheim-clip of above was not a problem in itself, but only a consequence of an earlier crash. I'll try again next, from the very start. 
I can't stand in for this, but I never experienced something like this in the years before, using kdenlive, including a batch rendering with submitting multiple files. 

I tried my best to submit a complete bug report, but wasn't allowed to:

Failed to create bug.
Server says: 401 Unauthorized
{"message":"Sorry, but you are not allowed to (un)mark comments or attachments as private.","documentation":"https://bugzilla.redhat.com/docs/en/html/api/index.html","error":true,"code":113}
('report_Bugzilla' exited with 1)

No idea what this means.

Thanks for your report.
Wondering if some of your source clips have encoding issues. 
Can you reproduce 100% of the time with that Anaheim clip ? Is it also reproducible with the AppImage:
https://download.kde.org/stable/kdenlive/25.08/linux/

Also, one thing is not clear for me. You render twice: one for separate audio tracks, and another one for the video ?
For the second rendering operation, you disable audio export to only have the video ?

Thanks for your reply!
Now the matter becomes clearer, I hope. 
I should start by saying that I rendered a good thousand files during the last 7 years with kdenlive, out of which several dozen didn't render properly due to reception errors resulting in encoding issues. Until here, they became visible by a rendering speed of 1 fps and even lower. In all cases graceful degradation.

This actual clip, however, behaves differently. I have by now tried the same .ts sources with 23.08.5 on ubuntu 24.04 instead of fedora 42. And the result is identical. While the file loads in the project bin, shows the content of the video track which can be edited, together with the audio track, without problem, it stops at some moment at rendering. It plays a resulting file including audio, but with video completely in white. When reloading kdenlive and the project, identical to what I observed in 25.08.0 on fedora, everything loads properly, except of the video track in the timeline. It likewise loads, but all white. 
You are right, of course, that it is an encoding error of the source file. Though it is the first time, that certain items, defects of the source data, taken together, produce this outcome. 
I would still consider it a tiny-tiny bug, pointing to a weak point of kdenlive, since the saved, and reloaded, project file (foo.kdenlive) doesn't reconstruct the same state when saving it. Because when saving, the video track was visually okay, with visible video content. Saved and reloaded, the video track is all white. On the screen, the Clip Monitor shows, and plays, the file in the project, allows scrolling it, everything. While the Project Monitor, different from the moment when creating the project, shows an all white track. 
(I'll attach a screen shot of the reloaded project, to hopefully make things easier to understand.)

(Could it be that the second part of your reply refers to my other report, on audio dropouts when loading individual sequences of longer clips as 0000.ts, 0001.ts, 002.ts one by one into the timeline? That is completely different and has nothing to do with this report. Here the source is a singlular .ts file of around 8 GB. 
And while those audio drop outs have occurred in all my previous renditions of this data source at merge points - therefore easily reproducible - here it is a singular, comprehensive source file that sends kdenlive into nirwana.)

Created attachment 184683 [details]
Visual of the reloaded project file (.kdenlive)

(I suggest to disregard my comment 3 - I don't know how to delete it? - for the simple reason that I found out later, that the crashed kdenlive still had some processes running - it actually completed an earlier commenced task after some hours, and completed it error-free. Though it didn't show any window, and therefore I had - as suggested by the bug report - restarted kdenlive. It had started properly, and worked in parallel to the invisible process. At some moment in time, so I found out, this doesn't go though without interference or crash. Sorry for not being aware of that other process still running in the background.)

My excuses, comment 5 isn't correct. But not my fault, this time: The Clip Monitor display is an artefact. As you can try yourself, once a clip has been edited, and saved, and a New project is started, the Clip Monitor still holds the display of the previous project. Make this a real minor bug; since when a new project has been started, the user would expect to see no remnants of the previous project.

(I don't know how to delete a comment, so I rectify it with the following:)
The project Anaheim can be created, timeline can be used, with video and audio, edits can be done according to the liking of the user. The project file can be saved. When loading the project, the Clip Monitor shows the previous clip, the Project Monitor remains white without remedy, and when clicking a clip in the project bin, the Clip Monitor shows the content of the respective clip; overwriting the remnants of the previous clip. 

This doesn't effect the buggy behaviour, however: At "Save" the timeline shows the (edited) video track, very normally, in the timeline, and most obvious, in the Project Monitor. When "Open" is used to load this saved project file, the Project Monitor is all white, from the InPoint onwards.
The only way to make anything but white appear in the Project Monitor is, to start a new project from scratch, and import the source file once again. Then everything is normal; but can be neither rendered, nor saved and (re-)loaded.

What else could I do? The source file plays in kdenlive (Clip Monitor, Project Monitor during the initial editing session), with artefacts, but plays, and so it does in vlc.

This gets utmost confusing. 
How about we delete or close this report, and start from scratch, with the more clear item: For this source clip, it is impossible to "Save" an edited project, and reload ("Open") it again, for whatever purpose, be it further edits or rendering it? 
And this clearly is a bug; if only for a specific, otherwise - despite of artefacts - playable source clip.

... and another one. Sorry, I am not very fast in this, so I had this idea only last night:)
I used ffmpeg on the command line for a quick-and-dirty trial with two edit points:
ffmpeg -i Anaheim.ts -ss 00:06:29 -t 01:48:20 -c:v copy -c:a copy Anaheim.mp4
Went through within a few seconds and plays splendidly. 

Therefore, IMHHO, the initial problem isn't rendering, but "Save". If you can't "Open" a saved project, rendering isn't supposed to work neither.

(Too many things have been reported here, observations, progress, in order to leave a comprehensible bug report behind.
My excuses, I close it. I have already re-opened it as 509101. )

*** This bug has been marked as a duplicate of bug 509101 ***