Premiere Pro Won't Play Preview of Timeline Past 35 Minutes

[brandonb96942845]

Alright, so I've got another weird one.

I've edited products before that were longer than this with no problem, so I'm at a loss what the problem is this time. I've got a Premiere timeline that's for a 60-minute program, but when I'm previewing it, around the 34 minutes 46 seconds mark, the audio just stops, and when I hit the space bar to stop playback it won't start again, and the VU meter stays at wherever it was last.

If I try to hit the play button again or hit the spacebar to get the preview to resume, the play icon will turn to a stop icon under the Program window, but nothing I do will get it to play again. If I try to close Premiere, it just freezes and I have to force it to close.

Before anyone asks, I've verified that it's not a glitch with the media track at that spot because I've moved it back and forth and even trimmed out a good bit of footage, and the problem always occurs at the exact same spot: as near as I can figure, 34:46:11.

Anybody else run into this?

[Sumeet Kumar Choubey]

Hi brandonb96942845,

We're sorry to hear about this. Is this happening with any specific project or all the projects? Also, let us know the version of Premiere Pro that you are using & the system specs.

Thanks,

Sumeet

[brandonb96942845]

This was version 22.3 of Premiere Pro (and of Media Encoder as well, since it stopped in the exact same place). This only happened with one project since it was the first one I'd tried to work on after upgrading to 22.3, but I can confirm it's not specific to a single PRPROJ file because I imported everything over into a completely new file and it still happened in the exact same spot. I can also confirm that it's not a glitch with the media file or with anything at that specific timecode--I moved things around, replaced files, and at one point even created "dead air" at that point just to see (I deleted all content for five seconds on each side of the problem timecode), and it still froze.

System specs aren't at issue because the same file had the same problem on three different systems of varying specification and capability.

[R Neil Haugen]

I've seen a couple other users post this ... very odd!

Neil

[brandonb96942845]

Definitely looks to be a bug with Premiere and Media Encoder 22.3

Like other users have said, I downgraded back to 22.2 and the problem disappeared. So whatever it is, it's definitely specific to 22.3

[R Neil Haugen]

He has a very good reason to be asking for system specs ... which is why everyone with an issue should ALWAYS provide complete system specs.

It isn't to blame your hardware, it's to identify which hardware has the issue. One of the first things in Troubleshooting 101. Some hardware may be affected, some might not, and you can't know until you know which hardware is in use.

What a user should assume is there is something different about your situation than anything the engineers have available ... or they'd already know about it. We users have to give full details so they know how to setup to replicate any issue.

Then they can fix it.

Neil

Neil

[brandonb96942845]

