web interface masked frequently by "CONNECTING..." overlay

Volumio Development Bug reports
1

Since the release of version 1.55 I unfortunately got the issue that the webinterface is masked by the “CONNECTING…” overlay frequently.
It doesn’t matter where exectly in the webinterface I am at this moment - the issue appears on the main site as well as on all sub sites.
The time before the Connecting overlay comes up varies from <5 seconds up to >20 seconds. When simply reloading the webinterface within the browser I am able to interact with it normally. Also when the next song of the current playlist starts to play, the connecting overlay disappears.

The MPD itself or an established ssh connection to the raspberry aren’t effected by this issue.

The issue also appears with a fresh installed volumio from the recent image download. Changing the SD-Card doesn’t change anything. It’s also nonrelevant if the raspberry is conencted to my network via LAN or WLAN.

Only hint I was able to find in the nginx error.log (/var/log/nginx/error.log) is the following error message, which appears withing the error.log multiple times on every sigle uptime of the raspberry:

2015/04/07 14:46:31 [error] 2539#0: *139 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 192.168.0.30, server: , request: "GET /_player_engine_spop.php?state=play&_=1428414380746 HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "192.168.0.26", referrer: "http://192.168.0.26/" 2015/04/07 14:46:31 [error] 2539#0: *139 open() "/etc/nginx/html/50x.html" failed (2: No such file or directory), client: 192.168.0.30, server: , request: "GET /_player_engine_spop.php?state=play&_=1428414380746 HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "192.168.0.26", referrer: "http://192.168.0.26/"

Best regards
Stefan

2

Same situation here!

3

Same problem here, with clean install of image on a Raspberry Pi B.
Not sure what causes the problem or how to find the cause…

All help is welcome.

4

I have the same problem (even with with clean install :frowning: )…

5

I get this as well, however refreshing the web page fixes it pretty quickly.

6

Mine, too. refreshing the page works but when you’re setting things up (nas, webradio, Spotify etc) you get almost all the details in and BAM! connecting screen! refresh the page, all info gone so you have to start from scratch (and hope you succeed before it pops up again) very frustrating! it seems to do it more on my windoze phone than pc or iPhone… (I had the same issue on v1.51 and 1.55) I did a ‘dirty’ fix by putting a ‘resume’ button on the connecting screen but so far it only refreshes the page, I need to try and make it simply clear the connecting screen (leaving the info you’ve typed in place) when on the settings pages and refresh when on the main player page. or possibly tell it not to show on settings pages at all? anybody had any other Ideas?

7

Hi all, I’ve found a solution,

in /var/www/js/volumio.api.js add this line @ line 84

$('#loader').hide();

