Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Beta 1.2.0 partially hanging on long compressions #495

Open
Darklocq opened this issue Dec 7, 2019 · 6 comments
Open

Beta 1.2.0 partially hanging on long compressions #495

Darklocq opened this issue Dec 7, 2019 · 6 comments
Assignees
Labels
Milestone

Comments

@Darklocq
Copy link

@Darklocq Darklocq commented Dec 7, 2019

Using the 1.2.0-dev beta that had the ACE stuff added in for testing. Seems to be 1.2.0-dev (3701), more specifically. I mostly use Keka as just a Dock drop target to do nothing but 7Z (max) compression. I'm finding that it seems to (partially) hang more than 50% of the time on any fairly large/long compressions, and is more apt to do so, it seems, when switching focus away from the app to do something else. The progress bar stops, you get a "beachball" cursor, and if you leave the app, nothing happens when you try to get back into it (by Dock icon click or by Cmd-Tab). It will often work right on a second or later attempt, but not always. In reality, the app is actually still working in the background, as can be confirmed by keeping an eye on the file size of the archive being written out. However, after it is done, it does not play its sound, and the app remains unresponsive.

For example, I kept getting a "beachball" in the app when compressing a 1.3 GB Native Instruments Maschine library (one big file) I don't need any time soon. It guestimates 6 minutes (at my performance settings), and becomes unresponsive after about 1 (but actually got the job done in 10–15). The non-beta version has no trouble with the file, and gets the job done in about 1.5 minutes (though hogging CPU and RAM), plays its completion sound, and is working properly afterward (in my case it quits unless I have it open doing something else, as intended). The beta version just sits there, stuck. The archive it created while semi-hung tests out as valid (in The Archive Browser).

I'm doubting this has to do with the ACE addition, since extracting ACEs and compressing 7Zs wouldn't seem to related to each other. But who knows.

I am testing some of the new Performance settings:

  • Max. sim. ops.: 2
  • Max. sim. comp.: 1
  • Max. sim. extr.: 2
  • Max. thread/op.: 2

(Aside: I can confirm that this stuff works to stop the app from using up all available RAM and CPU, at the cost of speed, as expected.)

File access is volume-wide on every volume. Inherit quarantine is off. Default action: always compress. Compression: 7z, slowest/most. Save: next to original, same base name. Exclude res. forks. Play sound when done. Ask before quit, enable Notification Ctr., use unified toolbar, close app when no windows open, auto-updates off. Keka not set as default app for anything.

Oh, and as I noted elsewhere, it crashed to desktop one time, after running the beta for the first time and opening preferences and picking some panes to look at.

System: macOS 10.13.6, mid-2010 Mac Pro, 40 GB RAM, loads of disk/SSD space.

@Darklocq

This comment has been minimized.

Copy link
Author

@Darklocq Darklocq commented Dec 12, 2019

In other thread about the ACE 2.x beta, I uploaded crash/hang logs. Also, I don't think this really has anything to do with length of the compression operation, but mostly with the app losing user "focus", though I also got it to crash another way (trying to write to directory without proper permissions), as reported at the other ticket. This ticket is probably a duplicate. Mostly, if you switch away from the app it just hangs, though as noted above sometimes part of it is still running and will eventually get the compression job done, though it will not tell you that it is done. On average, it just seems to hang completely. Meanwhile, if you leave it as the frontmost app, it will generally work normally.

@Darklocq

This comment has been minimized.

Copy link
Author

@Darklocq Darklocq commented Dec 12, 2019

That archive file of crash logs is toward the (current) end of #402.

@aonez

This comment has been minimized.

Copy link
Owner

@aonez aonez commented Dec 12, 2019

This reminds me to #119. I'll double check that Keka is informing the activity to the OS in the latest beta.

@aonez aonez added the bug label Dec 12, 2019
@aonez aonez added this to the 1.2.0 milestone Dec 12, 2019
@aonez aonez removed rar tests labels Dec 12, 2019
@aonez aonez self-assigned this Dec 12, 2019
@aonez

This comment has been minimized.

Copy link
Owner

@aonez aonez commented Dec 18, 2019

I can't reproduce this one, on 10.13 or 10.14.

@aonez aonez removed the bug label Dec 18, 2019
@Darklocq

This comment has been minimized.

Copy link
Author

@Darklocq Darklocq commented Jan 6, 2020

As I noted elsewhere, the dev version you pointed me to a couple of weeks ago was still hanging whenever I would switch out of the application (e.g. to finder). I found that it would complete the compression job if it was a short one (like a minute or less), but would die completely after a while on a long job. It would still complete the job without any kind of hanging as long as the app retained OS focus the entire time. That's under macOS 10.13.6. Is there another dev version to try?

@aonez

This comment has been minimized.

Copy link
Owner

@aonez aonez commented Jan 7, 2020

The latest one is https://github.com/aonez/Keka/releases/tag/v1.2.0-dev.3742, but I think you've already tried it. I was unable to reproduce the issue involving the focus...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.