You make an excellent point indeed, however there is a caveat to error reporting.
In order to report the error the software has to know there is an error first. Speaking with no knowledge of the internal error handling routines in the firmware, but if software or firmware becomes unresponsive this is often cause something has caused the code to loop or run too much. In this case the code would not know to log an error.
There are many other issues here too. But it remains a case of that if the unit knows it is in an error state it should recover either by resuming function or show an actual error. If the error is causing it to hover between these states or reboot, thereby causing memory to be lost, I am not sure if the error will or can be reported.
I would agree with you, although I suppose it depends on what the Naim software does in collecting diagnostic data. If it collects a memory dump, then I suppose thatās something that can be sent directly to Naim over the internet, assuming its not too large. It may just be collecting event logs which might give an indication on what the device was doing prior to the crash. Now Naim wouldnāt want all logs on all devices all the time, but I suppose there is no reason why the app couldnāt give an option to send diagnostic data to Naim following a crash - again like a Apple Mac would. Hopefully Naim are thinking about it, and if they do introduce it, lets hope that code is well written and doesnāt cause issues in itself
Yeah, it all depends on how the software approaches this. And yeah you can collect and send everything but that causes two potential problems:
Possible privacy issues.
Trying to find a needle in a haystack of collected dump data.
Bad error logging is sometimes worse than no error logging.
But certainly, if it is targeted and useful I would say go for it. Only, turning on the āLog all the thingsā switch does not mean it becomes helpful.
On a computer you have a lot more persisted data as well than on something that loads everything into normal or flash memory so they can do more targeted reporting of the error conditions as the persisted storage can be used to reconstruct more info.
Computers donāt just spontaneously reboot on their own. Thereās either an exception handler that is being called that does the reboot. Or the external reset line to the microprocessor is being pulled. In the first case, they should be logging this information so that it can be collected. For the second case, they should know the conditions that will cause this, or the chip that did the hardware reset will possibly have log information also.
No Idea if itās related to the firmware, but had a strange issue tonight.My Star wasnāt responding to the app or Chromecast even though botth could"see" it. When I tried to operate it with the buttons, it seemed it didnāt respond initially although at some point the display showed a different input but so much delayed it was impossible to tell what to do next. So much I couldnāt really select anything.
When I wanted to turn it off by keeping the power button pressed nothing happened. Volume dial on top seemed to be blinking.
As itās my daughterās birthday and I had guests I just unplugged it, which fixed it.
Yeah I had pretty much exactly the same on my Star. Slowed down like crazy. Selected input and 10 seconds later reacted. Then pretty much froze. I could deep sleep it with the power button but that lagged too, screen remained active for a while. Power down fixed it for me too.
So hereās a theory. The volume of issues with 3.5 plus the fact that they seem to have caught Naim by surprise may indicate the poorly done merging of a whole new branch of code into the main line. You would have done this if for example you had been developing a new product and it was nearly ready for release. Merging new productās code into the āreleaseā branch is a common step just before product enters final test. New product could be, oh I donāt knowā¦ a 372?
I am running with this theory as it means the replacement 272 is nigh!
I do know for a fact development has been working on classic code. Now no one had mentioned what that code may be, but I wouldnāt be surprised if your hunch is close to reality. I do know on the core for example, they are using an updated version of Samba. This maybe the cause for the streamers as well. Naim will make it right. I still have outstanding issues with the core after the latest and it was well documented into the beta forum but never made it into GA code release.
So I think I may have experienced my first random reboot. Came down this morning to find my Nova āblinkingā, with menu and volume control lights pulsing on and off. Did a 3 sec hold of power button to reset and all seems fine for now. I thought Iād escaped the 3.5 problems. Of course, it may have been a power outage but I donāt know.
Just had another random reboot (my second, but first after doing the power cycle plus cup of tea thing). This time, however, I saw a āPairing Completeā screen, which is a new one. Itās as if Iāve paired the remote again (which I havenāt).
My Atom now refuses to show any cover art at all, I normally have my display off however it use to show the cover for a few seconds before turning its self off. Now nothing, just a black screen. It still shows volume levels and it doesnāt seem to shutdown as well. The app is also playing up, it refuses to show my Muso but itās there to stream to, think weāve got ghosts in our machines.
Will be emailing Naim Support with info on firmware update effect on my Nova, which has appeared over the last three days via the following issues in no particular order:
App setting to turn display off not working or intermittent.
Power off and on during playback of vinyl LP.
No ability to apply any settings during playback. Sound working but app, handset and Nova buttons unresponsive so had to power off.
Volume display intermittent. Sometimes it displays sometimes and more often it does not via app, handset or physically turning the volume wheel.
