Update as promised: as you could probably guess from a few of the posts above, we’re moving straight to 3.60 on the Firmware front, following some very promising early trials. Should be in beta within the next week. Will keep you all in loop.
10 Likes
In beta within the next week.
When are Naim planning on releasing
3 6.0 for the rest of us?
As ever, that will depend on how well the Beta test goes
I might be missing something but it seems to me that Naim is wasting time.
3.6.0 is meant to address a freeze/reboot issue that, allegedly, only affects a negligible number of NDX2 and ND555 devices.
What is the point of beta testing an upgrade that is designed to have no effect for the large majority of beta testers?
Why isn’t Naim just trying to solve the freeze/reboot issue specifically for (a sample of) those users who are affected by the issue?
After the problem has been sorted out, Naim could try to integrate the solution into the standard firmware that works well for the majority of the devices.
1 Like
How do you know the list of fixes and improvements that are included in 3.6.0? It would be unusual to go from 3.5.2 to 3.6.0 with just one little additional fix, so I doubt this is all there is
To test that it really does not affect them and does not break anything, for instance?
It would perhaps be unusual but certainly better than trying to fix many issues at the same time. Naim have already tried and failed to fix the reboot/freeze issue often enough that they should better focus on this issue and nothing else. It is rarely a good idea to try to do more than one thing at the same time.
1 Like
Thing is you don’t know this until you test it.
2 Likes
There are many possible valid reasons. By way of an example that may have nothing to do with reality in this case, but is something I have seen countless times on other projects: They may e.g. have had a workaround for the reboots in 3.5.2 and a more fundamental fix planned for later, which however requires larger changes elsewhere in the code that are available only on 3.6 and cannot easily be merged back to 3.5. For whatever reason they may then have decided to skip 3.5.2, in this example a possible reason would be that the workaround didn’t fix it reliably or had side effects.
I work in a software company being responsible for user support and relations and I can tell you that the last thing we need is customers who have <1% of the information telling us how to do our release planning 
4 Likes
Yeah well at least you didn’t say “what successor…” 
2 Likes
Not wasting time, hopefully ensuring it actually works to fix the problem this time as its not always apparent instantly. This is the point of beta testing after all. Being on the team can’t really say any more. But a lot more people have signed up to help so this gives us a bigger indication of users that seem to be affected and possible causes.
1 Like
This is true but the problem is that, so far, beta testing has not help recognizing and fixing the freeze/reboot issue. As @Naim.Marketing argues, this is most likely because the issue only affects a small minority which is not properly represented in the sample of beta testers.
If this is the case, it would be more effective (less time consuming) to first distribute a pre-3.6 to those users who are affected by the freeze/reboot issue and then proceed with beta testing 3.6 once it has been ascertained that the issue has really been fully understood and fixed.
This would also have the advantage that the users who are affected by screen freeze and reboot events receive a fix before the beta testing process of 3.6 is completed.
1 Like
If the pool of beta testers meanwhile contains a representative number of users who are affected by the freeze/reboot issue, then beta testing 3.6 directly makes of course sense. So far, however, beta testing has not been effective for spotting and fixing the issue.
Oh believe me I am fully for faster releases. But the other part of Beta testing is not just to see if something has been fixed but to ensure that the fix did not break things that was working before. By officially releasing an untested version, even to a small group of clients, the result is super unpredictable.
1 Like
I don’t fully understand why some users , let’s pick ndx2, are affected with screen issues and others are not.
Unless Naim understand the problem how can the firmware provide a confident fix?
I will attempt something of an explanation.
Issues happen in any software because certain scenarios are not catered for the code. This can be for a number of reasons.
With these type of devices they are being controlled from apps on different platforms, can be attached to a large number of external devices and then you have the sequence of events of how a user goed about doing what they are doing.
Take for example an app where you can select a song, play the song, scroll to a position in the song. Say that the developers/designers of the app accepts that the song will be playing before the user sets the position int he song it could break if a user does it before starting the song. This is a very simple example that has nothing to do with what’s happening here, but I am trying to illustrate how sequence of events of user actions can trigger things.
So testing is trying to discover these scenarios and fixing them. And add to that the different external devices and sources and it increases the chance of finding something in the code not catering for THAT scenario.
So it is usually not a case of not understanding the problem but not knowing that it exists as it has not been encountered before.
2 Likes
None here understands that of course, hopefully somebody at Naim does. Given what I have read so far on this forum, I tend to think that those users who are affected by screen issues have a different hardware from those who are not. This does not need to be the case, of course. But it is a possibility.
The other thing that I find a bit surprising is that Naim has not so far been able to fix the issue. This is not rocket science and audio software routinely undergoes upgrades.
I have gone through dozens of MPD, upmpdcli, MinimServer, etc. upgrades over the last couple of years. None of them has brought any regression in my system. Naim’s software seems to be a bit unstable. Perhaps it is not mature enough but, again, perhaps it is just an hardware problem. We will see.
In spite of @Naim.Marketing’s reassuring post, I do think that it is possible that those users who are affected by screen issues (apparently a very small minority) have a different hardware from those who are not. This doesn’t need to be the case of course. But it could be the case. Sometimes errors just happen.
Clare said they don’t. I don’t know how rare it is, I used a Nova and an NDX2 and both hat spontaneous reboots, though the Nova was more problematic. If it is a very small number, I was unlucky; possible of course.
Count me unlucky too. Nova, NDX2, reboots.