errors when run

[bf2spy]

This project is great, but when I ran it I got some errors
When I access it with ip address 127.0.0.1:3005，no errors
But when I access it with ip address 192.168.0.20:3005 or my domain name for example www.xxxx.com:3005,it shows errors in the terminal：
ws.go:85 Failed to set websocket upgrade: webcocket: request origin not allowed by upgrader.checkorigin

Even so, I can register and login normally, and add repeaters normally，test with Google Chrome。

Enroll New peer -INOP failed unless modify from “peers#” to “peers/new"

[USA-RedDragon]

Thanks for trying out DMRHub!

But when I access it with ip address 192.168.0.20:3005 or my domain name for example www.xxxx.com:3005,it shows errors in the terminal

It sounds like you're hitting CORS issues. Make sure to set the CORS_HOST environment variable for your environment. The env vars are documented here: https://github.com/USA-RedDragon/DMRHub/wiki/Environment-Variables

Basically, you'll want to add any (fully-qualified URLs) of hosts that you'd like to access DMRHub at, i.e. CORS_HOST="http://127.0.0.1:3005,http://192.168.0.20:3005,http://www.xxxx.com:3005,https://www.xxxx.com"

Enroll New peer -INOP failed unless modify from “peers#” to “peers/new"

As far as peers and OpenBridge, that's still a WIP. The -INOP means literally "inoperable". I intend to have a feature flag for this soon so it won't show up on releases until it's ready. #81 is the issue tracking OpenBridge support.

[USA-RedDragon]

v1.0.44 is releasing now that removes the evidence of OpenBridge support (the items that were previously broken and marked INOP) until it's ready.

[bf2spy]

Thank you very much for your efforts
Now that CORS_HOST has been added, it has been accessed normally without errors.

After comparison, I found that your project is better than freedmr and hblink!
Looking forward to its more and more perfect, I use the firmware of the mmdvm to do the hotspot board relay test, there has been a puzzling problem, the configuration environment is as follows:
Client 1: mmdvmhost----dmrgateway-----dmrhub register and add a trunk
Static call groups 123456 and 123457

Client 2: mmdvmhost----dmrgateway-----dmrhub register and add a trunk
Static call groups 123458 and 123459

When client1 makes a call in talkgroup 123456, client2 can copy the call in talkgroup 123458.

The function I understand is that calls can only be received in the same talkgroup
For example, when client1 makes a call in call group 123456, client2 can receive the call only after adding dynamic talkgroup 123456. After dynamic talkgroup 123456 is deleted, client1 cannot receive the call

The current situation is that after a client makes a call to any call group, other clients can receive a call even if they are not in the same talkgroup

My walkie-talkie uses opengd77 firmware and has not yet been tested with other walkie-talkie.
I will test further and give feedback later

[bf2spy]

Another issue is that mmdvmhost's repeater password support for dmrhub is not very good
When I filled in the Password of mmdvmhost prompted by the repeater in the password of pi-star mmdvmhost, mmdvmhost stopped running. I tried to add and delete the repeater once to get a password that could be supported, but found that the special symbol would cause MMDVmhost to stop working. For example, a password that contains @%&* characters.
I tried manually changing these passwords in the database , for example, passw0rd, and everything worked fine

[USA-RedDragon]

The function I understand is that calls can only be received in the same talkgroup

This is how it should work, but since you said this, it doesn't sound like it:

The current situation is that after a client makes a call to any call group, other clients can receive a call even if they are not in the same talkgroup

I'll look into this, thanks for letting me know.

I tried to add and delete the repeater once to get a password that could be supported, but found that the special symbol would cause MMDVmhost to stop working. For example, a password that contains @%&* characters

Same here, I'll look into this. You wouldn't happen to have any logs from when this happened, would you?

[USA-RedDragon]

Looks like since about 2020, MMDVMHost wants folks to use DMRGateway for connecting to master servers like DMRHub. This seems to be because MMDVM isn't just DMR, so the DMR bits specifically are now handled at the DMRGateway side, so technically that setup is unsupported on the MMDVMHost side: See related issue g4klx/MMDVMHost#651

