Thanks for everyone’s patience. There is a lot going on at present, but I will try to be concise.
We can see from our database that more than a thousand users upgraded in the first few days, and amongst that we were always going to have a few failures, given that we needed two kernel downloads over the internet to work without a hitch. This is no consolation if you are one of those that struck a problem, and you are our top priority right now, but the failure rate has been very low.
While Mark Cole has been the point person for all of you, three of us are working in the background, getting reports from Mark about what is going wrong for some users, feeding Mark with fixes where they can be simply applied, and/or developing patches for the next push.
The next push will include updated third party apps, upgrades to the myantipodes process, a couple of bug fixes, and a new Squeeze remote control web app. We have a large software development program underway, but the critical first step is getting users onto a common v3.1 starting point.
I think it is worth clarifying a couple of messages that it seems we have not communicated well enough. The first is about the need for patience with the upgrade steps, and the second is about how overnight updates work.
The need for patience.
The upgrade steps include downloading and installing a new kernel for the operating system. A new operating system needs to interrogate all hardware components on the main board and some connected boards, and then configure its device drivers to ensure that everything will run as it is intended. For example, the same kernel is being installed on a DS1 from 2011 and a K50 from 2021 and every motherboard we have used in the decade between those. The differences in drivers required have to be determined and configured for each music server. This happens the first time you boot into the new kernel, and that process has a set time limit of a couple of minutes. The time limit is necessary because, in our experience, users often panic at a long boot and pull the plug, potentially causing a more serious problem.
So you might not get a completed configuration at the first boot after Step 3/3. So another reboot or more may be needed to get everything configured properly, depending on the quality of your internet connection. A number of factors will affect how long it takes to get the job done. I think we had a dozen or so reported upgrade failures that resolved themselves after as many as four reboots. I have only touched on one of the reasons why this is not a simple ‘press a button and it is done’ kind of process, but it might help you to understand that the system needs to be given time to sort itself out, and this is normal.
Overnight Updates.
Prior to v3.0, we did not have a way to push updates out automatically. Customers had to initiate the updates, which led to our many customers being on a range of different generations of operating system and applications. This makes it very difficult to provide support and ongoing software upgrades.
Nor were we in a position to do anything about that without getting the update code onto your devices. We did manage to get the code out to a few devices with an update in 2019, but not many customers took up that offer. All v.3 devices have the update code. So this v3.1 upgrade process is flushing out who still needs the update code and Mark Cole is progressively getting it out there.
In some cases poorly setup IPv6 configurations on DNS servers managed by your ISPs are also getting in the way of the update code being able to work. Fortunately this is impacting only a small percentage of users, but we are giving them top priority at the moment. Changing your DNS server addresses and/or disabling IPv6 on your router is typically going to be needed to fix these ones, as the problem has nothing to do with our code. Sadly these problems are not uncommon when a new internet standard is rolled out - if you can browse the internet and send emails, then that is sometimes all your ISP tests for when implementing on their DNS servers. It eventually works itself out and right now IPv6 implementations are creating problems for a wide range of software that requires sophisticated communications. In our case, the fault does not lie with our software, it lies with a small number of ISPs.
Once we have actions underway for all customers that need a fix, we will shift our focus to the ongoing overnight updates, to push out new versions of apps, bug fixes, enhancements, etc. We do not want to interrupt your listening pleasure, so these updates are timed for around 3:30am. To receive the update your device needs to be booted up and left on overnight.
If you like, just do this once a week or once a month, but if you want the optimum sound quality from your Antipodes music server you should typically be leaving it always on anyway. At 3.30am, your device will look at the Antipodes repository and check that it is up to date. If it sees that there are later versions of any software components it will download and install them. Sometimes an internet issue will mean your device is timed out from the repository and you will get the update on another night.
We only add new software components to the repository when they have been fully tested on our operating system and with our integration code. We do not put a new app in the repository just because the third-party software developer has a newer version, because that risks your server receiving a version that will not work on your device. The only exception to this is Roon, where our partnership with Roon means there are processes in place to ensure their new versions will work before they are released.
Sorry for the long post, just hoping it clarifies a few things.
). So perhaps an early push can just rectify that? If it would be useful I can supply details of which different versions of the apps have been sent out with 3.1 but you probably know anyway.
