Posts: 159
Threads: 19
Joined: Mar 2020
Reputation:
3
Hello Tim,
being able to control rpi power and activity LEDs since version 6.5.0 directly in the interface is a cool feature however why not relate the LEDs' operation to the status of the moOde player itself rather than that of the rpi ?
I wrote a small shell script and systemd units without any other pretention than just indicating the status of the sources and automatically try to remount them if they get disconnected for any reason.
The howto and files can be found here if they can be of any use: LED control on rpi 3B+ and 4B (moOde 6.4.2+)
Posts: 13,351
Threads: 302
Joined: Mar 2018
Reputation:
538
Hi,
I'll check it out. I'm wondering though, how can a source become disconnected other than the NAS or the Network going down?
I do vaguely remember rare "stale file handle" errors that resulted in adding the RE-MOUNT function to Library Config. Is this what's happening in your case?
-Tim
Posts: 159
Threads: 19
Joined: Mar 2020
Reputation:
3
That's exactly my point Tim, if something goes wrong with the network - server crash or connection loss - you can almost immediately see, 1 minute after at most, that there's a problem by just looking at how the LEDs operate. The possibility to remount the sources upon network return or crash recovery is just a plus as you won't need to connect to the interface and remount them manually.
Also, when the moOde player starts, a fixed green LED shows that everything is OK and that the player is ready to play, can still be useful imho.
As an example, I use two of my moOde players, one in my office and one in my bedroom, wirelessly connected to an AP in my living room. If the signal gets too weak because they are a bit too far from the AP, green LED turns off and red LED starts blinking. If I move them closer to the AP and the signal gets strong enough, allowing them to hook the network up again, sources are automatically remounted, red LED turns off and green one turns on again.
Posts: 13,351
Threads: 302
Joined: Mar 2018
Reputation:
538
I think auto-remount is goodness for all users but I'll have to think about how the LED status feature will co-exist with the existing LED feature. The existing feature is for users that want to turn the LED's off. Maybe on System Config we could do drop downs like below.
Code: LED0 (Act): [ ] On, Off, Mount Status
LED1 (Pwr): [ ] On, Off, Mount Status
Btw, what Open Source license do you want to attach to your nice script, GPLv3, MIT?
-Tim
Posts: 159
Threads: 19
Joined: Mar 2020
Reputation:
3
(04-29-2020, 10:25 PM)Tim Curtis Wrote: I think auto-remount is goodness for all users but I'll have to think about how the LED status feature will co-exist with the existing LED feature. The existing feature is for users that want to turn the LED's off. Maybe on System Config we could do drop downs like below.
Code: LED0 (Act): [ ] On, Off, Mount Status
LED1 (Pwr): [ ] On, Off, Mount Status
Btw, what Open Source license do you want to attach to your nice script, GPLv3, MIT?
-Tim Tim,
thanks for the compliment To be honest I hadn't thought about how both features would co-exist but I think your drop downs solution is the best compromise.
Also, will you change the default mount flags for NFS shares ? Unless you have a solution to this, with NFS hard mounts the risk is to see the script waiting indefinitely for the network share to be online again if it ever gets unavailable.
GPLv3 license is fine to me.
Posts: 13,351
Threads: 302
Joined: Mar 2018
Reputation:
538
What the issue with NFS? I don't have any experience with it.
Posts: 159
Threads: 19
Joined: Mar 2020
Reputation:
3
(04-29-2020, 11:10 PM)Tim Curtis Wrote: What the issue with NFS? I don't have any experience with it.
It will be better explained here Hard Mount Vs Soft Mount than I will do myself I guess
For a home server or a NAS, soft mount should be sufficient. Hard mounts are for client-server environments where data integrity is a major concern.
Posts: 159
Threads: 19
Joined: Mar 2020
Reputation:
3
(04-29-2020, 10:25 PM)Tim Curtis Wrote: I think auto-remount is goodness for all users but I'll have to think about how the LED status feature will co-exist with the existing LED feature. The existing feature is for users that want to turn the LED's off. Maybe on System Config we could do drop downs like below.
Code: LED0 (Act): [ ] On, Off, Mount Status
LED1 (Pwr): [ ] On, Off, Mount Status
Btw, what Open Source license do you want to attach to your nice script, GPLv3, MIT?
-Tim Rethinking about how both features would co-exist, I think LED0 and LED1 shouldn't be set independantly when choosing the "Mount Status" because both LEDs are useful for this purpose. Does it make sense ?
Posts: 5,993
Threads: 175
Joined: Apr 2018
Reputation:
233
(04-29-2020, 11:17 PM)romain Wrote: (04-29-2020, 11:10 PM)Tim Curtis Wrote: What the issue with NFS? I don't have any experience with it.
It will be better explained here Hard Mount Vs Soft Mount than I will do myself I guess
For a home server or a NAS, soft mount should be sufficient. Hard mounts are for client-server environments where data integrity is a major concern.
If moOde is mounting NFS resources with option 'ro' then the data integrity issue is moot. May as well choose soft mount to avoid the possible zombie state where the system hangs forever waiting for the server.
Brrr. I get the shivers remembering the bad old days when my lab and others had multiple cross-mounted filesystems on our engineering workstations and we'd end up in deadly embraces trying to bring them back up after a crash. What made it worse was our research facility were a heterogeneous OS shop---countless SunOS/Solaris stations, a few dozen SGI IRIX stations, a handful of IBM AIX stations, even one or two DEC Ultrix stations. The network administrators didn't last long.
Regards,
Kent
Posts: 13,351
Threads: 302
Joined: Mar 2018
Reputation:
538
(04-29-2020, 11:28 PM)romain Wrote: (04-29-2020, 10:25 PM)Tim Curtis Wrote: I think auto-remount is goodness for all users but I'll have to think about how the LED status feature will co-exist with the existing LED feature. The existing feature is for users that want to turn the LED's off. Maybe on System Config we could do drop downs like below.
Code: LED0 (Act): [ ] On, Off, Mount Status
LED1 (Pwr): [ ] On, Off, Mount Status
Btw, what Open Source license do you want to attach to your nice script, GPLv3, MIT?
-Tim Rethinking about how both features would co-exist, I think LED0 and LED1 shouldn't be set independantly when choosing the "Mount Status" because both LEDs are useful for this purpose. Does it make sense ?
Makes sense. Im not sure how to do the UI options cos some users want to control each LED, mainly leaving power ON but turning the activity LED off.
|