you should end up with this: (without the //<------------(new line added here) bit!)

function backendRequest() {
    $.ajax({
        type : 'GET',
        url : '_player_engine.php?state=' + GUI.MpdState['state'],
        async : true,
        cache : false,
        success : function(data) {
			GUI.MpdState = eval('(' + data + ')');
            renderUI();
            $('#loader').hide(); //<------------(new line added here)
            backendRequest();
        },
        error : function() {
            setTimeout(function() {
                GUI.state = 'disconnected';
                $('#loader').show();
                $('#countdown-display').countdown('pause');
                window.clearInterval(GUI.currentKnob);
                backendRequest();
            }, 5000);
        }
    });
}

it seems to work for me on my Windows machines (the results will show once your cache is cleared/refreshed)

8

Hi Sog Sussex,

thank you for this solution!

Works fine for me on a windows client using firefox as well as the Volumio Web App on my smartphone.
You see me very happy :slight_smile:

Best regards
Stefan

9

It doesn’t work on my Acer-Android phone, using “Chrome beta” browser :frowning: … the webinterface continues to be masked by the “CONNECTING…” overlay frequently.

10

Hello maxvise,

have you already tried the volumio web app for android? (https://play.google.com/store/apps/details?id=com.volumio.moritz.volumiowebapp_release)
For me it works with this solution.

Br
Stefan

11

Thanks Sog Sussex - I’ve rolled in your fix to this commit. Let me know if that seems to solve the problem.

12

I just registered so i can tell you its not working. Well, at least not for me. I got Volumio running on a raspberry with Kiosk Mode. If I add this “hide” Line it does not help and if I use the file from github, the website is broken, without buttons or anything. Browser is Midori. Any other idea? I could also live with a crontab or something which will restart a Service every hour.

13

I think that I have discovered a simple solution quite inadvertently. I found that the webui seemed to be on a a different IP address each time I booted and decided to fix it by changing over from using DHCP to a fixed IP address. The webui is now always on the same IP address and the added benefit is that pages are no longer masked by “CONNECTING…”

Can anybody else confirm?

14

I am always using Static IP and I also experience still experience problems.
Adding the “$(’#loader’).hide();” fix to the js file did work for me. I had to reboot the Raspberry though!!!

15

adding the line worked for me, android phone and tablet thanks!

16

hi ning-yu,

your fix unfortunately does not work on the hourly interruptions and problem on mobile phones when you lock your phone or switch to an different app.

My problem is that I want to have a permanent volumio GUI on a device, but every time after an hour it goes to connecting state, which is very unpleasant, so if anyone else is bothered by this I have a solution.

PROBLEM: every hour the connection on client side switches a port that causes the AJAX call to fail, but the server does not notice it. this might also happen when there is a short network interrupt on client side, that the server will not notice.

more on technical note:
the backendRequest() sends a request and first time receives an answer, than you send another request, but the server does not reply until it has something to send, like start/stop playing, so it can keep silent for hours.
So the problem is following:
after an hour (or some kind of interrupt), the backendRequest() will go into error and startup the loader, you will send another request, but because the server did not notice the connection interrupt, it will not send anything back, so it does not go to success : function(data) and does not clear the loader, which sucks.

The problem is architectural, there is no good fix going with backendRequest() if the server behaves like this.

on the other hand backendRequestSpop() behaves differently, when you send a request, the server always replies even then the data is empty, so this is more suitable as heartbeat mechanism and controlling if the connection was lost.

(I don’t know how it worked before, I tested it only on the latest volumio)
so if you don’t plan to change the server behavior, I would recommend following code which I ended with.

altering /var/www/js/volumio.api.js

[code]function backendRequest() {
$.ajax({
type : ‘GET’,
url : ‘_player_engine.php?state=’ + GUI.MpdState[‘state’],
async : true,
cache : false,
success : function(data) {
GUI.MpdState = data;
renderUI();
$(’#loader’).hide(); //probably no need for it but it can stay
backendRequest();
},
error : function() {
setTimeout(function() {
//kick out the $(’#loader’).show();
backendRequest();
}, 5000);
}
});
}

var myFailCounter = 1;

function backendRequestSpop() {
$.ajax({
type : ‘GET’,
url : ‘_player_engine_spop.php?state=’ + GUI.SpopState[‘state’],
async : true,
cache : false,
success : function(data) {
if (data != ‘’) {
myFailCounter = 1;
GUI.SpopState = data;
$(’#loader’).hide();
renderUI();
backendRequestSpop();
} else {
myFailCounter = 1;
$(’#loader’).hide();
setTimeout(function() {
backendRequestSpop();
}, 5000);
}
},
error : function() {
setTimeout(function() {
if (myFailCounter == 0){
GUI.state = ‘disconnected’;
$(’#loader’).show();
$(’#countdown-display’).countdown(‘pause’);
} else {
myFailCounter = myFailCounter - 1;
}
backendRequestSpop();
}, 5000);
}
});
}[/code]

just move the loader to this function (It is not used on all the pages with the backendRequest() so it might be good t put it there)

the myFailCounter is there just for me because I really don’t want to see the loader, even when it takes more time to detect this way (but the chance for the backendRequestSpop() to be interrupted is really low, so It can be safely removed).

also the GUI.state = ‘disconnected’; is useless because you never set it to anything else! so its probably some old mess

And everything works great