Ok, I think there is nothing more to do about it. I cannot reproduce the problem in my pc's, the newer server is installed in some other pc's too and it is working there, so I give up.

The latest github includes version 3.1.1, the latest stable for you Darko and Hendrik too.

This was the last update/upgrade of the PhanromSDR. No sense to try more updates, from the moment that the last version cannot work for everyone.

Hope enjoy the journey.

It is really a problem that the communication is only through the forum, but can you both retry with this install.sh?
I downloaded the latest from github, it was 3 minutes old, ran install.sh, nothing, the page crashes, I had to physically restart the computer, I couldn't kill the spectrumserver process (Debian 13 Trixie).

On a public computer, on Ubuntu 24.04, I first installed directly from github, the page crashed, no S meter, no frequencies. After that, I installed the latest install.sh from the forum, the same thing, everything crashed.

I think it would be a good idea to disable all scripts that are not absolutely necessary for the normal operation of PhantomSDR (statistics, users, support for websdr.org). The method of elimination might be able to find the cause of our troubles with v3.2.0.

Again, for the umpteenth time, I'm going back to v3.1.1 

73!

Very sorry about this.
It is really a problem that the communication is only through the forum, but can you both retry with this install.sh?

Also no luck with release 3.2.0.

I got here some of the same issues like Darko. After start:
- Volume is zero -> Display shows 50 %
- Mode is set to "USB" -> tml says modulation="AM"
- spectrum switch is on -> spectrum is off
- the frequency is only to see after mode switch (before set to 0)
- none by the 4 kinds of S-Meter is to see
- the yellow marker shows not the choosen frequency (middle of the band) but the RX tuning is OK
- no markers to see
- the "spectrumserver" needs now a long time (15 seconds) to finish

It seems the init is not runnig trough. Any ideas to detect the bug?

I use here Ubuntu 24 server with a fresh running install.sh.
http://mellesdr.rqhk191saz25euus.myfritz.net/

Best greetings from Berlin,
Hendrik

QuoteUntil yesterday Darko, your v.3.2.0 was working excellent on public server, except users, which were always with an IP address 127.0.0.1 That's way I've asked about your VPN.

The explanation for 127.0.0.1 is simple, nginx is on the same computer as PhantomSDR-Plus. It's a trick I borrowed from the Openwebrx distribution for RPI maintained by Stanislaw.
It converts the public port of Openwebrx (usually 8073) to port 80 on the same computer. That way I can reach the server locally without specifying an additional port, everything runs on port 80.

My VDSL router does NAT, so external port 8905 is sent to port 80 of the local PhantomSDR-Plus computer. Nginx converts that port 80 to local port 8905 and everything works, except printing a list of users with IP number 127.0.0.1

That's why I use that command in the command line to see the public IP addresses of users. My config for nginx looks like this:

