Reaper will not close on certain projects at certain zoom levels (FIXED)
This is one of the weird ones... I was told to re-post it here. This will be long
I have a project where version _26 will close just fine, and version _27 will not. both had the same amount and instance of plugins. Even if I remove all plugins using Fx Bay, _27 will not close. And what's real interesting is that after I removed all the plugins from _27, Reaper now fails to show up in Task Manager Processes or Details tab. And this is even stranger, even tho Reaper is greyed out with the black Initializing splash thing, I can still scroll through the Track panel in the greyed out project, but can't close Reaper. Had to reboot to get Reaper to go away. I really hope Reaper doesn't get like Altium... that'd suck.
See vid.
Tried Open with no FX - still hung.
So here's two files - two different versions of the same file. All FX deleted. Both are otherwise the same. One closes and one does not.
xpander mentioned:
"Yep, zoom and several of the track heights. The one which won't close on your end is zoomed way closer and has some of the tracks much taller. The one which closes has all the tracks small and the whole project length visible in Arrange.
However, on my end those don't matter. Both projects open and close normally here.
Would it make any difference if you zoom out on the not closing project and set tracks small, similar to what they are in the closing one...then trying to close it? "
So I took his advice and collapsed all the tracks in wontclose_nofx.rpp. Now it closes. But only when I scroll to the end of the project in the TCP
Also noticed something weird. When I open wontclose_nofx.rpp I get about double the CPU Power Usage in Task Mangers idiot screen - like 16% then drops to 14%.
I can hear the system fan/CPU fan increase in speed.
When I open willclose_nofx.rpp it hangs at around 7%...
Now if I open wontclose_nofx.rpp and collapse all the tracks (using CNTL Mousewheel) it drops to 7% and NOW WILL CLOSE.
In the real Task Mangler:
For wontclose_nofx.rpp I get:
reaper.exe -
CPU = 13
Memory (active...) = 456,404K
User objects = 303
GDI = 262
reaper_host32.exe
CPU = 00
Memory (active...) = 25,192
User objects = 7
GDI = 28
For willclose_nofx.rpp I get:
reaper.exe -
CPU = 3
Memory (active...) = 453,280
User objects = 300
GDI = 254
reaper_host32.exe -
CPU = 0
Memory (active...) = 25,204
User objects = 7
GDI = 28
So now - - if I open wontclose_nofx.rpp and after using CNTL Mousewheel to collapse all the tracks, after the collapse I get:
reaper.exe -
CPU = 3
Memory (active...) = 458,232
User objects = 300
GDI = 254
reaper_host32.exe -
CPU = 0
Memory (active...) = 25,432
User objects = 7
GDI = 28
.. and then it will close.
At different zoom levels I get different CPU utilization.
So if I open wontclose_nofx and collapse it And scroll to the top of the TCP it goes back up to 9-12% and will not close.
Now if I scroll to the bottom of the TCP to the last track, the CPU drops to 3 and I can now use Close Project.
I'm using an OpenGL Quadro card with three monitors running...
Here's a link to a video of what I'm talking about. Note the Task Mangler values for reaper.exe CPU as I go through various scenarios.
Might have to use Chrome and stretch it across two monitors to read Task Crap.
It's also affected by the horizontal zooming. If I take wontclose_nofx.RPP with Task thing showing 13% CPU, and I then Zoom the TCP horizontal out to the show the whole project, the CPU drops to 3% and I can close even without changing the TCP vertical zoom. See vid - http://www.ajawamnet.com/getsevenweirder.mp4
Reaper 6.23 does NOT have this problem. I tried every version back to then and used the examples I posted. All using the same theme and config, for some reason reaper 6.23 works as expected. 6.30 - 6.33 fails to close
And if I copy the tracks from the wontopen_nofx.RPP into a new project, it now closes. It's as though something is corrupting RPP files.
Maybe a plug-in has a modal window that is obscured and is preventing normal mouse handling from processing? If you like when this happens, open the task manager, go to reaper.exe, right click, and do "create dump file" and then zip/email a link to that to support at cockos dot com, and we can take a look.
Maybe a plug-in has a modal window that is obscured and is preventing normal mouse handling from processing? If you like when this happens, open the task manager, go to reaper.exe, right click, and do "create dump file" and then zip/email a link to that to support at cockos dot com, and we can take a look.
No, I specifically kept all effects out - no Monitor FX either. Still hangs. Task Banger shows a "reaper.exe is running normally" in the Task Mangler's "Analyze wait chain" dialog.
I tried the willclose_nofx_6.RPP project, and it won't close for me. Stuck forever on "initializing". Created a dump-file, will e-mail it.
Thank you so much for verifying that. Yea, I saw the other post about initializing getting stuck on open...
Not sure if you tried to re-zoom the TCP and scroll... weird that for me, it closes then.
I have a bunch of projects I'm trying to get out and ever since 6.30 I've had this issue creep up on revisions (using the "_x thing) where the previous version worked as it should and then that latest revision would not.
FYI... I cannot reproduce the issue using the "won't close no fx" test project FYI. I tried having the mixer on a separate monitor as well as the reverse aka reaper on left monitor, mixer on right, and reaper on right and mixer on left monitor.
Version: 6.32
__________________ Music is what feelings sound like.
Last edited by karbomusic; 08-13-2021 at 07:41 AM.
Not sure what the difference is between mine and ramses (who also sees the problem) environment. What I see is when I take the wontclose_nofx.RPP and use CNTL-mousewheel to compact the TCP view and scroll to the bottom of the TCP, the processor utilization drops from 13-14% for reaper.exe in Task Mangler - Details and it now closes.
Procmon then shows it getting past IPR_MJ_Close and closing:
Maybe zoom level gets saved in the project and even though it's a .RPP file, it's actually an INI file format (which could be related to the close ini file hang that I saw in the non-working procmon).
So when it doesn't work maybe it's trying to write the zoom level to the project.rpp (INI) file or something along those lines but I can't be sure and am guessing quite a bit.
I'm still interested if this repros when using my Scenario #2:
I haven't gotten to the root of the issue, something is causing it to get stuck in a peekmessage() loop.. which should be easily avoided (have the loops time out), but now I'm looking at what's causing it, because I'm curious...
I haven't gotten to the root of the issue, something is causing it to get stuck in a peekmessage() loop.. which should be easily avoided (have the loops time out), but now I'm looking at what's causing it, because I'm curious...
Thank you for looking into this. It's strange bird fer sure...
Takes about 11 seconds after I hit File > Close; I get the Initializing splash , waits 11 seconds and then it does close. I guess you now have some sort of watchdog/timeout running?
The CPU still jumps to 13% when I open that project.
It's still the same as to the behavior; if I use CNTL-mousewheel and compress all the tracks in the TCP, and then scroll to the bottom of the project in the TCP, the CPU drops to 2-3% and a File > Close happens immediately.
The CPU still jumps to 13% when I open that project.
It's still the same as to the behavior; if I use CNTL-mousewheel and compress all the tracks in the TCP, and then scroll to the bottom of the project in the TCP, the CPU drops to 2-3% and a File > Close happens immediately.
Do you have any scripts running or extensions (sws, reapack, etc) installed? If so, can you try disabling all of that?
Are you guys sure ramses and ajawamnets root cause are the same? Maybe it's a typo but below is saying the one that "will close" is hanging for ramses...
Quote:
Originally Posted by ramses
I tried the willclose_nofx_6.RPP project, and it won't close for me. Stuck forever on "initializing". Created a dump-file, will e-mail it.
I also don't remember seeing the peekMessage loop in ajawamnets data in the other thread but it's highly possible I just over looked as it could be happening in a different thread than ajawamnets sent me. - hope I'm not backseat driving, just caught my eye and wanted to mention.
__________________ Music is what feelings sound like.
Do you have any scripts running or extensions (sws, reapack, etc) installed? If so, can you try disabling all of that?
Never installed reapack, no sws installed. The AppData\Roaming\REAPER\UserPlugins directory is totally empty
Still hangs on wontclose_nofx for about 15 seconds on the Initializing splash screen.
But it does close.
And as I mentioned when I scroll the TCP to compact all the tracks and scroll to the bottom of wontclose_nofx it closes immediately.
I even tried a copy of both - same results.
I'm thinking it might have to do with the theme I use - a customized version of Commala_5. This might make sense since the presentation on the screen has varying effects on the hang issue.
So I nuked Reaper - even the appdata and program files directories.
reinstalled 634-dev0813_x64
With the stock theme and no changes to the theme (dockers, floating stuff) wontclose_nofx now WILL CLOSE without mucking around with the TCP zoom.
So I tried moving the mixer to the other monitor, since I saw some posts concerning hanging on open.
Still closes the file no problem - immediately.
So now I copy my themes over to the appdata. But I restart reaper and don't change the theme.
Still closes as it should
So now I choose the Commala_5 theme that I customized.
Open wontclose.
Now it hangs for 15 seconds.
I even tried the stock Commala_5 theme. Same thing - wontclose hangs for 15 seconds
I zipped up the Color Theme directory and uploaded it here:
Even more interesting... so I load a pref file into this new Reaper install. Of course it comes up with Commala_5 as the theme. But now if I go back to the Default theme, wontclose_nofx still hangs for about 12 seconds before closing.
I have other projects from those sessions that I derived wont/will close from and some are much more intense as to track count and FX. The all close immediately. Not sure what's up.
Even more interesting... so I load a pref file into this new Reaper install. Of course it comes up with Commala_5 as the theme. But now if I go back to the Default theme, wontclose_nofx still hangs for about 12 seconds before closing.
I have other projects from those sessions that I derived wont/will close from and some are much more intense as to track count and FX. The all close immediately. Not sure what's up.
It's fixed for me I believe. I still get the "initializing" prompt, but it only lasts about 10 seconds now.
Great!
Yea - same for me. But what's weird is the different behavior with the TCP zoom level and the Theme I'm using. Me thinks something is still not quite right.
Thanks! What are the resolutions and layouts of your monitor? If you set the monitor to a single 1920x1080 can you reproduce?
I think you mentioned that 6.23 doesn't have this issue? Does 6.24? Can you find the exact version where the issue began?
I'm using 3 monitors; two are 2560x1440 the third is 1920 x 1200. The two 2560 are left and center, the 1920 is right
So I shut down and unplugged all the monitors but one of the 2560. The wontclose_nofx.RPP now closes after a 2 second hang.
I went from 6.23 right to 6.28. Now I'm curious.
So I totally nuked the Reaper install again, and again deleting all Roaming and Program Files Reaper directories.
Go back to three monitors as it was
I downloaded all the versions from 6.23 (which I had) up to 6.28 which exhibits the hang on close of the wontclose_nofx.RPP
So I installed 6.23 to start... with the stock theme right after install, no problem, it closes immediately.
So I load an old config - one from late 2020. This has the Commala theme. Open wontclose_nofx.RPP. Closes immediately (I'm getting good at spelling immediately)
So I now update to 6.24.
As you expected 6.24 hangs. Same thing, reaper.exe goes to about 12-13% in Task Cracker.
And again, if I use the CNTL-scroll wheel to shrink the TCP to minimum and scroll to the bottom of the TCP it closes immediately.
So it's at the 6.24 version where the problem reared it's ugly head.
Well... I downloaded a bunch of installers I don't need.
When I worked for the ex-NSA guys I recall one cracked program our hackers used that had a bunch of libs that no one really used (they wrote their own exploits).
So the "Rearme" (yea that's how it's spelled) that was in the rar file said, "if u don't wanna use the libs at all and have yer own , u just burnt a cd for nothing, , isn't that funny!
So even if I back ver and just install the 6.23 release over top of 0205 it closes as expected.
But 6.23+dev0205 hangs
Thanks! I added some more builds (6.19+dev and 6.21+dev) -- can you start with the first 6.19+dev -- note this is 6.19+dev1219, since it's month/day and that series started in december -- and check that? If it hangs then report, otherwise if it doesn't hang, move forward through the list
Thanks! I added some more builds (6.19+dev and 6.21+dev) -- can you start with the first 6.19+dev -- note this is 6.19+dev1219, since it's month/day and that series started in december -- and check that? If it hangs then report, otherwise if it doesn't hang, move forward through the list
So 1219 hangs...
I wanted to see something... Sooo...
If I take the TCP and drag it to monitor 1 - with the mixer floating and the master floating, it still hangs, except for version 6.23.
But now, if I take and dock both the mixer and the master and run them on monitor 1, even 6.34 with the same prefs and Commala_5 ( and not the the dev build) closes.
This is looking like the same issue that others are reporting concerning the mixer on another monitor causing initializing hangs.
So - in summary:
All versions do not hang when the mixer (regardless if the Master is floating or not) IS DOCKED. Regardless of what monitor is used or if in full screen.
Even with the mixer docked, it seems that 6.19+dev1228, 1231 hang a bit more before finally closing.
Versions 6.19+dev1219, 1222, 1223, 1226, 1228 (see note above), 1229, 1230, 1231, (see note above), 0101, 0102, 0103, etc ALL HANG - with the CPU climbing to 13% - when the mixer is NOT docked.
So I tried going backward from 6.23. Started with 6.21+dev0202 - it does the same thing; hangs with mixer un-docked/floating, but closes as expected when the mixer is docked.
All hang with the mixer undocked except for version 6.23. I kept going back to that version. It closes regardless if the mixer is docked or not
6.34+dev0813 hangs for 10 seconds but eventually closes.
Really strange. It seems that 6.23 is the bastard child.
So this confirms for me that software totally blows away the theory that insanity is doing the same thing over and over and expecting different results.
It seems par for the course with software.
I always tell my young engineers (I design hardware) that I chose to do hardware because exception handling has been done by nature for billions of years. I fuck up it's handled; I just gotta find out why.
A note, the +dev builds have additional code, so they aren't exactly linear with the releases. So we'll keep stepping backwards through the +dev builds. I posted a new batch to https://landoleet.org/old/624/
So you can start at reaper613+dev0723_x64-install.exe and see if that hangs. If it doesn't, then it's between that and hreaper619+dev1219_x64-install.exe
Thanks and sorry for the trouble we'll figure this out soon!
A note, the +dev builds have additional code, so they aren't exactly linear with the releases. So we'll keep stepping backwards through the +dev builds. I posted a new batch to https://landoleet.org/old/624/
So you can start at reaper613+dev0723_x64-install.exe and see if that hangs. If it doesn't, then it's between that and hreaper619+dev1219_x64-install.exe
Thanks and sorry for the trouble we'll figure this out soon!