Thanks for that Neil, but I work in IT so I understand far better than the average user why they always ask for system specs. (At most companies I'm the equivalent of a Tier III specialist.)

Normally I'd be happy to oblige, but in this case the three system configurations are so completely different in terms of their processors, GPUs, types and amounts of RAM, types of displays (and so forth) that I can comfortably eliminate hardware as a factor. I'm positive this isn't being caused by a hardware issue.

[R Neil Haugen]

Brandon,

Remember, forums like this are not private conversations. The are intended to be read and used by a lot of people, most of who never actually post. So intentionally I work to get the broadest communications going in any thread I participate in here. That's the educational part of this user-to-user forum.

And of course, as you didn't mention previously that you'd experienced the issue on three different systems, there's no way we could have known that. And honestly, including that in the original post would have been a very useful thing.

As to your statement, "... but in this case the three system configurations are so completely different in terms of their processors, GPUs, types and amounts of RAM, types of displays (and so forth) that I can comfortably eliminate hardware as a factor. I'm positive this isn't being caused by a hardware issue." ...

Even that it was on say a Windows machine could be informative and useful. It really is best if users don't try to out-guess what the engineers need. Because very clearly, if you don't give the information, they will still have to ask!

How in the world are they supposed to just "know" this stuff? What you've done, what hardware, if you don't tell them?

I've never understood why some users find it painful or even an insult to be asked to provide the hard data needed for troubleshooting.

Neil

[brandonb96942845]

For the record, I don't find it "painful" or "an insult"--I fully understand why I'm being asked. But I also understand when something is a factor and when something isn't--and when I've determined to my satisfaction that the hardware isn't an issue, I'm not going to take the time to gather up the full specs on three separate systems.

If it was a single system, I'd be more than happy too because then, I wouldn't have any way to know what might or might not be impacting it, and it might genuinely be a hardware issue. (In fact at first I was tempted to blame the GPU, as much as I love nVidia they aren't infallible.)

As to your statement, "It really is best if users don't try to out-guess what the engineers need," I've done enough troubleshooting (in addition to everything I'm also a member of the Windows Insider Program and have been for eight years now) to know that one of the first things engineers usually do is look to see if there's some quirk to a particular system that might be causing the particular problem, whether it's unique hardware or some app that might be causing some critical process to crash.

Having said that, I've also watched with my own eyes that some software engineers (particularly the ones at Microsoft) are very quick to push back and say "it's not our software, it's your fault" before they even bother taking a look to see if, yes, their own product might be at fault after all. That's why at my ripe old age of 36 I've decided not to waste time writing in to a support forum or support e-mail at all until after I've exhausted every means at my disposal of isolating the problem, and I don't provide system specs unless I'm sure some piece of it is at fault. In this case, I've seen the problem on three different systems, one of which dual-boots between Windows 10 and Windows 11, and I see it on both OS's.

Will every user be this thorough? Probably not. Will every user have my IT background and have the same instinct I have for what might and might not be at fault? Probably not. Does that mean I should behave like any other user who doesn't know what they're talking about? Absolutely not.

So please save the lectures for people with less experience.

[R Neil Haugen]

The "lecture" here is for people with lesser experience, as I've noted.

And the point I've tried to make ... it doesn't make one bit of difference your experience, mine, Jack Frost's. For engineers to be able to zero in on an issue, they need to start with the basics. They cannot outguess us users. Just because we have data to hand on puzzling the problem doesn't give that data to the engineers.

Nor will they have a clue we've tested for that information if we don't give that in the post about the problem.

I have a great deal of experience troubleshooting in Premiere. And many of the engineers even know who I am. I've met a fair number in person over the years. So should I insist that I shouldn't have to add the testing I've done when posting of a problem here and on the UserVoice?

Absolutely not. If I've got an issue to post ... which I do quite regularly! ... I always assume I should give the full details of the issue, the troubleshooting I've done, the results from each test. So that way the engineers can read the data, and set about quickly to replicate.

No engineer will have clue one whether any of us users know what we're talking about. How could they? And ... well, ego (and emotion in general) isn't a valuable part of either troubleshooting or forum discussions.

Neil

[Peru Bob]

I respect that your computer knowledge is greater than the average Joe, but in the time it took you to tell us why you didn't post the system specs, you could have posted the system specs.

If the specs are as varied as you say they are, it would help the Adobe engineers to know that.  More data means quicker bug fixes.

[Baffy19]

Solving one or three of the presented specifications will not solve the problem globally. That's actually the problem of engineers who are trying to fix for a specific PC model. Users are not required to provide their specifications. In scientific terms, engineers create a product that should work on any machine that meets the specifications according to the Adobe help. And not to demand: "Tell us your specification and we will fix it." And it's okay if another user starts having problems that didn't exist before. Absurd, but not professionally solved tasks. It is very small and it will always be so with the product until engineers start creating a product for systems, and not for a specific PC. Sorry, Microsoft engineers don't ask each user what your specification is, let us know and we will fix it. THE PROBLEM IS SOLVED GLOBALLY.

[Francis-Crossman]

We have identified that the issue is related to audio.  Can you tell me about your audio channelization.  Do you have source clips with multichannel audio?  Is your sequence configured for more than stereo.  We are working quickly on a fix.

[brandonb96942845]

I figured it was an audio glitch of some kind since the VU meter got stuck wherever it was at the moment the problem occurs.

The sequence and source clips are all dual-channel stereo (just left and right channels and that's it). I'm not sure if this might make a difference but one of the sequences this happened on had a bunch of audio tracks (like six or seven), but still just stereo audio files on each one.

And also worth mentioning is the fact that this happened even when there was no audio (or any media period) at the point where the glitch seemed to happen.

[Peter Kinoy]

Wow, I am going crazy with this exact same problem. I tried replacing footage, re-encoding clips... I thought it was bad media, but even when I cut that media out completely when the sequence hit approx 34 minutes it stops playing sound, and then can't play anything, and I have to force quit.

[Jeff Bellune · Accepted solution]

The new update to 22.3.1 supposedly fixes this issue.

[Peter Kinoy]

I am experiencing what sounds like the exact same issue as Brandon. Sound cutting out at about 34:40, and I cannot compress the sequence past 34:40 either, compressor stops there.

And it seems to be only on two particular sequences in one particular project. These sequences played fine in the earlier version of Premiere.

specs:

The project is very large, 170.MB. My dialogue tracks are mono, music track stereo.

I am running version 22.0 Adobe Premiere.

I am running on an iMac 2020

MacOS 12.3.1

I am not sure what specs are most helpful: graphic display ADM Raedon Pro 5700

Audio is through Audiengine D1

If anyone can help, I would most appreciate it.

thanks, Peter Kinoy

[Peru Bob]

Update to version 22.3.1

[Baffy19]

Thanks Bob for the prompt troubleshooting.

[R Neil Haugen · Accepted solution]

The 22.3.1 version was specifically pushed out due to the 34 minute issue. All users should switch, and if it works, great.

If not, post away please!

Neil

[DocWalls]

Exactly the same issue at exactly the same point on the timeline - 34:46:13. When it hangs in sarts looping a one second audio segment and then PPro locks up and has to be force closed. It has taken 2 days of my life to figure out that it was the time stamp and not the actual media. The only other thing that was unusual about this project was I had to render my audio to get waveforms. None of the usual workarounds worked. Be interesting to know if the two are related. I have downloaded the patch, so fingers crossed.

[R Neil Haugen]

Francis Crossman just shook his head in amazement at that bug. It took like four things to trip it ... including something with audio, and three other things I forget. So replicating it had the staff going nuts until they tumbled as to what it was.

Then ... they could replicate first time every time. Which made going for the fix a lot easier.

Neil