• Global community
    • Language:
      • Deutsch
      • English
      • Español
      • Français
      • Português
  • 日本語コミュニティ
    Dedicated community for Japanese speakers
  • 한국 커뮤니티
    Dedicated community for Korean speakers
Exit
1

Using track select tool is incredibly slow while ripple delete is instant

Explorer ,
Aug 27, 2024 Aug 27, 2024

Copy link to clipboard

Copied

Using the track selection tool on a large number of edit points (you can see in my screenshot I have 2h worth selected) takes an incredibly long time to move, more often than not "crashing" (and sometimes even hard crashing) premiere. Meanwhile moving clips using a ripple delete or the ripple edit tool is basically instant.
I understand moving a large amount of clips might require a lot on the back end and hold no real expectations of "instant" across the board, but one being basically instant while another constantly crashes prem seems a bit strange, is it because using the track selection tool is directly interacting with the clips via the UI?.
I guess in addition to this it should be mentioned that grabbing a large number of clips and attempting to move them also drags the premiere UI to a grinding halt - the more clips you grab the more the user experience tanks.

This behaviour has been getting progressively worse and makes adjusting large timelines incredibly painful.
This behaviour can be seen in both v24.6 and the current v25 beta.

7900X 12-Core Processor
96.0GB Ram
everything on an ssd & prores proxied, etc etc

Bug Needs More Info
TOPICS
Editing and playback , Performance or Stability , User experience or interface

Views

97

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines

correct answers 2 Pinned Replies

Adobe Employee , Aug 30, 2024 Aug 30, 2024

Hi @Tom_edit,

Can you try copying and pasting the clips into a new sequence? What kind of media is it? See, How do I write a bug report?

 

I hope the team can assist you soon. Sorry for the trouble.

 

Thanks,
Kevin

Status Needs More Info

Votes

Translate

Translate
Adobe Employee , Sep 03, 2024 Sep 03, 2024

Howdy @Tom_edit,

Thanks for the reply. Are these 4K or larger files? If so, you may want to increase the RAM to see if your timeline performance improves. An amazing amount of RAM is required to edit a Long GOP sequence at 4K at feature-length durations (my observation, anyway). You should also reboot the computer throughout the day to refresh the RAM.

 

I hope the advice helps. Sorry for the trouble.

 

Thanks,
Kevin

Votes

Translate

Translate
4 Comments
Adobe Employee ,
Aug 30, 2024 Aug 30, 2024

Copy link to clipboard

Copied

Hi @Tom_edit,

Can you try copying and pasting the clips into a new sequence? What kind of media is it? See, How do I write a bug report?

 

I hope the team can assist you soon. Sorry for the trouble.

 

Thanks,
Kevin

Status Needs More Info

Votes

Translate

Translate

Report

Report
Explorer ,
Sep 01, 2024 Sep 01, 2024

Copy link to clipboard

Copied

Hello @Kevin-Monahan 
Placing it within a new sequence changes nothing unfortunately, the issue stems purely from the amount of clips selected and attempting to be moved; selecting less causes less lag & delay, selecting more makes the issues worse. I can even disable or even offline everything in the nest and it still occurs
This is similar behaviour to the issues here where performance worsens the larger a sequence gets.

The clips in my example are a multicam sequence containing a mix of things, H.264 4:2:2 from sony cameras, HEVC 4:2:0 from gopros,  etc - all proxied to prores but this issue isn't really file format dependent from my experience and just happens with anything once the amount of edit points gets high enough. Even a multicam with only two tracks just containing camera footage will run into this issue once the timeline gets big enough.

My systems;
Windows, 7900X, 4070ti Super, Driver ver 555.99, 96.0GB Ram, mix of internal m.2 ssd & external usb3.2 ssd
&
Windows, 5900X, 4070ti Super, Driver ver 560.81, 128.0GB Ram, mix of internal m.2 ssd & external usb3.2 ssd

Steps can be a little difficult to reproduce as you need to be working on some larger projects to start running into it - and admittedly it's gotten slightly better in more recent v25 beta releases compared to when I wrote this report, although it is still occurring and is still especially bad on v24.6.1

Votes

Translate

Translate

Report

Report
Adobe Employee ,
Sep 03, 2024 Sep 03, 2024

Copy link to clipboard

Copied

Howdy @Tom_edit,

Thanks for the reply. Are these 4K or larger files? If so, you may want to increase the RAM to see if your timeline performance improves. An amazing amount of RAM is required to edit a Long GOP sequence at 4K at feature-length durations (my observation, anyway). You should also reboot the computer throughout the day to refresh the RAM.

 

I hope the advice helps. Sorry for the trouble.

 

Thanks,
Kevin

Votes

Translate

Translate

Report

Report
Explorer ,
Sep 03, 2024 Sep 03, 2024

Copy link to clipboard

Copied

LATEST

Hello @Kevin-Monahan thank you again for your reply.

My apologies, yes 4k footage, I accidently omitted that.

 

I however have no reason to believe it is a ram related issue, at least not a user facing one; on the one machine I have over 80GB allocated and on the other 110GB and the same issue persists - even as soon as premiere is opened on machine start up (nevermind the fact that premiere never seems to allocate more than 15-25gb of ram anyway).

But again, this issue can be seen performing completely differently across different versions of premiere, as well as the fact that my underpowered 8gb m2 macbook air that can't even really playback my timeline, can zip around the timeline like it's nothing.

 

I should also note I've seen this exact same behaviour happen on an all prores timeline (admittedly not recently bc my filesizes are far too large now to completely rerender everything to prores, but hopefully that helps my claim that I do not believe it's a clip type related issue)

Votes

Translate

Translate

Report

Report