Issue with Stream Deck +

wsomm · January 24, 2024, 1:15pm

For your information!

I have a Stream Deck + and the GP Extension installed. The workstation computer is a Mac Studio with Sonoma 14.2.1. The combination has some issue:

The directory “/private/tmp/boost_interprocess” is flooded with Millions of files when using Gig Performer. Approximately 20 gigabytes of data are written every minute, which means the SSD is full after half an hour.

fs_usage clearly indicates that the files are being written by the GigPerformer process. Occasionally, there are accesses from streamdeck-g to the directory, but it’s rare.

For me, the Stream Deck combination is not necessary, so I’m deleting the extension, and for me, the issue is resolved.

But perhaps someone else may still have problems with this combination.

rank13 · January 24, 2024, 1:41pm

I have a Stream Deck + and running Ventura on an Intel MacBook Pro. I will check this out as well.

wsomm · January 24, 2024, 1:46pm

Additional Information:

It happens when I open a second instance of GP for the Audio files.
Everythign is fine, when using GP with Stream Deck without this.

timothyschoen · January 24, 2024, 3:15pm

Thanks for reporting!

This definitely seems like it is coming from the extension. I am using boost_interprocess for communication between the 2 extensions.

I think this might not happen for everyone, since writing 20gb per minute would probably have been noticed before. That would mean that most people’s disks would be completely full after an hour of usage.

I’ll see if I can find any reason for it to do this

dhj · January 24, 2024, 3:19pm

Yes, I can duplicate this as well. Deleting the extension makes it go away.

However, if the streamdeck main application is running, even if GP Profile and Extension is not there, it produces a single entry in that folder called gigp-streamdeck-cid

npudar · January 30, 2024, 12:18pm

Can you please test this version and confirm that the problem is fixed?
Link: [blog] How to install and use the Stream Deck extension in Gig Performer - #77 by timothyschoen

wsomm · January 30, 2024, 2:20pm

No, but I believe the new extension was not properly installed.

Clicked on the installer. It ran smoothly.

However, nothing was installed in /Users/Shared/Gig Performer/Extensions.

I had the old one renamed and still kept there. Renamed it back, then
the extension was reactivated, but the error still persists.

wsomm · January 30, 2024, 2:26pm

Correction:

Behaviour changed indeed.

No files are created anymore but fs_usage is running permamnt things like this:

15:24:14 mkdir private/tmp/boost_interprocess 15:24:14 chmod private/tmp/boost_interprocess 15:24:14 mkdir private/tmp/boost_interprocess 15:24:14 chmod private/tmp/boost_interprocess 15:24:14 mkdir private/tmp/boost_interprocess 15:24:14 chmod private/tmp/boost_interprocess 15:24:14 mkdir private/tmp/boost_interprocess 15:24:14 chmod private/tmp/boost_interprocess 15:24:14 mkdir private/tmp/boost_interprocess 15:24:14 chmod private/tmp/boost_interprocess 15:24:14 mkdir private/tmp/boost_interprocess 15:24:14 chmod private/tmp/boost_interprocess 15:24:14 mkdir private/tmp/boost_interprocess 15:24:14 chmod private/tmp/boost_interprocess 15:24:14 mkdir private/tmp/boost_interprocess 15:24:14 chmod private/tmp/boost_interprocess 15:24:14 mkdir private/tmp/boost_interprocess 15:24:14 chmod private/tmp/boost_interprocess 15:24:14 mkdir private/tmp/boost_interprocess 15:24:14 chmod private/tmp/boost_interprocess 15:24:14 mkdir private/tmp/boost_interprocess 15:24:14 chmod private/tmp/boost_interprocess 15:24:14 mkdir private/tmp/boost_interprocess 15:24:14 chmod private/tmp/boost_interprocess 15:24:14 mkdir private/tmp/boost_interprocess 15:24:14 chmod private/tmp/boost_interprocess 15:24:14 mkdir private/tmp/boost_interprocess 15:24:14 chmod private/tmp/boost_interprocess 15:24:14 mkdir private/tmp/boost_interprocess 15:24:14 chmod private/tmp/boost_interprocess 15:24:14 mkdir private/tmp/boost_interprocess 15:24:14 chmod private/tmp/boost_interprocess 15:24:14 mkdir private/tmp/boost_interprocess 15:24:14 chmod private/tmp/boost_interprocess 15:24:14 mkdir private/tmp/boost_interprocess 15:24:14 chmod private/tmp/boost_interprocess 15:24:14 mkdir private/tmp/boost_interprocess 15:24:14 chmod private/tmp/boost_interprocess 15:24:14 mkdir private/tmp/boost_interprocess 15:24:14 chmod private/tmp/boost_interprocess 15:24:14 mkdir private/tmp/boost_interprocess 15:24:14 chmod private/tmp/boost_interprocess 15:24:14 mkdir private/tmp/boost_interprocess 15:24:14 chmod private/tmp/boost_interprocess 15:24:14 mkdir private/tmp/boost_interprocess 15:24:14 chmod private/tmp/boost_interprocess 15:24:14 mkdir private/tmp/boost_interprocess 15:24:14 chmod private/tmp/boost_interprocess 15:24:14 mkdir private/tmp/boost_interprocess 15:24:14 chmod private/tmp/boost_interprocess 15:24:14 mkdir private/tmp/boost_interprocess 15:24:14 chmod private/tmp/boost_interprocess 15:24:14 mkdir private/tmp/boost_interprocess 15:24:14 chmod private/tmp/boost_interprocess 15:24:14 mkdir private/tmp/boost_interprocess 15:24:14 chmod private/tmp/boost_interprocess 15:24:14 mkdir private/tmp/boost_interprocess 15:24:14 chmod private/tmp/boost_interprocess 0.000016 GigPerformer
0.000052 GigPerformer
0.000015 GigPerformer
0.000031 GigPerformer
0.000012 GigPerformer
0.000061 GigPerformer
0.000018 GigPerformer
0.000050 GigPerformer
0.000030 GigPerformer
0.000058 GigPerformer
0.000012 GigPerformer
0.000050 GigPerformer
0.000014 GigPerformer
0.000037 GigPerformer
0.000009 GigPerformer
0.000027 GigPerformer
0.000012 GigPerformer
0.000056 GigPerformer
0.000017 GigPerformer
0.000051 GigPerformer
0.000024 GigPerformer
0.000056 GigPerformer
0.000011 GigPerformer
0.000047 GigPerformer
0.000024 GigPerformer
0.000086 GigPerformer
0.000014 GigPerformer
0.000039 GigPerformer
0.000009 GigPerformer
0.000045 GigPerformer
0.000020 GigPerformer
0.000044 GigPerformer
0.000043 GigPerformer
0.000048 GigPerformer
0.000010 GigPerformer
0.000048 GigPerformer
0.000026 GigPerformer
0.000064 GigPerformer
0.000019 GigPerformer
0.000048 GigPerformer
0.000015 GigPerformer
0.000083 GigPerformer
0.000020 GigPerformer
0.000057 GigPerformer
0.000016 GigPerformer
0.000050 GigPerformer
0.000011 GigPerformer
0.000047 GigPerformer
0.000026 GigPerformer
0.000060 GigPerformer
0.000013 GigPerformer
0.000037 GigPerformer
0.000011 GigPerformer
0.000052 GigPerformer
0.000035 GigPerformer
0.000052 GigPerformer
0.000010 GigPerformer
0.000028 GigPerformer

