Hi Everybody,
I just edited the original post at the top of this thread with the link for a new bugfix version 3.1.12. See the changelog in that post for the list of fixes included. If no new major issues are discovered, this version will go out over the wifi early next week.
We’re already well underway building the lock tracks feature and hope to have that out soon 
I’m having a bug that wasn’t happening before.
Accidentally, I saved the song on aeros internal memory instead of the SD card (as I usually do), after 2 second the unit crashed, it turned off and got stucked on the Aeros welcome screen.
I tried to do the same several times and It happens every time I try to save the song on the internal memory, it doesn’t happen using the SD card.
Is that with 3.1.12?
Was the song saved on the SD card and then you changed it to internal? What percentage of memory did the stopped screen say was used when you saved the song
Yes, it was with 3.1.12.
it never happened with previous versions.
No, the song wasn’t saved before, it was the first attemp.
The internal memory percentage was 1% used because i just saved all the song into my SD card a couple of days ago.
Just had the same thing happen with firmware 3.1.12 saving to memory crashed the software. On rebooting song had been saved to memory. Have now started to use SD card only. Might have to roll back firmware. Hope they can find the problem
@sharifkerbage, cool that you spotted this one…
It would definitely deserve a dedicated bug-following topic.
@sharifkerbage @Johnyhorse thank you for reporting this critical bug. We’re trying to reproduce it but no luck yet. Do you remember how much of the song memory %, as displayed in the stopped screen was used (not the internal storage that’s displayed in the song list screen)?
Also what settings were you guys using? freeform/quantized (what time signature), sync length settings? change part/stop song setting?
Did you have an SD card inserted when the crash happened? If yes, please post the crash log file that was generated on it, or send it to me as a private message
Not exactly, but around 5% I think (there were 1 part with 3 tracks and a second part with just one track)
It was Freeform, Sync Lenght and Start, and change part/stop EOL
Yes. I didn’t check the crash log file, I’ll send it to you
I reproduced it 3 times with the same results.
Ok it seems we have fixed this bug. I am removing version 3.1.12. We expect to have a newer version up next week.
I have also been experiencing system lockups when saving songs to memory. I end up having to power off the unit.
This has been fixed in current tested version, please regress your version to 3.1.10 for now and the next beta/release should solve your issue.
I just edited the original post at the top of this thread with the link for a new bugfix version 3.1.18. See the changelog in that post for the list of fixes included.
If no critical bugs are discovered in the next few days, it will go out as an official version over the wifi.
Next firmware version should include locked tracks.
Any updates on track panning and reverse?
Hey there,
They are definitely on our mind but are not likely updates for some time, we have a few more things to tackle past the lock tracks release coming after the next 3.1.x release.
Stuck at 1.18% downloading for a while with no visible way to cancel/restart the process. ;-(
I can leave and come back to the updates page and it just says Downloading without any progress info. If I press on the non-button looking" Downloading" button, it prompts me yes/no but comes back to the same uninformative screen.
I know all the ways to improve the wifi or sideload. This is more a note about possible improvements to the highly touted and seldom used wifi download feature.
Realize that for many, this update will be part of their first use experience … which needs to be a wow (and not a bummer).
Update: Restarted and performed upgrade again. It moved quickly to 1.2% and is now stuck there. I suspect this a problem in retries in the SW and/or issues with your (ftp) server? Clearly the wifi is working; perhaps not perfectly, but it a fallacy that networks are without errors.
Good News: Restarted wifi update one more time and it was making good progress when I left. Think the download was successful this time.
Bad News: I came back and it was displaying the splash screen … and it’s still doing that many minutes laters. This does not have the “please wait” message that I’ve see after other updates.
I’ll wait for a while, but it might be bricked. Hoping you added the “reset to factory” capability?
[Update: All good now after updating from SDCard. Waited longer and no change. Power cycled the unit and it came up (phew) reported the older firmware. Tried wifi update but it stopped around 1%. Clearly lots of issue with that process. FYI I was on the prior version that was removed from this thread. Copied the .bin fil eto the sdcard and it detected that upon insert (nice!) and is now finishing up the update. Took forever to move past 99% though (please fix that).]
Hello @Quad,
Since I purchased the Aeros, apart from the very few first times I have been upgrading using the SD card (despite the lack of hash provided along the firmware, which is both unbelievable and utterly stupid, and I really cannot understand why @DavidPackouz is so reluctant to actually enforce this, whereas he personally acknowledged that it had to be put in place… multiple times… and considering the fact the cost is close to nothing).
Now talking about Wifi and the Aeros, what I noticed in the very beginning is that the Wifi chip in the Aeros is pretty bad… The update process stopping in the middle of nothing happened to me in the beginning until I realized I had to be really close from my wifi router for updates to complete normally…
It is not necessarily a problem, as the goal is not to stream stuff non-stop from and to the Aeros, but you may be aware that when you need to update your Aeros, you have to move it to the right place…
OTA Update failing for 3.1.18
First time sat at the Aeros Splash screen -
Power off and on showed it was still at 3.1.10.
Tried update again - stuck at 88.48% - I’m gonna leave it for a bit but then I’ll cycle the power.
The first failure not bricking the unit gives me hope
Should I try the SD card update method?
Thanks for a great pedal, oh and bluetooth midi would be awesome if you ever get bored dreaming up new features 
(or fixing undocumented features)
[Update1] Noticed I’m not the only one with this sort of issue -
I’ll try getting closer to the router (I have line of sight at about 8 meters)
[/Uodate1]
[Update2]
Fail - sitting at splash screen 2 meters from wifi router
Time to try manual update.
I hope this feedback shows you guys a solvable issue
[/Update2]
[Update3]
SD Card method worked perfectly!!
[Pincho_Paxton] said, presume by way of response to the isue of failed OTA updates that “Beta updates are by SD. Only final updates work by Wifi”
I dont belive a beta update is even atemptable via Wifi.
For the device to indicate a firmware update is available and prompt the user to download and begin the upgrade - is expected behavour for a release, which 3.1.18 at the time of my initial post was a pushed release.
I imagine some sort of internal staging issue caused the problem but that only a crude guess.
/Update3]
Cheers
M
Beta updates are by SD Card. Only the final updates work by Wifi.
To add to Quad’s and others comments… I’ve just let the WiFi update happen. The download seemed to work perfectly. It finished and then reset the unit (presumably to install the downloaded firmware). But now it’s just sat at the splash screen. No other messages (particularly not the “updating” and “progress”; also no splash dim that usually precedes those messages).
Seems like there is an OTA issue (but only when the image comes from WiFi?) - probably in the previous firmware since it’s not running the firmware yet. If that’s the case…I was running previous stable, not beta. Which I think was 3.1.10, but my memory might be wrong.
I will now try an SD card update as Quad did above and report back.
Update: SD card update worked perfectly (got same long wait at 99% that Quad described, but apart from that it was smooth).
I should note that I have only ever updated via WiFi in the past – without difficulty. So I don’t believe it’s a hardware/router/signal strength issue. That’s reinforced by the fact that the lockup happens after the post-download reset. What’s odd is that it’s happening before the screen changes to show an update is happening – implies that the fault, whatever it is, is very early on in the update process (does the bootloader check the firmware hash or a signature?). To help us help you in the future – perhaps it’s worth putting more debug information on the screen during the reflash process, so we can say exactly where the update is stopping?