[Request] Add profile usage data to /metrics.json API to prevent user conflicts on shared profiles

[alexandrglm]

Feature Description:

Public ./metrics.json API Update to Track Shared Profiles and Prevent Conflicts

The issue is that when a profile is marked as "Shared", a new user connecting and changing the frequency can override the session of someone already using it. Currently, ordinary users have no way of knowing if a profile is in use.

I propose enhancing the public /metrics.json API by adding a profiles_usage section under openwebrx. This would provide, for each profile:

• Whether it is shared (isShared)
• Current frequency and mode (currentFreq, currentMode) if shared
• Digital decoding details (digData) if relevant
• Number of users currently active on that profile (active_users)

This change (the main idea of this request) would let the users be noticed, via further UI implementation, before they inadvertently overwrite someone else's session.

---

Here's an example of how the new data might look:

{
  "openwebrx": {

    "users": 16,


    "profiles_usage": {


      "RTL-SDR Device 1, 20m": {
        "shared_profile": {
          "isShared": true,
          "currentFreq": 14074000,
          "currentMode": "USB",
          "digData": {
            "isDig": true,
            "digMode": "FT8"
          }
        },
        "active_users": 5
      },


      "SDR Device 2, 40m": {
        "shared_profile": {
          "isShared": false
        },
        "active_users": 1


      }
    }
  }

// Actual metrics API json data ... 

}

---

Target Audience

This feature would benefit all users by keeping them informed about shared profile usage and who is currently connected:

• Helps prevent conflicts between users
• Makes coordination easier
• Maintains backward compatibility with the existing /metrics.json structure
• Minimal performance impact on metrics collection
• Only minor changes needed in the endpoint route at owrx/metrics.py and owrx/websocket.py

---

In the end, an admin could easily implement a panel to display this information to new users, or it could even be shown by default when selecting a Shared Profile.

---

Thanks in advance for considering my suggestion!
Alexandr.

[zaldih]

+1 to this. I think it would be great to implement a system that allows for coordinating the use of shared devices.

It is common to see users “fighting” over a profile, and a good way to avoid this would be to be able to configure how long a user must “cool down” before being able to “take over” the profile again, and how long to keep the channel reserved. This is just an additional idea to the original issue.

[jketterl]

Before we get any deeper into this... Try to put more effort into describing the actual problem, and try not to go into the technical solution yet. The reason I'm saying this is because the metrics API is for monitoring, and I don't consider it suitable for the use case you propose. Communication with the receiver client will have to use the websocket.

There is also no current system to mark a profile as "shared" (for whatever that would imply).

[alexandrglm]

Before we get any deeper into this... Try to put more effort into describing the actual problem, and try not to go into the technical solution yet. The reason I'm saying this is because the metrics API is for monitoring, and I don't consider it suitable for the use case you propose. Communication with the receiver client will have to use the websocket.

There is also no current system to mark a profile as "shared" (for whatever that would imply).

Firstly, thanks for the quick response.

As a user of several WebSDR based on OpenWebRx, I often face a recurring problem:

• Many administrators have multiple devices, which they assign as 'Profiles', according to band/device and its limitations.

• In many cases, some of these profiles are 'Shared Profiles' among all the connected users (due to the limitations of the device in use to acquire signal).

• This means, in example :

  1. "User A" is on a Shared Profile, tuned to a certain freq/mode.

  2. Then, "User B" joins into the WebSDR, selects the same Shared Profile, and tunes to their own desired freq/mode, cutting of the "User A"'s transmission without notifying him the reasons.

  3. Afterwards, more users join, unawared that others are already using the same Shared Profile, ending up overlapping each other without understanding what is happening.
     Most users in this situation tend to believe that the system core, or interface, is broken, which worsens the user experience.

In short, a marker indicating whether a Shared Profile is currently in use by others, or not, could help prevent conflict sbetween users, improving the overall user-experience.

---

On the other hand, implementation of something like this via the metrics API was suggested, since it is publicly accessible for the regular users and it would allow a simple further front-end integration showing markers like the one requested.

---

This is an outline of the problem, its underlying cause, and rationale/context about opening this request.

Thanks.
Alexandr

[jketterl]

Thank you. I think there's a bit of a misunderstanding as to the nature of a "shared" profile is. In my understanding, every profile is shared. I think what you're trying to do is to distinguish between scenarios where a device only offers a single profile (and as such, no interference with other users is possible) vs. scenarios where a device provides multiple profiles. Am I understanding this correctly?

[alexandrglm]

Yes.

I'm not native English speaker so that I called it a "Shared Profile" as you explained.

The main idea/goal is to distinguish these two scenarios (currently done so rude with emojis in the Devices List), but more intended "to be able to know when a profile that I've called before as Shared (where a change in tuning freq/mode affects all the other users in the same device) is in use by someone or it's free and available".