If you use DHCP, the interface freezes and you have to reboot the PS, which does not happen when it is static, thus there is a problem and a bug; unless PS intended for the user to have unplug and plug the ETH cable, or reboot the PS to get it unstuck which would be an incredibly flawed design.
I give PS engineers a LOT more respect and credit, this precisely why I would be willing to bet anyone any amount of money that PS engineers would not design something so flawed.
I never said that PS can’t write a NIC firmware, I said that I doubt they would because the NIC in the PS units does not need to do anything special for a NIC, so unless they are using a custom and extremely unique NIC it would make not much sense to assign engineering resources to develop something that it is available from the OEMs, that has been tested.
If PS is using an FPGA to mount the NIC, then the use case is even simpler.
Although I am not the ultimate authority, not even close, and I that I do not know anything on how PS is run, I would be shocked if PS was in the business of developing a very special NIC costs at the very least hundreds of thousands in design, development, instrumentation, testing and manufacturing.
I also seriously doubt that PS sells enough devices to even amortize these development costs.
Without getting into much details, I lead a group of R&D engineers that develops FPGAs and GPUs for one of the top 3 largest consumers of hardware in the world. My company deploys anything between 200K-300K GPUs, 400K FPGAs and 200K NICs a month so I know very well, at least for my company, what it takes to go and develop new hardware/software. It is becoming very hard to make a business case for not leveraging what is already available.
I also seriously doubt that any of the manufactures you motion develop their own firmware; what manufactures do, is to add/remove/enable/disable features to the OEM’s firmware so the firmware becomes a branch from the OEM’s. Again, developing a NIC firmware from scratch would be an insanely bad decision, as there is already firmware developed by the OEMs with pretty much any functionality you can imagine, that has been tested, passed over 40 certifications, gets maintained, and fixed for the customer, in this case PS.
But who knows…anything is possible…maybe PS wanted the system to freeze, behave differently in one of the most adopted and enforced protocols in the world. I do not think it is very likely that they did.
I do not want to boil the ocean, I asked Paul a very simple question, why they do not offer a richer UI experience and to fix a few bugs that have been reported, and acknowledged by their own tech support, for years.
He reasonable responded saying that that was not the intent for the WebUI.
The next reasonable question would be, does the hardware have the resources to add more functionality? If the answer is no, then that is the end of the discussion.
If the hardware does have the resources to add functionality, then the next question would, does it make sense for PS to assign resources to offer a richer experience? If it is not worth for them, then could they offer access to the API so people outside PS could develop a richer UI experience?
I don’t need to see any of the stats while I listen to music, but it would be very interesting to be able to analyze and see what the Pxx did and does from the WebUI.
The PS-12 WebUI is broken, period; not one UI-developer would want to return failed queries or pointers (i.e. the REF in the WebUI) be exposed like they are in the PS12 WebUI.
The P20 also has bugs, again acknowledged by PS support, that have not been addressed for years.
PS support acknowledged these bugs, in some cases years ago, so unless anyone on this forum knows better than PS, then these are bug.
It is completely irrelevant what we think and want. It is either a bug or not. PS said that these are bugs, so for me the discussion is over with regards to them.
@Paul, thank you! It would be great if you could fix the P20 and P12. I just bought my second P20, and I have a P12 and I am going to be in a wheelchair for the next 2-3 months and having to go to the rack, get behind to reset the ETH cable, or flipping the switch in the back in the Pxx is not an option.
If you have an API doc for your Pxx it would be great if you could share it. I would love to make a prototype, that includes, the power current status, add a few graphs similarly to those in the touch-screen, and add programing logic to the outlets.
I think it would be great to be able to program/create and name a power-on sequence like,
Power on sequence #1
- Power on the TT.
- Power on the phono stage.
- Power on the DAC.
- Power on the subs.
- Power on the amp(s),
Power-off Sequence #!
- Turn off the amp(s)
- Turn off the subs.
- Turn off the DAC.
- Turn off the phono stage.
- Turn off the TT.
These sequences should not be all that difficult as you already provide the functionality.