[Bug]: Socket failed to connect (webapp and android mobile app) #2511

Originally created by @alternativesurfer on GitHub (Jan 20, 2025).

What happened?

Log error: [SocketAuthority] clientEmitter - no clients found for user 06835809-8b6a-47fe-81fd-1677b1ddf6c6

Webclient error:

Android app error:

Within the web client, all functionality appears to still work (playback, etc).
On Android, I cannot flip between Podcasts/Audiobooks (I am stuck on audiobooks). Playback works and syncs playback location.

What did you expect to happen?

The websocket connects.

Steps to reproduce the issue

Launch app.
error exists

Audiobookshelf version

v2.18.0

How are you running audiobookshelf?

Docker

What OS is your Audiobookshelf server hosted from?

Linux

If the issue is being seen in the UI, what browsers are you seeing the problem on?

Other (list in "Additional Notes" box)

Logs

The only thing I can see related to the websocket is: 
2025-01-20 20:52:05.099

DEBUG

[SocketAuthority] clientEmitter - no clients found for user 06835809-8b6a-47fe-81fd-1677b1ddf6c6

Additional Notes

UI errors:
Edge
Firefox (windows)
Fennec (Android)

as well as the Android Audiobookshelf App & Lissen app.

Originally created by @alternativesurfer on GitHub (Jan 20, 2025). ### What happened? Log error: [SocketAuthority] clientEmitter - no clients found for user 06835809-8b6a-47fe-81fd-1677b1ddf6c6 Webclient error: ![Image](https://github.com/user-attachments/assets/e76bbb2f-0aba-4a31-876c-54ea78b65dc2) Android app error: ![Image](https://github.com/user-attachments/assets/91887d2d-0708-4726-b6f1-9d80c995187f) Within the web client, all functionality appears to still work (playback, etc). On Android, I cannot flip between Podcasts/Audiobooks (I am stuck on audiobooks). Playback works and syncs playback location. ### What did you expect to happen? The websocket connects. ### Steps to reproduce the issue 1. Launch app. 2. error exists ### Audiobookshelf version v2.18.0 ### How are you running audiobookshelf? Docker ### What OS is your Audiobookshelf server hosted from? Linux ### If the issue is being seen in the UI, what browsers are you seeing the problem on? Other (list in "Additional Notes" box) ### Logs ```shell The only thing I can see related to the websocket is: 2025-01-20 20:52:05.099 DEBUG [SocketAuthority] clientEmitter - no clients found for user 06835809-8b6a-47fe-81fd-1677b1ddf6c6 ``` ### Additional Notes UI errors: Edge Firefox (windows) Fennec (Android) as well as the Android Audiobookshelf App & Lissen app.

adam added the bug label 2026-04-25 00:07:52 +02:00

adam closed this issue

adam commented

@advplyr commented on GitHub (Jan 20, 2025):

Are you using a reverse proxy or local ip?

@advplyr commented on GitHub (Jan 20, 2025): Are you using a reverse proxy or local ip?

adam commented

@Dork74 commented on GitHub (Jan 20, 2025):

Same error with android app and also unable to connect via web client.

Running in Docker on Synology

Web error:
Unable to connect error on PC

"The connection was reset
The connection to the server was reset while the page was loading."

Log says listening on port 1333

@Dork74 commented on GitHub (Jan 20, 2025): Same error with android app and also unable to connect via web client. Running in Docker on Synology Web error: Unable to connect error on PC "The connection was reset The connection to the server was reset while the page was loading." Log says listening on port 1333

adam commented

@advplyr commented on GitHub (Jan 20, 2025):

Was this working for you on prior versions?
Are you using a reverse proxy? If so, can you also replicate the issue with local ip address.

@advplyr commented on GitHub (Jan 20, 2025): 1. Was this working for you on prior versions? 2. Are you using a reverse proxy? If so, can you also replicate the issue with local ip address.

adam commented

@Dork74 commented on GitHub (Jan 20, 2025):

Worked fine prior to today's update.
Local IP: port 13378

