I have been getting this message all day today - this setup was working fine till a cpl of days ago. However, all day today, I cant do anything on the webclient. Looking through previous posts I dont see any real solutions apart from either reinstalling or waiting for the issue to just go away. Any ideas for things that I can look at to debug this?
The mopidy service is running in the background for sure.
Looking through firefox debugger - I see this
Firefox can’t establish a connection to the server at ws://<musicbox’s ip address>:6680/mopidy/ws.
Apparently if I stop running mopidy as a service, and run it via the terminal then there are NO issues. So something going on in the configuration of the service I assume?
If I remember correctly, the config file used in both cases (as service and user) is the same one. So I’d have thought any configuration issues would be present in both cases. Do you see any errors from the service in /var/log/mopidy/mopidy.log? Does the service work if you restart it (service mopidy restart) manually? Did you try to upgrade or install any new mopidy extensions recently?
I tried the restart and still get the same error. Looking through the config, it looks like pandora and google music addons are disabled automatically somehow. I had done a apt-get upgrade over the weekend - and remember getting a message about mopidy updates and a new mopidy config file that was installed. Could that be the issue?
EDIT - The config looks pretty similar to what I had earlier or atleast what I remember from earlier.
Yes, that’s issue. Musicbox 0.6 does not support upgrades.
Oh. So whats my options now? Reformat the SD card and start again?
You can do that or you can attempt to follow http://docs.pimusicbox.com/en/develop/upgrading/ and fix some of the things that will have broken
Looking through - I realized I actually installed mopidy directly and added in the extensions as needed. So it wasnt really a pimusic install from the start. If thats the case, would the issues with upgrading still have the same impact?
And I realize this is more pimusicbox focussed, but how do I fix this issue given its not really pimusicbox but mopidy and something to do with upgrades.
If this is a regular Mopidy install then upgrading/updating is completely fine. It is only pimusicbox systems where this will mess things up. My comment about user and service configs being the same only applies to pimusicbox. Sounds like I should move this topic out of the pimusicbox section.
Please post the output of
sudo mopidyctl deps and
sudo mopidyctl config. Also provide your log file (/var/log/mopidy/mopidy.log) showing the latest startup. Please use a gist or http://dpaste.com/ if you can, particularly for the log file.
Is it possible the
musicbox_webclient section has something set for
@fallenicarus When you do an
apt-get upgrade on Mopidy it warns you that it wants to overwrite your configuration file. You have to select that you don’t want it to overwrite it.
It sounds like you let it overwrite your config during the upgrade.
Can I check that you tried a full force refresh in your browser? Usually it’s shift+f5 or something like that. The browser cache can do all kinds of strange things following upgrades.
@jjok Yeah I think thats what happened. I have gone through and uninstalled all mopidy components, and programs. I also found used the purge option to clean out data/config files for mopidy. I am planning on re-installing over the weekend to see if that fixes the issue.
@kingosticks I did try that. What interesting is, I cannot access the mopidy player page on any other browser, or if I even try just the /index.html page. But somehow, /index.html#home etc show the page but with the trying to connect to Pi-Musicplayer message.
I checked ports open using netstat -lnp and dont see the port open for the webplayer. So not sure what is going on there. I also dont see a folder/file for the webclient package in my python folder. I assume I got it all when I uninstalled everything.
@fallenicarus Musicbox Webclient uses the HTML application cache, which makes the files still load even when the client or server are offline. I expect that is what you’re seeing. It makes it pretty confusing when you’re trying to work out why it doesn’t work.
@kingosticks I was going to suggest that it would be better to remove the app cache. Actually, it looks like that standard has now been deprecated anyway.
@fallenicarus Now we know this isn’t pimusicbox I think it would be best if you just provide the output of
sudo mopidyctl config and the log at /var/log/mopidy/mopidy.log. It really just sounds like the web frontend is not running. If you have now purged everything then OK, re-installation (read: reconfiguration) will probably fix everything.
@jjok I had been intending to mention this to @jcass77 since he implemented that stuff. To be honest, I originally thought it was only there to properly version the assets since we’ve no requirement for offline support. Maybe i got the wrong idea, or maybe the versioning is just a side-effect of using it that we are trying to benefit from.
It may be deprecated but, despite what Mozilla claim, it’'ll remain part of the real standard for some time (years) so no need to worry yet.
Yeah the appcache approach is pretty much deprecated.
I think it still works well for the Mopidy Musicbox webclient (MMW) however. Although I haven’t tested this, MMW should in theory be much quicker to load on mobile devices (where the extension acts as a hybrid app rather than just loading a regular web page).
The negatives are:
appcache is deprecated, as @kingosticks said.
If you’ve saved MMW as an app on the home screen of your iOS device, then you’ll need to launch and close the app twice for changes to be detected.
If we forget to update the appcache manifest, then mobile devices will NEVER bother checking for updated resource files on the server. This should not be a problem if we are careful when making new official releases (e.g. by just updating the time stamp or version number at the top of the manifest).
The various browser platforms seem to have different rules as to how they invalidate the cache which can be bothersome between MMW upgrades. Manually clearing the cache has always worked for me though.
MMW will load even if Mopidy cannot be reached, as long as it has been cached on that device before. This can be confusing as other web extensions load as regular web pages. But this is also why we have the ‘trying to connect…’ popup.
On the bright side, rolling back the appcache is as easy as deleting the manifest file and removing one or two HTML meta tags. So we can decide to change tack on this whenever we want to.
I was getting 102 (CONNECTION_ERR_REFUSED or something similar) on my roll your own Mopidy + MusicBox. It turned out that when I did a sudo apt-get update && sudo apt-get upgrade I told it to overwrite mopidy.conf. I did it to two different Pi’s just to be sure that’s what it was. If prompted to overwrite, don’t. The default is to not. Don’t second guess it.
It took me quite a few hours to get that straightened out, but I enhanced the system in the process, so it wasn’t totally time wasted.
@kraigompls69 Glad you got the issue sorted out.
Thank you all for your help. I plan on fixing my install over the weekend - all of this discussion has been really helpful
Hopefully I dont have any issues installing (I was able to find solutions last time around as I did this, so hoping for more of the same this time around too).