I suggested so too.
Sorry for hijacking the thread
I would open a bug report after trying a last time with a new, high quality sdhc-card.
ASIair was more than double the price and didn't support AZ mounts. This is why i decided to use Stellarmate, and it worked after optimizing some things and a libcamera bug, which was solved within a couple of days after updating.
In AA all the optimization is done already, but you have to pay the price, and AFAIK you can't just expand the system like you can in an open linux system like Astroberry or Stellarmate, browsing the www while capturing frames....
So, as my setup mostly worked, i switched to en EQ mount and decided to keep Stellarmate. I wouldn't call it "garbage" at all.
Yeah, who needs trouble anyway?
But for now, let's get back to trying to solve problems. Did you manage to execute "sudo apt-get ..."?
Waiting for results (select all/copy using right mouse button) or select using a mouse and hit the enter key (can't remember exactly).
I'm not a stellarmate developer, but i know this way of upgrading debian based distributions since many years now. It just works best.
For myself, i would assume that the dialog box (application) was made for the desktop user's experience.
However, it is not very verbose about what's going on, so best use the "old way" to check for more output.
And yes, bugs are daily business in software development, it's just that the projects became way bigger and more complicated to maintain.
I wouldn't assume a room filling bug-hunting and functional testing team is at work for $50 of cost for a lifetime license.
It's bad when we run into bugs, even less severe. Sometimes there is an instant workaround available or made obvious.
I could not imagine doing Astrophotography without stellarmate again, but the Asiair stuff has features that don't work as well as with stellarmate, and for sure, it has and will have bugs too. Code is still written by humans...
Also try to look for existing forum threads covering stellarmate OS upgrade issues, might help.
Paul, you gotta open a terminal window on the stellarmate OS desktop and type in the following lines to get more information, each line followed by a return (CR)
open terminal app and enter:
As i found out, there's one more thing to add, since i was experiencing dropouts some time after the OS booted and worked flawlessly.
I knew where to look and i found out the medtic (priority) of the default route(s) have been flipped again, so no backroute and no connection possible via home LAN IP.
Turned out that the USB-WiFi dongle which provides the stellarmate WiFi suffered from power issues on the onboard USB3 connector. So next time the power drops, the ifdown/ifup processes are run and remove/add the network's default route, which is added with a higher priority again.
After running the USB WiFi dongle off the powered USB 3 hub, the wlan0 and wlan1 interfaces became stable and the routing priority fluctuations were gone.
If i find a way to keep the system from adding a default route for a private network (stellarmate) on every ifup, i'll post it here, but this article should give you an idea about the core problem with dhcpd:
A recommendable read if you use more than one dynamic network interface with Raspbian-based distributions.
So, i wanted to have wlan0 (internal) connected to my home wifi, as well as wlan1 (usb wifi dongle) to provide the stellarmate hotspot.
Reasons: i wanted better throughput and signal on the stellarmate wlan to the android app, while still staying connected to the internet via internal wifi adapter at home.
I configured both wifi networks via the systems network config application, but i could not access the internet, because every packet got sent out through wlan1 (stellarmate) instead of wlan0 (home wifi). The short background story: i was a linux sysadmin, 10 years ago.
Now some admin talk:
What i quickly found out (via "route -n")is that there were actually two default gateways (0.0.0.0) set, one for each wifi adapter/network, but the wlan1 entry had a lower Metric value (higher routing priority).
Why? Because on the first tab of a network's config, there is "priority 0" set by default. The assignment order, however, was wlan1 before wlan0, i suggest because it got configured first, so it got a higher priority resulting in a lower routing Metric value.
Make sure the priority value in the network config dialog (first tab "general" iirc) is set to 0 for the interface you want to route all undirected packets through (to the internet or local LAN), while setting a HIGHER priority value (i finally set it to 10) for the stellarmate network, if bound to a different wifi transceiver.
Hmm, after upgrading to 2.5.7 i also ran into troubles using Stellarmate app (on a Samsung S6 Tablet).
I am using a dual-IP setup, one is on the local WiFi, the other one is the Stellarmate WifFi network, where the Raspi acts as a hotspot for the private 10.250.250.0//24 subnet.
I was away from the home network, so the 192.168.0.x network could not be reached, but i wasn't able to create a new device config for 10.250.250.1 (SM hotspot) while being in the same subnet with both devices (Phone and Raspi), because the app got stuck in the optical train setup dialogue. At home, the 192.168.0.x network/node was available again in the app, but i could not connect because of the stuck dialogue. Then i deleted all app data and cleared app cache, so i was able to create 10.250.250.1 config in the app again, but it acted awkward on connect. Nothing worked, i had to shut down the Rasapi using ssh.
I am quite confident that there is a bug which will get resolved with the successful addressing of Christian T's bug and issuing a fix.
If there's a workaround, please post here, in the meantime i'm using Stellarmate OS directly via VNC, which works well as soon as you got the hang of the slightly different EKOS dialogues.