npudar · January 30, 2024, 3:26pm

@timothyschoen

Is this OK?

timothyschoen · January 30, 2024, 3:56pm

Thanks for testing!

The output is different for me:

GigPerformer only prints this constantly:

16:43:33.399051  write             F=7    B=0x1                                                   0.000006   GigPerformer4.4784323
16:43:33.399058  read              F=6    B=0x1                                                   0.000002   GigPerformer4.4784322

But it does so regardless of whether or not the Stream Deck extension is installed. So that’s unrelated.

On the Stream Deck side, I can reproduce something like what you get, when there is no active connection to GigPerformer:

16:40:49.017418  mkdir                  [ 17]           private/tmp/boost_interprocess            0.000082   streamdeck-gp.4781546
16:40:49.017505  chmod             <rwxrwxrwt>          private/tmp/boost_interprocess            0.000086   streamdeck-gp.4781546
16:40:49.017537  open                   [  2] (RW__________)  private/tmp/boost_interprocess/     0.000023   streamdeck-gp.4781546

This makes sense: it’s trying to establish a connection with GigPerformer, so it checks if the “private/tmp/boost_interprocess” folder actually exists, and if it has the correct permissions. That’s just regular stuff that boost_interprocess does when it tries to open a connection.

Once a connection is established, I only get fs_usage messages when you actually interact with the Stream Deck or GigPerformer.

I’m not yet sure why you also get that output from GigPerformer. Does the extension work normally other than this filesystem usage?

wsomm · January 30, 2024, 4:35pm

Before we continue.

As the new installer has not installed a new libgp-streamdeck.dylib I am using
a version created 11. Nov 2023 00:26. Is this ok?

(And maybe we transfer further details to PM?!?)

timothyschoen · January 30, 2024, 4:41pm

That is definitely an old version! You can copy the new version manually as well, but I’m surprised it doesn’t work. I’ll also have to find out what’s going on there.

You can also manually copy the extension over for now, it’s just stored as a regular file: “~/Library/Application Support/com.elgato.StreamDeck/Plugins/com.deskew.gigperformer.sdPlugin/libgp-streamdeck.dylib”

We can discuss further on DM. Thanks again for helping out!

timothyschoen · January 30, 2024, 4:49pm

Okay, I see what’s going on here. I made a mistake in packaging the macOS Arm version, which I think you might be using?

EDIT: never mind, that’s not the problem

wsomm · January 30, 2024, 4:57pm

Yes, I am using the Arm Version.

The extension works. But the described behaviour above (mkdir/chmod) remains,
but only when I open a second instance in which I have my audio files.

I do not know, what else I can do to help.

wsomm · January 30, 2024, 4:58pm

BTW: Thank you for this wonderful extension!

timothyschoen · January 30, 2024, 5:11pm

I think the most important thing is that it’s no longer writing a lot of data to the disk, and that it actually works. I’ll try some more things, I’ll DM you if there’s anything you can do to help!

This issue doesn’t seem as bad, fortunately. GigPerformer is already periodically generating some disk activity by itself, so while this is not ideal, it’s also not very harmful.

I’m still unsure why automatic installation fails for you, so I’ll also DM you if I need help with that