OK. Sent feedback to you twice at around 09:17am US Eastern (13:17 UTC). The first time,I got an error message:
[root@ropieee-usbsig ~]# /opt/RoPieee/sbin/send-feedback
gathering information in /tmp/feedback_bNCR6 …
ls: cannot access ‘/dev/input/by-id’: No such file or directory
Warning: The unit file, source configuration file or drop-ins of avahi-daemon.service changed on disk. Run ‘systemctl daemon-reload’ to reload units.
compressing information …
sending it …
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 132k 0 0 100 132k 0 109k 0:00:01 0:00:01 --:–:-- 109k
So, I ran the systemctl daemon-reload command, and then re-ran the send-feedback command:
[root@ropieee-usbsig ~]# systemctl daemon-reload
[root@ropieee-usbsig ~]# /opt/RoPieee/sbin/send-feedback
gathering information in /tmp/feedback_0UaaJ …
ls: cannot access ‘/dev/input/by-id’: No such file or directory
compressing information …
sending it …
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 132k 0 0 100 132k 0 106k 0:00:01 0:00:01 --:–:-- 106k
I hope this is helpful. Thanks for your time and attention to this, and please let me know if you’d like me to try anything else.
Yeah you can ignore the errors. As this is an ‘under da hood’ script it does not test nicely for existence of files.
So to be clear:
This is a log from a session where you provided feedback (from the command-line) at the point the web interface is not reachable any more right? Is it correct that you restarted it the interface in this session once again manually?
And what does it exactly do when it hangs up? If you hit an F5 in the browser it keeps spinning?
What do you use for address? hostname/IP address or a the .local ?
Yes, this log was sent from the command line when the web interface was hanging.
It is correct that right before this, I had restarted the interface manually from the command line.
I connect by entering the IP address of the box.
When it hangs, I observe the following behavior:
The browser connects to the RoPieee web server, but fails to load the page (I’m primarily using Chrome and Microsoft Edge (Chromium) on a Mac)–it keeps “spinning.” Force-reloading the page does nothing. Safari and Firefox are the same.
The interesting thing is when I issue the command to restart the web service, the session immediately disconnects (Chrome says: “The site can’t be reached”). After 10-15 seconds, the browser then successfully connects, and I can usually then operate the web interface normally. After some time passes, or if I kill the browser and then attempt to reconnect again later, it will die again.
Again, this is happening on BOTH of my RoPieee units–an Allo USB Sig and a RPi 3B+ touchscreen unit. For now, I can use the restart trick as a workaround (I don’t often need to change things in the setup), but I wanted to let you know about this behavior. If I am the only one experiencing this, then perhaps something on my network is whack, but I can’t imagine what that could be. I have lots of IoT crap, and nothing else is acting up.
Thanks again for your help on this, and let me know if there is anything else I can try for you.
I really don’t get this. The logs do not even show the incoming request.
And yes, afaik you’re the only seeing this behaviour (which in itself does not automatically rule out there could be an issue in the software).
Can you switch to the beta channel? Not that it will change much, but at least you then have the latest stuff.
I’ll post you some instructions later tonight on how to set the web interface in a more verbose mode so we can get more logging.
OK, will do. I’ll await your instructions on enabling verbose mode in the logging.
UPDATE: switched to beta, currently on 2.541. No improvement. By the way, I could run a packet sniffer (Wireshark) and send the traffic log if that would be helpful.
Tonight I set up a small test network with some old hardware and connected the Allo. The web interface worked flawlessly, so at this point it appears that my RoPieee devices are not playing nicely with my Ubiquiti Unifi network. I haven’t figured it out yet, but it is interesting that this problem shows up on 2 different RoPieee devices, running on different hardware, one connected by ethernet and the other by wifi. I’ve run a packet trace with Wireshark, but I’m not expert at interpreting results. It does appear that something goes wrong and packets are either dropped or unacknowledged. I don’t see any transmission errors in my switch log, however.
I have other RPi based devices running web interfaces (Allo DietPi GUI, Pi-hole) and these work fine, so this does seem to be RoPieee-specific, but I’ve demonstrated that at least one of my RoPieee boxes runs just fine on a different switch. I’ve tried changing ports on the Unifi switch, but this was no help.
Anyway, it looks like this one is due to some bizarre interaction with my network, so I’m sorry to have wasted your time. Thanks again for all your help.
Any sort of ad filtering / domain blackholes on your network?
I think my recent issue is due to my Pi-hole blocking some of Ropieee’s external dependencies, which cause this same web UI lock-up behavior. Although in my case it’s only happening when configuring WIFI for the first time on a new Pi, my existing Pi 3b with RopieeeXL has remained flawless.
Hi, no strange things in my network.
Everything is back to normal on my 3 RPI’s. On one of them the installation failed. I hope Harry can help you. Cheers John.
Thanks, Laver! I do use a Pi-hole on my network, but this is not the issue. There are no blocked requests in the PH log, and I did try running with the PH bypassed with no effect.
I’m convinced that this is a problem between RoPieee in particular, and my network (switch). I have other SBC and network devices running web GUIs, and they all work fine. There appears to be something strange in RoPieee’s implementation, as I now observe this problem on three separate units (I’ve added one built on a RPi 4b). I’ve swapped ports on the switch, cables, etc. and get no relief. By the way, everything is plugged into the same switch, a Ubiquiti Unifi US-24-250W) so this is not related to any routing or firewall issues I think.
I upgraded to 2.535 (and also tried 2.535 beta), however whenever I browse to http://music.local/ropieeexl in the WebGUI , I get “internal server error”. Any ideas ?
I’ve run the feedback command to push some logs to you…
Yes, I can get into the web interface fine. However, when clicking on the Ropieexl tab, I get that error. ‘music’ is the name I’ve given ropiee on the network
I am currently using version 2.450 stable, and get the message “There is an update available for your device”. After starting the update (12 seconds) and the reboot following after that (40 seconds), I am still at the same version. Tried updating several times, but without luck.
Can you send me feedback that has the update action covered?
So first hit the update button in the UI and when it finished do not reboot but send me feedback.
