another tom

Added a 500GB NVMe drive to my EISY and was following the instructions here: https://developer.isy.io/blog/eisy-way I ran the: sudo fl.ops setup.nvme.boot command. The process fails on this step: zpool attach -f zudi /dev/mmcsd0p3 /dev/nvd0p2 with the following error: cannot attach /dev/nvd0p2 to /dev/mmcsd0p3: can only attach to mirrors and top-level disks I tried it twice, once trying to create a 150GB extra partition, the second time not adding any partition. The results were the same each way. My udx Version is : 3.5.7_4 nvmecontrol devlist shows the following: nvme0: CT500P310SSD8 nvme0ns1 (476940MB) Any ideas what else I can try?

Ah! That was a little non-intuitive - but it does work. Once it is playing any media, I can change the volume, AND the volume setting stayed in place for all future files (which is what i wanted). The only part I was missing was that a file or steam had to be active in order to make the initial change. Thanks!

Same issue. Volume Control at top says 100%. If I change it below, the top still says 100% and anything played will come out of headphones at 100%. There doesn't seem to be a "write" of the volume setting when hitting "Play"

Thank you both for your ideas. With the exception of @DennisC's idea about setting vars in the code (brilliant!), I was aware of all these other approaches. The intent of my post was to request changes to logging to make all these "search and locate" steps obsolete. It would be a welcome enhancement if the logs could be used to corollate the initial event with the actions taken, rather than just list the events.

I have been trying to track down a rouge event that is turning off a device. In doing so, I have ended up becoming frustrated with the current "log" capabilities. They faithfully show the device being turned on this evening at 4:39, and then turned off at 4:55. What I can't tell is WHY it was turned off. Was it an event that fired in the eisy? or a scene activation? or a local switch pressed? I may not be able to track local switch actions - but it would be nice if the log was a bit more structured and could provide some more cause-effect data for things happening within the eisy. Maybe something like: This would tell me: Program "IsNightTime" triggered, and it was what turned on the FrontGang light (notice column 5 doesnt say "system"). Then the Off command actually came from a "HolidayProg" trigger than happened to have run earlier in the day and had a WAIT of 3 hours instead of 3 minutes. (Hint: I found the cause of this problem....) The last line still saying "System" would be the result of my directly toggling the status of the Device via the admin console. In summary - can the logging be improved to provide more information regarding the chain-of-events rather than just the actions?