Used the same bookmark with address that I've always used

Android giving Failed to ping server error (connection reset)

@Dork74 commented on GitHub (Jan 20, 2025): 1. Worked fine prior to today's update. 2. Local IP: port 13378 Used the same bookmark with address that I've always used Android giving Failed to ping server error (connection reset)

adam commented

@vampy101 commented on GitHub (Jan 21, 2025):

I'm seeing this as well on my instance even after upgrading to the 2.18.1. I am using a reverse proxy (apache) to access it.

I did check connecting directly and it does not show up that way.

@vampy101 commented on GitHub (Jan 21, 2025): I'm seeing this as well on my instance even after upgrading to the 2.18.1. I am using a reverse proxy (apache) to access it. I did check connecting directly and it does not show up that way.

adam commented

@ritniotvor commented on GitHub (Jan 21, 2025):

Same problem, updated today, and after the update I can't get to the site anymore. Neither through local ip, nor through reversproxy :(

@ritniotvor commented on GitHub (Jan 21, 2025): Same problem, updated today, and after the update I can't get to the site anymore. Neither through local ip, nor through reversproxy :( ![Image](https://github.com/user-attachments/assets/c5fa538d-3444-4eca-8e39-47d4783e3507)

adam commented

@20CCAA07 commented on GitHub (Jan 21, 2025):

After updating from version v2.17.7 to the latest version v2.18.1 via Synology's Container Manager today, I could no longer access Audiobookshelf via the local IP address on either iOS or a web browser.

I then compared the log files from before and after the update and found the following difference:

Before the update (v2.17.7): Listening on port :80
After the update (v2.18.1): Listening on port :3333

As a workaround, I resolved the issue for me by:

Stopping the container in Synology's Container Manager.
Manually changing the mapping for port 13378 from 80 to 3333 within the Settings menu.
Restarting the container.

After this adjustment, I was able to access Audiobookshelf again on both iOS and web browsers.

@ritniotvor : Since you use Synology, too, this might solve your problem for now as well.

@advplyr : It seems like that Audiobookshelf now listens on port 3333 per default. Will it continue to do so or will this be reverted to port 80 again with a later update, that is if the default port is hard coded (I guess)?

