Package Details: streamdeck-ui 4.1.2-1

Git Clone URL: https://aur.archlinux.org/streamdeck-ui.git (read-only, click to copy)
Package Base: streamdeck-ui
Description: A Linux compatible UI for the Elgato Stream Deck
Upstream URL: https://streamdeck-linux-gui.github.io/streamdeck-linux-gui/
Keywords: deck elgato streamdeck streamer streaming
Licenses: MIT
Provides: streamdeck-ui
Submitter: GI_Jack
Maintainer: dhtseany
Last Packager: dhtseany
Votes: 7
Popularity: 0.46
First Submitted: 2021-05-14 15:27 (UTC)
Last Updated: 2024-04-15 18:45 (UTC)

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 8 9 10 Next › Last »

dhtseany commented on 2023-03-22 22:10 (UTC) (edited on 2023-03-22 22:12 (UTC) by dhtseany)

@jvzr I think I get what's wrong: root vs user land.

When the service runs as I provided it, I admit I tested $ /usr/bin/streamdeck -n in user-space and I didn't consider that it worked because I ran it as my local user.

However, when the service attempts to invoke the same run command it's trying to run it as root and it doesn't work because the streamdeck's config file was made and works in user-space so the service running as root doesn't see the cached streamdeck config file. This prevents it from seeing the cached userland config so in the service's case it craps itself but in the case of running it as root it presents a blanked out config. Re-running the app as a regular user restores the config instantly.

Bear with me while I keep tinkering with this, I'm sure I'll find a workaround, I'm just not sure what the fix is yet to let the service invoke the user-space streamdeck config. Maybe going with the upstream instructions is the right approach after all? I'll test and report back my findings.

dhtseany commented on 2023-03-20 22:54 (UTC)

@jvzr I'm having the same problem on my production system, I'll get it fixed/patched soon and report back once I know what's up. Thanks for the report!

jvzr commented on 2023-03-14 21:20 (UTC)

@dhtseany I've stopped the service, ran the command (my stream deck was then showing my configured buttons), killed it, started the service, same error

Here's the output of systemctl status streamdeck.service

I'm running plain old Arch with Gnome 43/GDM/Mutter. I'm sure I may have modified things here and there but it is not headless, nope

dhtseany commented on 2023-03-14 21:00 (UTC) (edited on 2023-03-14 21:06 (UTC) by dhtseany)

@jvzr I think I dealt with this at one point but I couldn't reproduce it, first kill the running service then try running # python /usr/bin/streamdeck -n (aka as admin), kill the running python thread, then try starting the service again. Does that help? I think it's something with the config file not existing and running it that way makes a dummy file.

If not paste me the output of $ systemctl status streamdeck.service and I'll try to help more. Also, the angry display message is because we're using Wayland but it should still work.

Edit: Upon closer inspection of your initially provided logs I too see how it seems to be a bit more angry than usual, that isn't the normal qta bug I'm used to seeing. The system you're using isn't headless, is it?

jvzr commented on 2023-03-14 18:39 (UTC)

@dhtseany I have been trying to make the systemd service work but have been unsuccessful. I get a qt.cpa error relating to the display. Gnome 43 on Wayland. Can I provide you with more info? If so I'd happy to help you debug this.

As always, thank you for the continuous updates!

dhtseany commented on 2023-03-14 17:22 (UTC)

The update to 2.0.15-1 was fairly uneventful with support for the Stream Deck Pedal being the major feature addition for this version. As always let me know if you need help and remember to check your makedep's if your having problems building.

dhtseany commented on 2023-03-06 20:38 (UTC) (edited on 2023-03-06 20:59 (UTC) by dhtseany)

The update to 2.0.14 has been pushed which notably includes the ability to run the streamdeck binary as a systemd service file however you'll find that the provided .service file does not match what is recommended by upstream. Remember that there's 2 ways to run the streamdeck-ui app on Arch:

  1. You can use upstream's provided PIP instructions which installs and runs all within user-space. Running the new service file as instructed by upstream is how you'd want to create the .service file.

  2. You choose to install a package like streamdeck-ui or streamdeck-ui-git knowing you'll be running at the system level instead which requires that we run the app slightly different from upstream.

This package is #2 and instead of their --user based command you start/enable/stop the service file as a normal .service file:

$ sudo systemctl start streamdeck.service

Let me know if anyone runs into any problems and I'll do my best to assist!

Edit: Lol sorry about 2.0.14-1, I forgot to save the .service file before I pushed it ^^

dhtseany commented on 2023-02-28 21:16 (UTC) (edited on 2023-03-03 20:37 (UTC) by dhtseany)

Updated to 2.0.13, thanks to the team upstream for the continued work on a great project!

This update sees the removal of pyside2 and the addition of pyside6 to take it's place.

The workaround with xhost is no longer required so I've removed that from the .desktop file and the app will launch normally again without error by using streamdeck.

Let me know if there's any problems during upgrade and I'll do my best to assist.

PS- Remember that you don't need pyside2 anymore, you should be able to remove it safely with $ pacman -Rs pyside2

dhtseany commented on 2023-01-04 20:55 (UTC)

I updated the .desktop file to provide an easier to use workaround assuming upstream doesn't plan to correct this. That said, you can also use the fix I applied from the terminal by running $ xhost + && streamdeck

If I get feedback on a better way to resolve this such as a patch I can apply during packaging I'm happy to accept the help! Let me know if there's problems from this update for anyone and I'll do my best to help.

dhtseany commented on 2022-12-20 14:45 (UTC)

I've found a workaround to get the app running again however I don't feel it's a permanent fix...

  1. Run: $ xhost +
  2. Then run streamdeck: $ streamdeck

I'm aware of the ongoing problem and I'm still waiting on a response about what we should do for a permanent fix from upstream but this should at least get it running again short-term.