BetterDiscord Plugin Fails to Load: Megathread
Closed this issue · 14 comments
I'm trying to run the plugin but I get this error
System info:
Discord Version: Release
OS: Arch Linux
Expected Beavior:
No error message, plugin works normally
Steps to reproduce:
1: Install the plugin
2: Enable it in BetterDiscord
3: Restart discord entierly
4: Module fails to load
Log:
Error: Cannot find module net
at Function._load (<anonymous>:4:320513)
at Function.o._load (<anonymous>:4:379728)
at <anonymous>:4:323433
at eval (betterdiscord://plugins/Tuxphones.plugin.js:289:40)
at buildPlugin (betterdiscord://plugins/Tuxphones.plugin.js:549:4)
at eval (betterdiscord://plugins/Tuxphones.plugin.js:554:2)
at Object.requireAddon (<anonymous>:4:43438)
at Object.loadAddon (<anonymous>:4:9197)
at Object.loadAddon (<anonymous>:4:41165)
at AsyncFunction.<anonymous> (<anonymous>:4:7353)
Due to Discord basically completely breaking all of my plugins, I'm gonna be taking a break from unofficial BD plugins and focus on my school work for a while. The entire plugin needs to be rewritten at this point to restore functionality.
Hey I hope things with school are going well fro you @ImTheSquid!
I thought I'd add some info here because I am also facing issues, and it might be helpful to you when you pick up this project again :)
@Rathmox, I created /net in my home directory. I am not sure if this is the cause for the next issue I began seeing:
$ cargo run
warning: unused import: `std::process::Command`
--> src/lib.rs:2:5
|
2 | use std::process::Command;
| ^^^^^^^^^^^^^^^^^^^^^
|
= note: `#[warn(unused_imports)]` on by default
warning: unused import: `Serialize`
--> src/discord_op.rs:4:17
|
4 | use serde::{Serialize, Serializer};
| ^^^^^^^^^
warning: unused variable: `gst_resize_rx`
--> src/lib.rs:112:53
|
112 | ... let (gst_resize_tx, gst_resize_rx) = channel(10);
| ^^^^^^^^^^^^^ help: if this is intentional, prefix it with an underscore: `_gst_resize_rx`
|
= note: `#[warn(unused_variables)]` on by default
warning: field `encoder` is never read
--> src/gstreamer.rs:99:5
|
95 | pub struct GstHandle {
| --------- field in this struct
...
99 | encoder: Element,
| ^^^^^^^
|
= note: `#[warn(dead_code)]` on by default
warning: `tuxphones` (lib) generated 4 warnings
Finished dev [unoptimized + debuginfo] target(s) in 0.37s
Running `target/debug/tuxphones`
2022-10-28T19:46:03.727573Z INFO tuxphones: Daemon started
Tuxphones
Could not be compiled. See console for details
TypeError: I.slice is not a function
at Function.resolveMainFile (<anonymous>:4:347466)
at Function._load (<anonymous>:4:348056)
at <anonymous>:4:351046
at eval (betterdiscord://plugins/Tuxphones.plugin.js:289:40)
at buildPlugin (betterdiscord://plugins/Tuxphones.plugin.js:549:4)
at eval (betterdiscord://plugins/Tuxphones.plugin.js:554:2)
at Object.requireAddon (<anonymous>:4:39192)
at Object.loadAddon (<anonymous>:4:9163)
at Object.loadAddon (<anonymous>:4:36864)
at Object.loadAllAddons (<anonymous>:4:11637)
at Object.initialize (<anonymous>:4:6059)
at Object.initialize (<anonymous>:4:36059)
at Object.startup (<anonymous>:4:396505)
Perhaps I'll take some time to familiarize myself with Rust and this project to see if I can offer any assistance here, though please don't hold your breath :)
Due to an update with Discord, all BD plugins have to be rewritten. I'm working on slowly updating my plugins so I'll try to fix this soon. In terms on what you could do to help, our biggest obstacle right now is sending WebRTC data to Discord. We currently use this project but there is a lack of support for media negotiation. If you want, you could try to contribute to that plugin or work on this one that may end up working better.
I've also been following this and thought something similar... it probably would be practical to refactor in go using pion. If nothing else, the ecosystem for voip and webrtc is arguably more mature and supported in golang.
Is there any chance you can document what you've discovered so far in building tuxphones?
@Dreaming-Codes is better-versed in WebRTC than I am, but from what I know Rust WebRTC doesn't have support full support for some type of media negotiation but Pion does. The Rust WebRTC plugin we built is relatively well-documented and almost works with Discord (video works well, audio doesn't work at all), but that's the only thing that needs to be replaced in the pipeline; everything else works (or can work after being updated since I need to rewrite the BD plugin).
I've also been following this and thought something similar... it probably would be practical to refactor in go using pion. If nothing else, the ecosystem for voip and webrtc is arguably more mature and supported in golang.
Is there any chance you can document what you've discovered so far in building tuxphones?
There's no need to rewrite everything in go...
We are using gstreamer so we can just use a go plugin for webrtc and rust for everything else.
I have already started writing the needed go gstreamer plugin and it's available on my gh.
Unfortunately, development of that plugin is slow since I am having a series of personal issues that do not allow me to find time to do everything. I hope to be able to resume development of it in a week at most.
@Dreaming-Codes is better-versed in WebRTC than I am, but from what I know Rust WebRTC doesn't have support full support for some type of media negotiation but Pion does. The Rust WebRTC plugin we built is relatively well-documented and almost works with Discord (video works well, audio doesn't work at all), but that's the only thing that needs to be replaced in the pipeline; everything else works (or can work after being updated since I need to rewrite the BD plugin).
Yeah, basically current rust webrtc implementation doesn't support encoding and so there's no automatic codec properties negotiation and since discord is doing something strange with audio we weren't able to set the gstreamer opus encoder how discord wanted.
In fact the go gstreamer plugin that I'm writing is supposed to get the raw output from gstreamer and encode it automatically according to the webrtc handshake.
I am having a similar issue.
Error: ENOENT: no such file or directory, lstat '/usr/bin/net'
at Object.T [as realpathSync] (:4:346490)
at Function.getFilePath (:4:347760)
at Function._load (:4:347855)
at :4:351046
at eval (betterdiscord://plugins/Tuxphones.plugin.js:289:40)
at buildPlugin (betterdiscord://plugins/Tuxphones.plugin.js:549:4)
at eval (betterdiscord://plugins/Tuxphones.plugin.js:554:2)
at Object.requireAddon (:4:39192)
at Object.loadAddon (:4:9163)
at Object.loadAddon (:4:36864)
at AsyncFunction. (:4:7155)
I am also having a secondary issue of the daemon refusing to run with the error:
2022-11-06T16:33:24.949373Z ERROR tuxphones::socket::receive: Failed to create listener: Address already in use (os error 98)
2022-11-06T16:33:24.949415Z ERROR tuxphones: Error creating socket watcher!
Both the plugin and daemon intialized fine the first time but neither is working for me now, and I am both deep in the weeds and out of my depth.
Once @Dreaming-Codes is ready to resume his work on the WebRTC part of the project, I will fix all of the current outstanding issues with the rest of the codebase.
I've started working on fixing the BD plugin, it should now at least load but it won't do anything right now while I fix module resolution completely. The daemon also needs to be updated for it to work properly.
The plugin should now be pretty much completely fixed.
It doesn't work
(btw the script wasn't working out of the box)
The script won't work until Tuxphones is ready for a 1.0 release. You have to manually clone the repo and run the daemon yourself using cargo run in the daemon folder, then the plugin will stop complaining. I should have a lot more time to work on this soon-ish, I'm just doing some maintenance right now to keep the project alive.
ok, thanks