@20CCAA07 commented on GitHub (Jan 21, 2025): After updating from version v2.17.7 to the latest version v2.18.1 via Synology's Container Manager today, I could no longer access Audiobookshelf via the local IP address on either iOS or a web browser. I then compared the log files from before and after the update and found the following difference: Before the update (v2.17.7): Listening on port :80 After the update (v2.18.1): Listening on port :3333 As a workaround, I resolved the issue for me by: 1. Stopping the container in Synology's Container Manager. 2. Manually changing the mapping for port 13378 from 80 to 3333 within the Settings menu. 3. Restarting the container. After this adjustment, I was able to access Audiobookshelf again on both iOS and web browsers. @ritniotvor : Since you use Synology, too, this might solve your problem for now as well. ![Image](https://github.com/user-attachments/assets/c8c0ee75-4b29-4253-bec2-23777ceeba23) @advplyr : It seems like that Audiobookshelf now listens on port 3333 per default. Will it continue to do so or will this be reverted to port 80 again with a later update, that is if the default port is hard coded (I guess)?

adam commented

@lsixecho commented on GitHub (Jan 21, 2025):

@20CCAA07 This works! Good sleuthing. I was seeing in the logs "listing on port 3333" and thought that was odd, but that's as far as I got before I checked the issues. Thanks again!

@lsixecho commented on GitHub (Jan 21, 2025): @20CCAA07 This works! Good sleuthing. I was seeing in the logs "listing on port 3333" and thought that was odd, but that's as far as I got before I checked the issues. Thanks again!

adam commented

@Dork74 commented on GitHub (Jan 21, 2025):

@20CCAA07
Thanks for the workaround. I noted the port change in my original post because I thought that was strange but @advplyr didn't make any comment on that.

@Dork74 commented on GitHub (Jan 21, 2025): @20CCAA07 Thanks for the workaround. I noted the port change in my original post because I thought that was strange but @advplyr didn't make any comment on that.

adam commented

@advplyr commented on GitHub (Jan 21, 2025):

I'm not familiar with Synology, what docker container are you pulling in? Are you using a docker run script?

@advplyr commented on GitHub (Jan 21, 2025): I'm not familiar with Synology, what docker container are you pulling in? Are you using a docker run script?

adam commented

@advplyr commented on GitHub (Jan 21, 2025):

This and some messages on Discord from other Synology users are making this really confusing. A user just said they removed and re-created the container in Synology Container Station app and it is now listening on port 80 (with no other changes).

The Dockerfile for the official Abs docker images was updated to specify port 80. When I start the container for latest tag I can see that it is listening on port 80.

If the port was actually changed it would break for thousands of users but it seems it has only broken for users using Synology.

Are you able to see the docker run command that Synology is using? Maybe it is overriding the PORT env variable defined in the Dockerfile with an empty value?

@advplyr commented on GitHub (Jan 21, 2025): This and some messages on Discord from other Synology users are making this really confusing. A user just said they removed and re-created the container in Synology Container Station app and it is now listening on port 80 (with no other changes). The [Dockerfile](https://github.com/advplyr/audiobookshelf/blob/master/Dockerfile#L49) for the official Abs docker images was updated to specify port 80. When I start the container for `latest` tag I can see that it is listening on port 80. If the port was actually changed it would break for thousands of users but it seems it has only broken for users using Synology. Are you able to see the docker run command that Synology is using? Maybe it is overriding the PORT env variable defined in the Dockerfile with an empty value?

adam commented

@jrhedman commented on GitHub (Jan 21, 2025):

If it helps:

Partial output of docker container inspect:

            "ContainerIDFile": "",
            "LogConfig": {
                "Type": "db",
                "Config": {}
            },
            "NetworkMode": "bridge",
            "PortBindings": {
                "80/tcp": [
                    {
                        "HostIp": "",
                        "HostPort": "49154"
                    }
                ]
            },
            "RestartPolicy": {
                "Name": "always",
                "MaximumRetryCount": 0
            },

docker logs shows it's listening on port 3333 however:

> audiobookshelf@2.18.1 start
> node index.js

Running in production mode.
Options: CONFIG_PATH=/config, METADATA_PATH=/metadata, PORT=3333, HOST=undefined, SOURCE=debian, ROUTER_BASE_PATH=/audiobookshelf

...

[2025-01-21 11:41:49.468] INFO: [Watcher] Initializing watcher for "Audiobooks".
[2025-01-21 11:41:49.468] DEBUG: [Watcher] Init watcher for library folder path "/Audiobooks"
[2025-01-21 11:41:49.470] INFO: [Watcher] Initializing watcher for "Podcasts".
[2025-01-21 11:41:49.470] DEBUG: [Watcher] Init watcher for library folder path "/Podcasts"
[2025-01-21 11:41:49.483] INFO: Listening on port :3333
[2025-01-21 11:41:50.110] INFO: [Watcher] "Podcasts" Ready
[2025-01-21 11:41:51.236] INFO: [Watcher] "Audiobooks" Ready

Edit: added more detail to docker logs showing it's attempting to use port 3333

@jrhedman commented on GitHub (Jan 21, 2025): If it helps: Partial output of `docker container inspect`: ``` "ContainerIDFile": "", "LogConfig": { "Type": "db", "Config": {} }, "NetworkMode": "bridge", "PortBindings": { "80/tcp": [ { "HostIp": "", "HostPort": "49154" } ] }, "RestartPolicy": { "Name": "always", "MaximumRetryCount": 0 }, ``` `docker logs` shows it's listening on port 3333 however: ``` > audiobookshelf@2.18.1 start > node index.js Running in production mode. Options: CONFIG_PATH=/config, METADATA_PATH=/metadata, PORT=3333, HOST=undefined, SOURCE=debian, ROUTER_BASE_PATH=/audiobookshelf ... [2025-01-21 11:41:49.468] INFO: [Watcher] Initializing watcher for "Audiobooks". [2025-01-21 11:41:49.468] DEBUG: [Watcher] Init watcher for library folder path "/Audiobooks" [2025-01-21 11:41:49.470] INFO: [Watcher] Initializing watcher for "Podcasts". [2025-01-21 11:41:49.470] DEBUG: [Watcher] Init watcher for library folder path "/Podcasts" [2025-01-21 11:41:49.483] INFO: Listening on port :3333 [2025-01-21 11:41:50.110] INFO: [Watcher] "Podcasts" Ready [2025-01-21 11:41:51.236] INFO: [Watcher] "Audiobooks" Ready ``` **Edit: added more detail to docker logs showing it's attempting to use port 3333**

adam commented

@advplyr commented on GitHub (Jan 21, 2025):

Thanks. Can you pull the image again and start a new container? And if Synology shows you the docker run command that it is using that would be the most helpful I think.

@advplyr commented on GitHub (Jan 21, 2025): Thanks. Can you pull the image again and start a new container? And if Synology shows you the docker run command that it is using that would be the most helpful I think.

adam commented

@Dork74 commented on GitHub (Jan 21, 2025):

Same as the Discord user, I duplicated and exported settings of the container, deleted original (after praying it wouldn't delete the database), then ran the copy and it is magically back to port 80.

@Dork74 commented on GitHub (Jan 21, 2025): Same as the Discord user, I duplicated and exported settings of the container, deleted original (after praying it wouldn't delete the database), then ran the copy and it is magically back to port 80.

adam commented

@advplyr commented on GitHub (Jan 21, 2025):

Thanks, it would be great to know how Synology is running the containers.
Make sure you taking regular backups using the backup manager in Abs. So long as the volume paths are the same in the docker container those backups can be used to fully restore Abs.

@advplyr commented on GitHub (Jan 21, 2025): Thanks, it would be great to know how Synology is running the containers. Make sure you taking regular backups using the backup manager in Abs. So long as the volume paths are the same in the docker container those backups can be used to fully restore Abs.

adam commented

@jrhedman commented on GitHub (Jan 21, 2025):

Can confirm @Dork74's findings:

docker logs after simply duplicating the container and running the copy shows it's now listening on port 80:

> audiobookshelf@2.18.1 start
> node index.js

Running in production mode.
Options: CONFIG_PATH=/config, METADATA_PATH=/metadata, PORT=80, HOST=undefined, SOURCE=docker, ROUTER_BASE_PATH=/audiobookshelf

...

[2025-01-21 12:08:27.778] INFO: [Watcher] Initializing watcher for "Audiobooks".
[2025-01-21 12:08:27.778] DEBUG: [Watcher] Init watcher for library folder path "/Audiobooks"
[2025-01-21 12:08:27.782] INFO: [Watcher] Initializing watcher for "Podcasts".
[2025-01-21 12:08:27.782] DEBUG: [Watcher] Init watcher for library folder path "/Podcasts"
[2025-01-21 12:08:27.808] INFO: Listening on port :80
[2025-01-21 12:08:35.626] INFO: [Watcher] "Podcasts" Ready
[2025-01-21 12:08:42.564] INFO: [Watcher] "Audiobooks" Ready

I noticed in the inspect the org.opencontainers.image.version on the faulty container was for some reason showing as 2.14.0!

I'm wondering if there's some cacheing that Synology is doing using their container manager which was causing the js file to go with using port 3333.

Bug certainly seems to be on Synology's side and not with Audiobookshelf. ~~Synology Users using the Container Manager should duplicate settings to a new container, re-add their port mappings and start the new container.~~

(These little things are why I'm moving further from using Synology's management tool and more interacting with docker directly)

We should be able to close the issue and people can use the above fix.

EDIT: Did some more digging. Best fix for Synology users is to bring their container down, choose action -> reset and then start the container again.

It looks like Synology was calling the entrypoint at startup docker-entrypoint.sh which might be where the issue comes from. Resetting the container changed it to tini.

I'll try to research more when I have a chance. It would explain some issues I've noticed with some container updates in the past where I had to essentially copy and build a new container in it's place. But that should deal with the issue here.

@jrhedman commented on GitHub (Jan 21, 2025): Can confirm @Dork74's findings: docker logs after simply duplicating the container and running the copy shows it's now listening on port 80: ``` > audiobookshelf@2.18.1 start > node index.js Running in production mode. Options: CONFIG_PATH=/config, METADATA_PATH=/metadata, PORT=80, HOST=undefined, SOURCE=docker, ROUTER_BASE_PATH=/audiobookshelf ... [2025-01-21 12:08:27.778] INFO: [Watcher] Initializing watcher for "Audiobooks". [2025-01-21 12:08:27.778] DEBUG: [Watcher] Init watcher for library folder path "/Audiobooks" [2025-01-21 12:08:27.782] INFO: [Watcher] Initializing watcher for "Podcasts". [2025-01-21 12:08:27.782] DEBUG: [Watcher] Init watcher for library folder path "/Podcasts" [2025-01-21 12:08:27.808] INFO: Listening on port :80 [2025-01-21 12:08:35.626] INFO: [Watcher] "Podcasts" Ready [2025-01-21 12:08:42.564] INFO: [Watcher] "Audiobooks" Ready ``` --- I noticed in the inspect the `org.opencontainers.image.version` on the faulty container was for some reason showing as `2.14.0`! I'm wondering if there's some cacheing that Synology is doing using their container manager which was causing the js file to go with using port 3333. --- Bug certainly seems to be on Synology's side and not with Audiobookshelf. ~~Synology Users using the Container Manager should duplicate settings to a new container, re-add their port mappings and start the new container.~~ (These little things are why I'm moving further from using Synology's management tool and more interacting with docker directly) We should be able to close the issue and people can use the above fix. --- **EDIT:** Did some more digging. Best fix for Synology users is to bring their container down, choose action -> reset and then start the container again. It looks like Synology was calling the entrypoint at startup `docker-entrypoint.sh` which might be where the issue comes from. Resetting the container changed it to `tini`. I'll try to research more when I have a chance. It would explain some issues I've noticed with some container updates in the past where I had to essentially copy and build a new container in it's place. But that should deal with the issue here.

adam commented

@advplyr commented on GitHub (Jan 21, 2025):

Thanks for digging into it. It does seem to be something with caching although it wouldn't be the js file since that is in the container.

If someone reaches out to Synology about this please share it here. I'm sure it is not the first time this has come up.

@advplyr commented on GitHub (Jan 21, 2025): Thanks for digging into it. It does seem to be something with caching although it wouldn't be the js file since that is in the container. If someone reaches out to Synology about this please share it here. I'm sure it is not the first time this has come up.

adam commented

@Dork74 commented on GitHub (Jan 21, 2025):

Have been running Abs (and a few other containers) for many months, including updates, with no problems. Not sure why Synology hated Abs this time. I'm a Docker noob, so of little help. Container Manager hasn't updated since 20.10.2023 (yes 2023 not 2024)

I make daily backups and keep them for 7 day. I have over 3500 audiobooks so wouldn't want to start from scratch.

Let me just take this time to thank you for this really awesome project. Actually Abs is what convinced me to start using Docker.

@Dork74 commented on GitHub (Jan 21, 2025): Have been running Abs (and a few other containers) for many months, including updates, with no problems. Not sure why Synology hated Abs this time. I'm a Docker noob, so of little help. Container Manager hasn't updated since 20.10.2023 (yes 2023 not 2024) I make daily backups and keep them for 7 day. I have over 3500 audiobooks so wouldn't want to start from scratch. Let me just take this time to thank you for this really awesome project. Actually Abs is what convinced me to start using Docker.

adam commented

@jrhedman commented on GitHub (Jan 21, 2025):

@Dork74 Fun fact, if you ssh into your Synology and deploy via docker on the command line, you can still use the container manager interface once the container is deployed, it will show up on the list the same.

This way you can practice getting your hands more dirty with docker directly and slowly remove the training wheels.

I'm slowly migrating away from the UI myself and AudiobookShelf was one of the one's I haven't touched yet which is why I caught the issue too. I'm sure it will affect novices most directly as beginners may not have as much intimate knowledge of how docker works behind the scenes.

Always keep learning and make your data your own! AudiobookShelf is one of the pillars of the self-hosting world imo and the number of people who will get into it will only keep growing. I've always enjoyed working with @advplyr when things come up and can understand why the community is so drawn towards this project.

Thanks again for all you do!

@jrhedman commented on GitHub (Jan 21, 2025): @Dork74 Fun fact, if you ssh into your Synology and deploy via docker on the command line, you can still use the container manager interface once the container is deployed, it will show up on the list the same. This way you can practice getting your hands more dirty with docker directly and slowly remove the training wheels. I'm slowly migrating away from the UI myself and AudiobookShelf was one of the one's I haven't touched yet which is why I caught the issue too. I'm sure it will affect novices most directly as beginners may not have as much intimate knowledge of how docker works behind the scenes. Always keep learning and make your data your own! AudiobookShelf is one of the pillars of the self-hosting world imo and the number of people who will get into it will only keep growing. I've always enjoyed working with @advplyr when things come up and can understand why the community is so drawn towards this project. Thanks again for all you do!

adam commented

@alternativesurfer commented on GitHub (Jan 21, 2025):

Was this working for you on prior versions?

Are you using a reverse proxy? If so, can you also replicate the issue with local ip address.

Hi, OP here.
I do not use Synology, just running Docker on an ubuntu server.
This seems unrelated to the Synology people since I never lost access to my front end.

This was working previously on 2.17.3 without error.
I was out of town so didn't patch between then and 2.18.0.

I am running through HAProxy. No config change on that end.
The only thing failing is the Socket error. I am able to load the GUI and playback items.

Direct to IP also works, but with the same socket error.

@alternativesurfer commented on GitHub (Jan 21, 2025): > 1. Was this working for you on prior versions? > 2. Are you using a reverse proxy? If so, can you also replicate the issue with local ip address. Hi, OP here. I do not use Synology, just running Docker on an ubuntu server. This seems unrelated to the Synology people since I never lost access to my front end. This was working previously on 2.17.3 without error. I was out of town so didn't patch between then and 2.18.0. I am running through HAProxy. No config change on that end. The only thing failing is the Socket error. I am able to load the GUI and playback items. Direct to IP also works, but with the same socket error.

adam commented

@alternativesurfer commented on GitHub (Jan 24, 2025):

Something definitely changed, because previously there were no websocket issues when I used HAProxy (not Apache).

Now my console is filled with these errors:

Timing wise, I suspect this is what broke it: https://github.com/advplyr/audiobookshelf/pull/3754
I added the env flag: EXP_PROXY_SUPPORT=1 to test, still not working.

So, I believewhatever fix was put into place for that issue broke proxy support for those of us it was already working for.

@alternativesurfer commented on GitHub (Jan 24, 2025): Something definitely changed, because previously there were no websocket issues when I used HAProxy (not Apache). Now my console is filled with these errors: ![Image](https://github.com/user-attachments/assets/cbccb6c9-a09d-45bf-a989-516dc19b07a9) Timing wise, I suspect this is what broke it: https://github.com/advplyr/audiobookshelf/pull/3754 I added the env flag: EXP_PROXY_SUPPORT=1 to test, still not working. So, I believewhatever fix was put into place for that issue broke proxy support for those of us it was already working for.

adam commented

@jstaubr commented on GitHub (Jan 31, 2025):

Older docker image did not have ENV "PORT=80". The new one I pulled has.
Don't know where it came up with the port number 3333 though.

@jstaubr commented on GitHub (Jan 31, 2025): Older docker image did not have ENV "PORT=80". The new one I pulled has. Don't know where it came up with the port number 3333 though.

adam commented