As long as DMRGatway is working as expected, there's not much I can do about MMDVMHost on the DMRHub side.

---

I'm looking into the talkgroup issue now

[USA-RedDragon]

This is how I've set up two DMR MMDVM repeaters for testing with. It seems like the DMR data is going to the appropriate talkgroups only and aren't leaking into other talkgroups unless they dynamically link. It's possible I misunderstood something from your report though.

[bf2spy]

Thank you very much for your reply I have done many experiments, I do not know whether it is related to the system, I was tested in the windows7 system, I did have 123456 in the dynamic call group, but after manually deleting the dynamic call group, although it is not in the 123456 call group, I can still receive calls from this call group. I guess the cache that dmrhub is running is still in use? At 2023-11-19 17:59:03, "Jacob McSwain" ***@***.***> wrote: This is how I've set up two DMR MMDVM repeaters for testing with. It seems like the DMR data is going to the appropriate talkgroups only and aren't leaking into other talkgroups unless they dynamically link. It's possible I misunderstood something from your report though. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>

[bf2spy]

I found that our experimental Settings are slightly different, both clients are time slot 1, client 1 static TG is 123456 and 123457, client 2 static TG is 123458 and 123459 Client 2 does not add a dynamic TG and then makes a call in TG 123456. After the dynamic TG is deleted on the login page and client 2 exits, if there is a call in TG 123456, client 2 can still receive it At 2023-11-19 17:59:03, "Jacob McSwain" ***@***.***> wrote: This is how I've set up two DMR MMDVM repeaters for testing with. It seems like the DMR data is going to the appropriate talkgroups only and aren't leaking into other talkgroups unless they dynamically link. It's possible I misunderstood something from your report though. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>

[USA-RedDragon]

I see, thanks for clarifying. I have a theory about why this might be happening, I'll update as I've got more info.

[USA-RedDragon]

I think I found the issue. The "subscription" goroutines that manage repeater data routing takes in a copy of the repeater's subscribed talkgroups when it begins and it doesn't get any updates afterward to inform it that the subscribed talkgroups have changed. I am working on a fix for that

[USA-RedDragon]

I believe this is fixed with b3ec90e but my 2nd mmdvm isn't activating right now to test it. That commit will be in v1.0.46 when it releases tonight after I pull in dependency updates.

[bf2spy]

Thank you very much I haven't logged in for a long time, but today I reinstalled postgresql-9.2.24 and used your latest 1.0.56 version Suddenly found a hint： github.com/USA-RedDragon/DMRHub/internal/db/db.go:68 [35;1mERROR: syntax error at or near "NOT" (SQLSTATE 42601) [0m[33m[1.000ms] [34;1m[rows:0][0m CREATE INDEX IF NOT EXISTS "idx_app_settings_deleted_at" ON "app_settings" ("deleted_at") It's weird. I don't know if it's just me At 2023-11-26 13:53:33, "Jacob McSwain" ***@***.***> wrote: I believe this is fixed with b3ec90e but my 2nd mmdvm isn't activating right now to test it. That commit will be in v1.0.46 when it releases tonight after I pull in dependency updates. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>

[bf2spy]

Please ignore the above feedback, after changing postgresql-9.5.25, there will be no above error。 At 2023-12-17 19:24:48, "wuxiandianzi" ***@***.***> wrote: Thank you very much I haven't logged in for a long time, but today I reinstalled postgresql-9.2.24 and used your latest 1.0.56 version Suddenly found a hint： github.com/USA-RedDragon/DMRHub/internal/db/db.go:68 [35;1mERROR: syntax error at or near "NOT" (SQLSTATE 42601) [0m[33m[1.000ms] [34;1m[rows:0][0m CREATE INDEX IF NOT EXISTS "idx_app_settings_deleted_at" ON "app_settings" ("deleted_at") It's weird. I don't know if it's just me At 2023-11-26 13:53:33, "Jacob McSwain" ***@***.***> wrote: I believe this is fixed with b3ec90e but my 2nd mmdvm isn't activating right now to test it. That commit will be in v1.0.46 when it releases tonight after I pull in dependency updates. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>