Localhost refused connection

[user29 2]

@Luke

 

The 1 were simply me renaming the plugins (as per ebr request)

These have now been deleted.

Emby starts - but still is unonnectable / refusing connection.

Log file here...

THanks for helping!

 

 

embyserver.txt

[visproduction 125]

Browser log for test non-member server shows undefined variables that appear to cause a Websocket failure in apiclient.js line 80.  Look at the log from line 327 to the end.  Suspect that no valid membership license results in undefined variable issues which causes Web socket look up to go into an infinity loop.  Variable for items is not defined inside docktabs.js, homesections.js and apiclient.js has no exception for this and install is stuck in a loop.

Inside dockedtabs.js is code trying to pull Items.length, but Items is not defined.  Is this expected or is this a result of no membership authentication and was overlooked during QA testing?
 

Quote

 for (var i = 0, length = result.Items.length; i < length && !(5 <= tabs.length); i++)
                    tabs.push({
                        name: result.Items[i].Name,
                        icon: _itemmanager.default.getDefaultIcon(result.Items[i]),
                        href: _approuter.default.getRouteUrl(result.Items[i])
                    });

Similar undefined Items variable inside homesections.js

    function getUserViews(apiClient, userId) {
        return apiClient.getUserViews({}, userId || apiClient.getCurrentUserId()).then(function(result) {
            return result.Items
        })

Perhaps Items should get a starting declaration variable so these undefined errors do not happen.  Can anyone reproduce this error on a non-member demo server?  Was the update tested on a non-member server?  I only tested it on one setup.  Maybe it was caused by something else.

 

Just a guess.

localhost-1706914012550.log

Edited February 3 by visproduction

[user29 2]

2 hours ago, user29 said:

@Luke

 

The 1 were simply me renaming the plugins (as per ebr request)

These have now been deleted.

Emby starts - but still is unonnectable / refusing connection.

Log file here...

THanks for helping!

 

 

embyserver.txt 31.44 kB · 2 downloads

I have left it running (and will keep it running) but its at 1.2MB memory and 0% processing - so i dont think its doing anything.

[btemple 1]

Having the same problem.  Can only guess that the new 4.8.0.80 release introduced some sort of issue opening port 8096 on windows servers.  Only a basic assumption as running a netstat to check open ports doesn't list 8096.  Regardless, had a go at cobbling together a Frankenstein install of Emby by manually backing up my config, doing a clean install, and then moving config back in one at a time until it failed.  As best as I can guess, the issue is with this file set:

activitylog.db
activitylog.db-shm
activitylog.db-wal

These files come from the new 4.8.0.80 package, and when I replace them with the original files from the prior release localhost connection fails.  Not dug into what's in this file set, and haven't copied over all of the config as there's a lot of old stuff in there that has probably been depricated over the years, so not 100% certainty on this.  Regardless, have most of my config manually restored and server is up and running, so have an interim fix until a full solution can be provided. 

[visproduction 125]

More clues: 
connectionManager requests url that has a 400 error at mb3admin.com

I get the same error with the parameter?serverID= validation on this test.  This is perhaps expected for the non-license status.  This error was ignored in 4.7xxx but appears maybe to throw an error now in 4.8 resulting in undefined variable for 'Items'.  I think 4.7 had this situation tweaked to allow non-license server to continue, but 4.8 does not.  Maybe just declaring a starting variable for 'Items' in the js files would fix this.

 

Edited February 3 by visproduction

[Luke 37247]

14 hours ago, btemple said:

Having the same problem.  Can only guess that the new 4.8.0.80 release introduced some sort of issue opening port 8096 on windows servers.  Only a basic assumption as running a netstat to check open ports doesn't list 8096.  Regardless, had a go at cobbling together a Frankenstein install of Emby by manually backing up my config, doing a clean install, and then moving config back in one at a time until it failed.  As best as I can guess, the issue is with this file set:

activitylog.db
activitylog.db-shm
activitylog.db-wal

These files come from the new 4.8.0.80 package, and when I replace them with the original files from the prior release localhost connection fails.  Not dug into what's in this file set, and haven't copied over all of the config as there's a lot of old stuff in there that has probably been depricated over the years, so not 100% certainty on this.  Regardless, have most of my config manually restored and server is up and running, so have an interim fix until a full solution can be provided. 

It could just be the database upgrade taking a long time. You could just delete the activity db files if you don’t mind the activity log starting from a blank slate.

[btemple 1]

6 hours ago, Luke said:

It could just be the database upgrade taking a long time. You could just delete the activity db files if you don’t mind the activity log starting from a blank slate.

Depends on what a "long time" would be.  By the time I got around to having a look at it, it'd been about 36 hours since the update.  Would the database upgrading cause a localhost connection failure?

[Luke 37247]

16 hours ago, btemple said:

Depends on what a "long time" would be.  By the time I got around to having a look at it, it'd been about 36 hours since the update.  Would the database upgrading cause a localhost connection failure?

Hi, did it complete?

[btemple 1]

22 hours ago, Luke said:

Hi, did it complete?

Not sure if I can tell how/when it's completed.  If you can let me know, i can test it out a bit.

FYI, I uninstalled, removing all files from the "Emby-Server" folder.  Ran a clean install, and then copied in all of the "programdata" files from my backup.  When I launched the browser on the server to connect to localhost, it failed (same as the other messages in this thread). I stopped the server and renamed the 3 activitylog files to .bak, and started it up again.  Everthing started just fine (with the server re-creating the activitylog files). So, looks like some sort of corruption in my files. 

I'm happy to drop the backup files back in again to test it, but since I can't manage the server from the browser to check status on anything when they're in place, I'll need to know what else to look for to see if the database upgrade completes.  

Ultimately, I'm not that bothered to lose the activity log.  More just happy to have the server up and running. 

[MEtaLpREs 0]

On 2/5/2024 at 5:37 PM, btemple said:

Not sure if I can tell how/when it's completed.  If you can let me know, i can test it out a bit.

FYI, I uninstalled, removing all files from the "Emby-Server" folder.  Ran a clean install, and then copied in all of the "programdata" files from my backup.  When I launched the browser on the server to connect to localhost, it failed (same as the other messages in this thread). I stopped the server and renamed the 3 activitylog files to .bak, and started it up again.  Everthing started just fine (with the server re-creating the activitylog files). So, looks like some sort of corruption in my files. 

I'm happy to drop the backup files back in again to test it, but since I can't manage the server from the browser to check status on anything when they're in place, I'll need to know what else to look for to see if the database upgrade completes.  

Ultimately, I'm not that bothered to lose the activity log.  More just happy to have the server up and running. 

Was having the same error since the 4.8 update, this is the solution that worked for me.  backed up the programdata folder, completely wiped all traces of emby, did a fresh install and copied the programdata folder back over with the 3 activity log files renamed.

Emby is now working perfectly again.  Was really driving me crazy thinking it was some sort of windows networking issue.  Thanks for your solution.

[btemple 1]

On 05/02/2024 at 22:37, btemple said:

Not sure if I can tell how/when it's completed.  If you can let me know, i can test it out a bit.

FYI, I uninstalled, removing all files from the "Emby-Server" folder.  Ran a clean install, and then copied in all of the "programdata" files from my backup.  When I launched the browser on the server to connect to localhost, it failed (same as the other messages in this thread). I stopped the server and renamed the 3 activitylog files to .bak, and started it up again.  Everthing started just fine (with the server re-creating the activitylog files). So, looks like some sort of corruption in my files. 

I'm happy to drop the backup files back in again to test it, but since I can't manage the server from the browser to check status on anything when they're in place, I'll need to know what else to look for to see if the database upgrade completes.  

Ultimately, I'm not that bothered to lose the activity log.  More just happy to have the server up and running. 

Just in case anyone else has this problem, the steps to fix (assuming you don't care about your activity log) are really just to stop the server, delete (or back up) the 3 activitylog files in \programdata\data, and restart the server.  No real need to back up and restore everything else on a clean install.  When you start the server back up, it'll recreate the activitylog files and you should be good to go.

[Happy2Play 8356]

8 minutes ago, btemple said:

Just in case anyone else has this problem, the steps to fix (assuming you don't care about your activity log) are really just to stop the server, delete (or back up) the 3 activitylog files in \programdata\data, and restart the server.  No real need to back up and restore everything else on a clean install.  When you start the server back up, it'll recreate the activitylog files and you should be good to go.

Note the shm and wal files represent an open database.  With a closed database there will only be one file.