[codeserver {
    listen 80 default_server;
    listen [::]:80 default_server;

    # SSL configuration

#    listen 443 ssl default_server;
#    listen [::]:443 ssl default_server;

    # Note: You should disable gzip for SSL traffic.
    # See: https://bugs.debian.org/773332

#    gzip off;

    # Read up on ssl_ciphers to ensure a secure configuration.
    # See: https://bugs.debian.org/765782
    #
    # Self signed certs generated by the ssl-cert package
    # Don't use them in a production server!

    include snippets/snakeoil.conf;

    set $upstream 127.0.0.1:8905;
        #set $upstream 127.0.0.1:6081;
        #set $upstream 192.168.3.11:8074;
       
    location / {
        proxy_pass http://$upstream;
        proxy_http_version 1.1;
        proxy_buffering off;

        # required for websockets
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $http_connection;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}
]

The problem with the actual IP number of the user in my case could perhaps be easily solved if the script instead of port 8905 looks at the traffic on ethernet port 80 of the computer where Phantom is running.

I repeat, these statistics mean nothing to me personally, I look at it from the command line. If there is a problem with traffic to and from my Phantom server , my provider is legally required to keep the log files, let the competent authorities ask them.   

And yes, from Croatia I can't connect the servers in Germany and Finland, it's been going on for months, since a colleague from Germany suggested that you add band-config.js to the src directory. I never, ever managed to connect to his server as a user.

Somehow it seems to me that the new statistics scripts want to retrieve something from the Internet that is inaccessible to me from Croatia, the form is not filled out and it distorts the entire front end of the new PhantomSDR server. (This is just my layman's opinion)

In the end, we are not professionals,
we are not pressed for deadlines, this is just fun.

73!

Until yesterday Darko, your v.3.2.0 was working excellent on public server, except users, which were always with an IP address 127.0.0.1 That's way I've asked about your VPN.
Anyway, trying to reproduce the problem you've mentioned has failed many times. Greek servers already running the newest version, the same in Argentina and Germany. I am waiting also Paulus to find time for a clean test install to his test server.

Yesterday I had guests and we were out in the sun all day. In the evening I tried v3.2.0 on a public server (without restarting the server) and the same problem appeared again, different widths of the websdr front end parts, no frequency, no S meter.

I returned v3.1.1 on the public server, v3.2.0 still runs just fine on the test server. I note that the test server runs on Ubuntu 24.0.4 WITHOUT OpenCL and with an RSP1A receiver (that's my public port 8906).

This morning I downloaded the latest version v.3.2.0 on Debian Trixie and it has the same phenomen, the same problem as on the main server. Debian Trixie has OpenCL just like the public server on Ubuntu 24.0.4.

I only use OpenVPN when I'm at work, there's Fortinet there that prevents me from accessing dynamic domains (they "forgot" to block the vpn port).

PhantomSDR has been behind the nginx proxy server for months, everything worked fine until the latest version of phantom. I don't think nginx has any effect on the broken appearance of v.3.2.0.

I personally don't care which user uses which frequency, internally sometimes I give the command netstat -tuan | grep internal_ip_of_my_local_server:80'
Then with whois ip_from_user I see from which country the user came.

On v3.2.0 I like the new Spectrum look, I'm interested in AGC, I don't need statistics.
I am not interested in detailed statistics.

I've been professionally maintaining a computer network for several years and I'm tired of looking at and analyzing log files.

73!

Very good Darko, I'm very glad to read it!
Maybe the problem with users is the fact that you are behind a VPN. Can you please try this file in backend to see if it could solve the problem? If not, may I have some details about your VPN?
Don't forget to recompile backend and restart server.

QuoteTried to fix the problems Darko has mentioned, I've doubled checked all the backend files. AI has found some issues, fixed and all new uploaded again.
I hope there will be not any problems now with any OS....

It works fine on Debian 13 (Trixie) and Ubuntu 24.0.4 now. Thanks to the development team for the quick and successful fix. 

There is a small problem when I want to stop websdr via systemd, it takes maybe 20 seconds:

root@minipc:/home/darko/PhantomSDR-Plus# service websdr status
● websdr.service - PhantomSDRPlus WebSDR
     Loaded: loaded (/etc/systemd/system/websdr.service; disabled; preset: enabled)
     Active: deactivating (final-sigterm) since Fri 2026-05-01 07:40:16 CEST; 1min 24s ago
    Process: 349780 ExecStart=/home/darko/PhantomSDR-Plus/start-websdr.sh (code=killed, signal=TERM)
   Main PID: 349780 (code=killed, signal=TERM)
      Tasks: 5 (limit: 18771)
     Memory: 311.6M (peak: 320.3M)
        CPU: 11min 13.474s
     CGroup: /system.slice/websdr.service
             └─349784 build/spectrumserver --config config-rx888mk2.toml

svi 01 07:34:26 minipc start-websdr.sh[349784]: write_users_json: cannot open frontend/dist/users.json.tmp
svi 01 07:34:27 minipc start-websdr.sh[349784]: write_users_json: cannot open frontend/dist/users.json.tmp
svi 01 07:34:28 minipc start-websdr.sh[349784]: write_users_json: cannot open frontend/dist/users.json.tmp
svi 01 07:34:29 minipc start-websdr.sh[349784]: write_users_json: cannot open frontend/dist/users.json.tmp
svi 01 07:34:30 minipc start-websdr.sh[349784]: write_users_json: cannot open frontend/dist/users.json.tmp
svi 01 07:34:31 minipc start-websdr.sh[349784]: write_users_json: cannot open frontend/dist/users.json.tmp
svi 01 07:34:32 minipc start-websdr.sh[349784]: write_users_json: cannot open frontend/dist/users.json.tmp
svi 01 07:34:33 minipc start-websdr.sh[349784]: write_users_json: cannot open frontend/dist/users.json.tmp
svi 01 07:34:34 minipc start-websdr.sh[349784]: write_users_json: cannot open frontend/dist/users.json.tmp
svi 01 07:40:16 minipc systemd[1]: Stopping websdr.service - PhantomSDRPlus WebSDR...
root@minipc:/home/darko/PhantomSDR-Plus# ps aux | grep spectrumserver
root      400661  0.0  0.0   9580  2404 pts/2    S+   07:41   0:00 grep --color=auto spectrumserver
root@minipc:/home/darko/PhantomSDR-Plus#
That slows down the reboot for those 20 seconds, of course.
Not a big problem, I expect the server to restart as rarely as possible. 

73!

Tried to fix the problems Darko has mentioned, I've doubled checked all the backend files. AI has found some issues, fixed and all new uploaded again.
I hope there will be not any problems now with any OS....