[SOLVED] Image install - web interface hangs all the time

[olisturm]

Hi,

I have been running volumio for a long time and I decided yesterday to try Moode. So I downloaded the current image and used a new SD card to run it on the same Pi (that's a 2B) that ran volumio previously. The image boots and I can log in (using a local HDMI screen and keyboard), and I can bring up the web interface.

That's where things stop working though. I was trying to look around the configuration pages, settings etc, and I found that the interface hung itself up in strange ways whenever I did something. For instance, I thought I'd quickly activate bluetooth, but the click on the Set button resulted in an endless "waiting for..." message in the browser. This morning I clicked the button to check for a software update, but the click on the Install button has hung up the browser again now. Several other functions I have tried (manage audio sources, for example) resulted in the same behavior. In this state, the web interface still allows me to bring up the menu and even the "Configure" popup, but I can't navigate into the individual settings page anymore. In /var/log/nginx/access.log I can see that each request results in a 499 error code at this point. The only way out is to restart the system via the command line (the menu item doesn't do anything either), then I can once more do one thing - more or less - before the system goes back into the non-responsive state.

I have checked log files and I can't see any trouble there, or in the output of moodelog. The latter did not react in any way when I ran the update install just now.

That's as much as I know at this point - obviously less than impressed by Moode so far! Are there other places where I can look for useful technical information on what might be happening? I suspect a hung process or similar... but what could it be? Any ideas?

Thanks
Oli

[olisturm]

Hi,

To summarize - egg on my face - turns out Bluetooth only works if you plug in the dongle, not if it's sitting elsewhere on the desk.

However - if Moode hadn't claimed (as the last line of the moodelog output) "Bluetooth controller started", I would have probably found out about the actual problem much earlier. There really doesn't appear to be any indication, before or after activating Bluetooth, that it doesn't work at all because the hardware isn't there.

As far as I can see, things are working correctly now, with the Bluetooth dongle properly inserted. Thanks for reading and sorry about the hassle! 

Oli

[TheOldPresbyope]

Hi,

To summarize - egg on my face - turns out Bluetooth only works if you plug in the dongle, not if it's sitting elsewhere on the desk.

However - if Moode hadn't claimed (as the last line of the moodelog output) "Bluetooth controller started", I would have probably found out about the actual problem much earlier. There really doesn't appear to be any indication, before or after activating Bluetooth, that it doesn't work at all because the hardware isn't there.

As far as I can see, things are working correctly now, with the Bluetooth dongle properly inserted. Thanks for reading and sorry about the hassle! 

Oli

Curious. I thought there's a check somewhere in the code that complains if the BT subsystem doesn't return a BT MAC address (e.g., can't find a BT transceiver). Maybe I'm mis-remembering. Tim? 

Regards,
Kent

[Tim Curtis]

Hi Kent,

I don't know if its possible to determine whether a BT adapter is present ?? For example the command below returns blank on  Pi-2B (no BT adapter) and on a Pi-3B (BT adapter present but BT not turned on in Audio config)

Code:

hcitool dev | grep chi

Other possible commands

Code:

lsmod | grep btusb
lsusb | grep -i Bluetooth

If its possible to detect then I can implement the check and then enable/disable the controls for the BT renderer on Audio config :-)

-Tim

[TheOldPresbyope]

@Tim Curtis 

Hi, Tim.

I had to go back and look at playerlib.php for the line

Code:

// start bluetooth
function startBt() {
       sysCmd('systemctl start hciuart');
       sysCmd('systemctl start bluetooth');
       sysCmd('systemctl start bluealsa');

       // we should have a MAC address
       $result = sysCmd('ls /var/lib/bluetooth');
       if ($result[0] == '') {
               workerLog('worker: Bluetooth error, no MAC address');
       }
       // initialize controller
       else {
               $result = sysCmd('/var/www/command/bt.sh -i');
               workerLog('worker: Bluetooth controller initialized');
       }
}

I came across this when we were fiddling with BT a while back but didn't stop to think about it. 

I don't have an RPi2B online at the moment so I can't test the no-adapter condition. On an RPi3B+ that is running, I get

Code:

pi@moode44h1:~ $ sudo ls -l /var/lib/bluetooth
total 4
drwx------ 5 root root 4096 Jan  2 13:28 B8:27:EB:83:AA:7A

Regards,
Kent

[Tim Curtis]

That code doesn't detect the presense of the adapter but rather it assumes the adapter is present and then starts the Bluetooth services.

Ideally we would want to know whether an adapter exists before deciding whether to start Bluetooth. For example with a BT dongle inserted, the function startBt() will most likely succeed and we will have a MAC address established in /var/lib/bluetooth. If the adapter is subsequently removed the MAC address will remain and thus it can't be used to reliably detect the presense of the adapter.

I think that simply starting hciuart would be a reliable test but it takes almost 2 minutes to timeout when no adapter :-0 This makes it unsuitable.

Code:

Jan 08 13:56:07 rp4 polkitd(authority=local)[608]: Registered Authentication Agent for unix-process:6454:1004991 (system bus name :1.10 [/usr/bin/pkttyagent --notify-fd 5 --fallback], object path /org
Jan 08 13:56:16 rp4 polkitd(authority=local)[608]: Unregistered Authentication Agent for unix-process:6454:1004991 (system bus name :1.10, object path /org/freedesktop/PolicyKit1/AuthenticationAgent,
Jan 08 13:56:16 rp4 polkitd(authority=local)[608]: Operator of unix-process:6454:1004991 FAILED to authenticate to gain authorization for action org.freedesktop.systemd1.manage-units for system-bus-na
Jan 08 13:56:19 rp4 sudo[6467]:       pi : TTY=pts/0 ; PWD=/home/pi ; USER=root ; COMMAND=/bin/systemctl start hciuart
Jan 08 13:56:19 rp4 sudo[6467]: pam_unix(sudo:session): session opened for user root by pi(uid=0)
Jan 08 13:57:49 rp4 systemd[1]: dev-serial1.device: Job dev-serial1.device/start timed out.
Jan 08 13:57:49 rp4 systemd[1]: Timed out waiting for device dev-serial1.device.

-Tim

[olisturm]

Just to clarify:

> worker: Bluetooth controller initialized

Now that things work correctly, I know that this is the line that does NOT appear when the Bluetooth dongle isn't plugged in. There are many other lines that never come up in the log in that scenario - but since the web frontend works (well, sort of - as described) and I can even play radio stations, there is no obvious indication that the system has really not completed startup correctly.