I am struggling to find a reason for an error on the "Expand Clip" function after placing an item from a library on a new timeline. The library process works fine when sending a few clips to the library and then retrieving them in a new sequence. However, the failure occurs when I try to expand the clips. Details: There are enough tracks to support the expansion. The clips are proxy clips. The error message is as follows: Cannot open file Bryce Canyon/Processed Videos/Pxl 20241110 182753272.Ts.mp4 The directory for the .mp4 is fully accessible, as files appear fine on all timelines. Watch this Unlisted Youtube video for the live example https://youtu.be/no1oDtQEijo
Thank you for reporting. I followed your video and what I see is that you have two points/dots in the file name … 182753272.Ts.mp4 (.Ts.mp4). Maybe that could be the issue. Rename the file to … 182753272-Ts.mp4 and try again. If that is not working, can you upload the mlt file so I can test.
Created attachment 177762 [details] 3m2xydyc.png Thanks for your response. YES! I tried the rename and it solved the issue. However thinking I might write a user story about the naming conventions handling native file names as there is no predictability on how devices name their files natively. The fact that users may not know to rename files on import, could present a feature function issue. Out of interest here is a directory with the native Google Pixel naming convention. Certainly! Here's a more professional version: I am considering writing a user story addressing the handling of native file names, as there is currently no predictability in how devices name their files. This unpredictability could lead to feature functionality issues, particularly if users are unaware of the need to rename files upon import. Devices often use detailed naming conventions to include metadata such as timestamps, which can result in file names with multiple periods. Samsung Galaxy Series: Samsung devices often use detailed file naming conventions for their media files. Sony Xperia Series: Sony Xperia smartphones are known for their intricate file naming structures. OnePlus Devices: OnePlus smartphones also tend to use complex file naming conventions. For reference, here is a directory showcasing the native Google Pixel 8 naming convention. ------ Original Message ------ From "emohr" <bugzilla_noreply@kde.org> To rockinjeff@gmail.com Date 2025-01-27 11:21:13 AM Subject [kdenlive] [Bug 499171] Expand Clip Error >https://bugs.kde.org/show_bug.cgi?id=499171 > >emohr <fritzibaby@gmx.net> changed: > > What |Removed |Added >---------------------------------------------------------------------------- > Keywords| |triaged > CC| |fritzibaby@gmx.net > Component|Title Clips & Subtitles |Project Bin & Import > >--- Comment #1 from emohr <fritzibaby@gmx.net> --- >Thank you for reporting. >I followed your video and what I see is that you have two points/dots in the >file name … 182753272.Ts.mp4 (.Ts.mp4). Maybe that could be the issue. Rename >the file to … 182753272-Ts.mp4 and try again. If that is not working, can you >upload the mlt file so I can test. > >-- >You are receiving this mail because: >You reported the bug.
Thank you for the feedback. I set the issue to “confirmed”. Feel free to update this bug with a user story so we have all together. We have to check if device file naming in general is an issue on other places as well. I can change the title of this bug and change it to wishlist once you have uploaded the user story.
Please find attached the user story from my Google Docs https://docs.google.com/document/d/1dmY5OwGphpLwwRkXBoNL7URWm-fTyuPlO-929Y58cas/edit?usp=sharing
Created attachment 177763 [details] attachment-555328-0.html I have put a link in the Kdnelive portal linking my Google Docs user story https://docs.google.com/document/d/1dmY5OwGphpLwwRkXBoNL7URWm-fTyuPlO-929Y58cas/edit?usp=sharing Best Jeff Jeffrey Krebs CPO E: jeff.krebs@bridgedigitalinc.com M: 647 783 2228 www.bridgedigitalinc.com linkedin icon <https://www.linkedin.com/in/jeffrey-krebs-0063bb6?lipi=urn%3Ali%3Apage%3Ad_flagship3_profile_view_base_contact_details%3BJxM5E9g1RhSJnFWsZBCMFw%3D%3D> ------ Original Message ------ From "emohr" <bugzilla_noreply@kde.org> To rockinjeff@gmail.com Date 2025-01-28 8:43:30 AM Subject [kdenlive] [Bug 499171] Expand Clip Error >https://bugs.kde.org/show_bug.cgi?id=499171 > >emohr <fritzibaby@gmx.net> changed: > > What |Removed |Added >---------------------------------------------------------------------------- > Status|REPORTED |CONFIRMED > Ever confirmed|0 |1 > >--- Comment #3 from emohr <fritzibaby@gmx.net> --- >Thank you for the feedback. I set the issue to “confirmed”. Feel free to update >this bug with a user story so we have all together. We have to check if device >file naming in general is an issue on other places as well. > >I can change the title of this bug and change it to wishlist once you have >uploaded the user story. > >-- >You are receiving this mail because: >You reported the bug.
Thanks Jefferey for your detailed report. In fact the bug has nothing to do with file names, but is a problem with library clips incorrect handling of proxy clips. Took me a while to reproduce and understand. Problem happens if you do the following from a blank project: * Add a clip to bin, proxy it and put it in timeline. * Save project in the same folder as source clip (or a parent folder) * Close project * Reopen project * Create the library clip from the proxied timeline clip * Then the created library clip will refuse to expand. I am working on a fix, thanks
Git commit e3eace2ab1a9e8e14610113038b3ff6439ef97d9 by Jean-Baptiste Mardelle. Committed on 30/01/2025 at 12:24. Pushed by mardelle into branch 'master'. Correctly fix path for proxied clip inside a playlist clip like in library Existing playlist clip will still have the bug, only newly created playlist clips will work fine M +11 -0 src/bin/playlistclip.cpp M +4 -0 src/bin/playlistclip.h M +15 -7 src/timeline2/model/timelinefunctions.cpp M +3 -3 src/timeline2/model/timelinefunctions.hpp M +13 -3 src/timeline2/view/timelinecontroller.cpp https://invent.kde.org/multimedia/kdenlive/-/commit/e3eace2ab1a9e8e14610113038b3ff6439ef97d9
Created attachment 177834 [details] attachment-942315-0.html This is great I'm glad you were able to find it. Would love to connect sometime. On Thu, Jan 30, 2025, 4:24 AM Jean-Baptiste Mardelle < bugzilla_noreply@kde.org> wrote: > https://bugs.kde.org/show_bug.cgi?id=499171 > > --- Comment #7 from Jean-Baptiste Mardelle <jb@kdenlive.org> --- > Git commit e3eace2ab1a9e8e14610113038b3ff6439ef97d9 by Jean-Baptiste > Mardelle. > Committed on 30/01/2025 at 12:24. > Pushed by mardelle into branch 'master'. > > Correctly fix path for proxied clip inside a playlist clip like in library > Existing playlist clip will still have the bug, only newly created playlist > clips will work fine > > M +11 -0 src/bin/playlistclip.cpp > M +4 -0 src/bin/playlistclip.h > M +15 -7 src/timeline2/model/timelinefunctions.cpp > M +3 -3 src/timeline2/model/timelinefunctions.hpp > M +13 -3 src/timeline2/view/timelinecontroller.cpp > > > https://invent.kde.org/multimedia/kdenlive/-/commit/e3eace2ab1a9e8e14610113038b3ff6439ef97d9 > > -- > You are receiving this mail because: > You reported the bug.
Git commit 71da7364f51e0602708693de90da283b1c1630fd by Jean-Baptiste Mardelle. Committed on 30/01/2025 at 20:48. Pushed by mardelle into branch 'release/24.12'. Better fix for expand library clips broken with proxies FIXED-IN: 24.12.2 M +11 -0 src/bin/playlistclip.cpp M +4 -0 src/bin/playlistclip.h M +32 -2 src/timeline2/model/timelinefunctions.cpp https://invent.kde.org/multimedia/kdenlive/-/commit/71da7364f51e0602708693de90da283b1c1630fd
Git commit f4bd5f93123eaa4e8b3ac2cc123b8a195fde1a67 by Jean-Baptiste Mardelle. Committed on 30/01/2025 at 20:49. Pushed by mardelle into branch 'master'. Better fix for expand library clips broken with proxies FIXED-IN: 24.12.2 M +11 -0 src/bin/playlistclip.cpp M +4 -0 src/bin/playlistclip.h M +32 -2 src/timeline2/model/timelinefunctions.cpp https://invent.kde.org/multimedia/kdenlive/-/commit/f4bd5f93123eaa4e8b3ac2cc123b8a195fde1a67
You can test if the issue is fixed with the daily build https://cdn.kde.org/ci-builds/multimedia/kdenlive/master/windows/. Download the 7zip file (144MB) as standalone so you have not to install Kdenlive.