Max2Play Home › Forums › Max2Play on Raspberry PI › Big problems from a small bug in v2.31
- This topic has 9 replies, 4 voices, and was last updated 8 years, 5 months ago by
flysurfer Moderator.
-
Posted in: Max2Play on Raspberry PI
-
30. Juni 2016 at 15:23 #20965
Hi,
TL;DR: Hostname in /etc/hosts in v2.31 is wrong causing a very unstable and slow/sluggish system because all „sudo“ calls have this error „sudo: unable to resolve host (max2play)“. The 127.0.0.1 entry in /etc/hosts has „raspberry“ as the name which doesn’t match with /etc/hostname (= max2play)
Quick fix for end-users: change „raspberry“ in /etc/hosts to „max2play“
(Or, for those who aren’t familiar with linux/ssh/cmdline etc, change the player name to „raspberry“ in the „Setting/Reboot“ page of the webinterface, that also changes the url to access it)Long, probably way to detailed, story:
After seeing some videos and reading about max2play I decided to try it and at some point even bought the 5yr licence (if only to support the devs). But after my first install on an RPi3 with the official 7″ touchscreen I found it to be slow, hard to configure and giving weird unexpected results, not at all what I expected as it’s advertised as quick and easy (and reading the feedback it is for most users)Things I did and encountered:
** I couldn’t reach it with the http://max2play/ hostname but that’s fine. It’s likely more to blame on my providers cablemodem and/or my network set-up. Such a feature just won’t work everywhere and it’s always reachable on the ip, no problems there.
** After getting the Wifi up and running and testing the squeezeplayer from LMS I thought the slowness of the webpage could be related to some settings or that the image wasn’t really optimised for the RPi 3 yet. That’s when I decided to buy a licence and get the Settings plugin which actually claims to detect an RPi2 (possible small harmless bug).
** I ticked the Autostart X environment and after rebooting noticed it could take up to a minute before the desktop appeared after boot completion (saw the login prompt for ~1m)
Not what I’m used to on Raspbian.
** I figured maybe the touchscreen plugin is needed so I installed that and configured it but apart from hiding the mouse I didn’t notice much difference.
** I installed the Jivelite plugin which refused to start and the „click here for details“ revealed nothing. Ticked Auto start Jive, rebooted, still just a delayed empty desktop.
** Found some things on the forum on how to start it from the cmd line so I tried that a few times but it either started shortly and then disappeared, sometimes the desktop disappeared completely, sometimes it got totally stuck.
** And then all of a sudden when I left it sitting for a while after yet another reboot, Jivelite started and I could actually configure it to my liking. It even survived a few reboots so I was happy and called it a day, still thinking it’s some new quirks related to the RPi3.
** Next day, not working anymore, best thing I got was an empty desktop.
** Decided to test the bluetooth plugin as that looked interesting, worked pretty much immediately after installing and all of a sudden I had another stable occurrence of Jivelite, which I lost again. Frustrating…
** At this point I decided to start over with a fresh image, carefully installing things one by one, thoroughly test it before moving on to the next plugin with many iterations and combinations of autostarting on/off, deleting all display settings etc, etc trying lots of suggestions I found on the forums but nothing worked stable, and the interface was still slow.
** This is when I decided to start looking under the hood and started investigating the scripts. I started to suspect the „detect if X is running“ logic was broken or clashing when the next plugin tried the same detection. I noticed multiple „startx“ processes among other things and wrote my own small test versions using only relevant bits from the max2play scripts based on my situation but still, never really able to get a smooth stable system.
** Sometimes I noticed the „unable to resolve host (max2play)“ error message but figured it was related to my very first point and because I’m mostly used to switching to the root user rather then using sudo I never connected the error message with sudo. Once I did, it was easy to solve and after fixing /etc/hosts I finally got the max2play experience I expected.So, lots of lessons learned which also led me to writing a very basic Jivelite plugin for controlling the RPi touchscreen brightness (happy to share it once I polished it a bit more).
It also made me try a bunch of possible alternative methods on how to launch certain processes/plugins (especially when there’s dependencies) which might be interesting to investigate further. I haven’t tested yet if the sudo error just caused a delay on the command or if it failed completely. If it’s just delaying I can imagine other timing issues or holdups causing this kind of instability, maybe worth discussing later. For now I’m going to enjoy my current stable Max2Play system.Cheers!
1. Juli 2016 at 21:04 #21067Thank you, OneArmedBandit!
Your post was very helpful. Because of the sluggishness of the Webinterface I would’ve almost abandoned M2P.Cheers,
Michael4. Juli 2016 at 14:20 #21130Thanks a lot for finding that bug and your detailed report! We created a fix that is applied with any update (beta update and 2.32 update) that solves that issue.
Cheers,
Stefan4. Juli 2016 at 15:37 #21140@OneArmedBandit:
Would you like to participate in further testing and/or Max2Play development? Your approach to solve the problem and your testing skills could help us a lot for new Addons / Features / Hardware!We are currently building a developer area for Max2Play. Main goal is to make it easier for developers to create custom Max2Play Addons and share them with the community.
All the best
Stefan6. Juli 2016 at 4:04 #21232I am using M2P 2.32 and I’ve changed the server name to ‚raspberry,‘ but I am seeing similar errors. For example, when I try to create a mount point:
sudo: unable to resolve host raspberry Timed out Password for root@//192.168.0.22/: Retrying with upper case share name mount error(6):
6. Juli 2016 at 9:12 #21234Hi Martin,
It looks like there’s 2 different issues here and I don’t think they’re related:
sudo: unable to resolve host raspberry Timed out
It seems the bug is only fixed partially in v2.32 and you „triggered“ it again by renaming your player to „raspberry“.
I bet that since changing the name the webinterface became slow on certain actions. Naming it back to max2play should resolve that part of your issue until the bug is 100% fixed.The core issue is that when the name in /etc/hostname doesn’t match with an entry in /etc/hosts you get the slowness caused by the „sudo: unable to resolve host <your_player_name>“ error. In v2.31 /etc/hostname contained „max2play“ while /etc/hosts had „raspberry“. They fixed it in v2.32 by changing the /etc/hostname entry to „max2play“ but it looks like that file doesn’t get updated when you rename your player.
Password for root@//192.168.0.22/: Retrying with upper case share name mount error(6)
I’m still relatively new to max2play and haven’t tried any mounting yet as I have no need for it yet.
I suggest you give more info on what system you’re trying to mount from like the Operating System, what protocol and if you’re able to mount it from other (non max2play) systems.
Maybe start a new topic on it so you get a broader audience and attract people with more experience on mounting issues.Cheers,
OneArmedBandit7. Juli 2016 at 15:27 #21287@flysurfer:
Thanks for the compliments and I’d be interested in participating more. Let me know what the plans are and we’ll see what happens. You can also email me directly on the address I’m registered with.Now on the hosts/hostname bug:
It looks like the patch isn’t working yet. Martin reported it here and after trying it myself I had a look at the code.
My PHP-foo is quite rusty as I’m a Perl guy myself but here’s what I found:The part that is generating the „sed“ command looks like this:
'sed -i \'s/'.$this->getHostname($this->view->playername).' '.$this->view->playername.'/'.$this->getHostname($name).' '.$name.'/\' /etc/hosts'Which resolves into:
sed -i 's/max2play max2play/livingroom livingroom/' /etc/hosts… and that doesn’t do much on an /etc/hosts file that looks like this on a default install:
pi@max2play:~ $ cat /etc/hosts 127.0.0.1 localhost ::1 localhost ip6-localhost ip6-loopback ff02::1 ip6-allnodes ff02::2 ip6-allrouters 127.0.1.1 max2playI think I understand where the need for the addition of getHostname comes from but my guess is that it was written in a dev environment where /etc/hosts may have looked like this:
127.0.0.1 localhost max2play ::1 localhost ip6-localhost ip6-loopback ff02::1 ip6-allnodes ff02::2 ip6-allroutersHope this helps.
Cheers,
OneArmedBandit9. Juli 2016 at 18:26 #21401I can confirm this has been properly fixed now in v2.33.
Cheers,
OneArmedBandit12. Juli 2016 at 10:39 #21447Thanks to OneArmedBandit this bug is solved now 🙂 I changed exactly the code you posted.
I’ll let you know when we have new plugins for testing and send you the forum links for discussions.
-
You must be logged in to reply to this topic.