Thank you for your donation!


Idea: on/off switch support
#1
Hi Tim,

To help with orderly and safe shutdowns I have added an on/off button to the moOde streamer I am building. Could you include support for an on/off button along these lines or something similar in the moOde distribution?

https://howchoo.com/g/mwnlytk3zmm/how-to...spberry-pi

A few ideas?
    1. As part of the system config page.
    2. As a script that could be executed via ssh.
    3. As part of your existing GPIO handler.

Thanks for your consideration and for moOde!

    John--pics and schematic soon
Reply
#2
Hi John,

The challenge is that there are many different Pi shutdown products each with their own unique scripts. This makes it difficult to support a "push button shutdown" feature as an integrated service. Your best bet is to use the GPIO button handler to map a GPIO pin to your script.

-Tim
Reply
#3
Hi Tim,

I wasn't asking about support for a wide variety of shutdown products, I know that is not feasible. However, I do feel that start/stop support for a simple normally-open push button would be a very good idea with strong stability benefits. The problem for me is having to reinstall everything once a new image is required either for an update or because of sd corruption.

I saw another poster suggest moving to a stable/development model. I second that. Stability is paramount to wider adoption and a rosy future. I think that always having a rock steady release available would be very helpful to the project.

Best regards,

      John
Reply
#4
Right but a good arguments have been made for other hardware shutdown solutions so I decided to leave this feature up to end user or vendor to implement. It's same for all the different LCD / OLED screens, IR remotes and other peripherals.

The stable/development model really means being able to actively support two complete releases at the same time including troubleshooting, bug fixes and updates. The moOde project only does this for the current release. We would need an additional developer thats willing to commit long term to supporting a legacy or stable release.
Reply
#5
This stable/development model is hard to maintain even with multiple developers. 

There are inevitable dust-ups over what gets backfitted to the stable release after its issue vs what goes into the development "release". It seem easy when talking only about new features but it quickly gets hard when bugs and security defects are discovered in the stable model... harder still when desirable new hardware like the RPi4 shows up and needs OS features not in the stable release. I won't name projects but some big, well-staffed ones have had real problems with this approach.

An extreme alternative is MaxK's approach to MPD. In effect it's a github stream-of-consciousness. Some checkpoints are denominated with a version number (MPD 0.21.23, for example) but that's only for reference. None constitutes a stable release in the sense I believe is meant here. A given version is what it is, warts and all. MaxK never looks backward.

At the moment, the moOde approach lies somewhere in between these extremes. I suppose you could keep some number of previous versions available on the server as "stable" releases but users would be on their own.

Regards,
Kent
Reply
#6
The approach taken with MPD is typical whereby only the current release is officially supported by the maintainer. It's same with moOde project.

We do have master and development branches in our project Git repo and our master branch represents the code base for the current release and the development branch represents the code base being worked on for the next release. After we publish the next release we merge the development branch into the master branch and they become equal at that point.

I should add that we do maintain previous releases but they do not receive any bug fixes or updates.
https://github.com/moode-player/moode/releases

I agree that supporting two complete releases at the same time even with additional dev help would be very difficult.
Reply


Forum Jump: