search

motioneye-project / motioneye

A web frontend for the motion daemon.
GNU General Public License v3.0
4.01k stars 661 forks source link

Plan for continuing with this project #2307

Open MichaIng opened 2 years ago

MichaIng commented 2 years ago

@cclauss @Mictronics @jmichault and everyone else, let's make a plan how to continue with this project, now moved to the new @motioneye-project GitHub organisation.

First of all, everyone who has contributed to motionEye before, or wants to do so, please feel free to join in, also I think we can add everyone who is interested to the organisation.

I think we agree that Python 3 support is the first thing to achieve, given that Python 2 has reached EOL since over 2 years already, @jmichault and @Mictronics have Python 3 compatible forks from where we can commit back, and on this repo we have the python3 branch and a bunch of open pull requests for further related fixes.

I personally would go this way:

Approximately from simple to difficult, regarding possible conflicts 😉.

starbasessd commented 2 years ago

I would like to continue contributing in my way (docs and support, rather than code) if you'd like, as a collaborator.

MichaIng commented 2 years ago

I just invited you to the organisation. This way you should be able to create branches right here on the main repo, but I think this was already the case before, since you were a collaborator already.

starbasessd commented 2 years ago

I don't know anything about programming, especially in the github environment, I was able to edit the wiki documents, and assist end users as needed, and marking issues with the various flags (which hadn't been done prior to my being given collaborator status. I am a script-kiddie in python2 & 3, pretty good with bash and dos command (win) scripting, and so forth. jasaw (video/motion issues) and jawsper (brought an image of motionEyeOS) are both very good in what they do. I am a professional beta tester, too, since back in the Zoom Modem voicemail days (for the C64 & Early PCs), I can break things quite easily. I am an Enterprise (Level 2 & 3) Senior Help Desk, for the past 25+ years. I do translations between end users and developers. I have a lot of resources available for testing (VBox VM Server Ryzen7 CPU 32GB RAM/10TB Storage, Gbit network, Pi1, 2, 3B, 3B+, 4B-4GB and 4B-8GB, PiZeroW, 8 Network IP cams, 2 USB Cams, 1 CSI PiCam) and used them regularly for helping out here. I do docker some, too. If you go through the WiKi, I've done a lot of updates to a lot of the pages. If someone uses an esoteric (read: non-Debian based) OS, I'm willing to try to get it to work, and then document it... Let me know if you can continue to use my 'services'....

starbasessd commented 2 years ago

One other question: Will this be applied to motionEyeOS too, or no?

MichaIng commented 2 years ago

That is very valuable, always good to have someone with some focus on the docs, issues/bug report review and testing side. Also Docker experience is good, which I lack, while I see the Dockerfile here.

I haven't had a look into motionEyeOS yet. I personally would concentrate on getting motionEye itself up and ready for Python 3 first, and then update Docker images and motionEyeOS in a second step. But those two definitely need others with more insights and experience with Docker and BuildRoot.

kleini commented 2 years ago

I would like to contribute, too, if my spare time allows me to do that. I am a long time developer and familiar with Python 3, Docker, Kubernetes.

cclauss commented 2 years ago

My preference would be to add #2308 as step 0. given that it is now green and puts in place some important guardrails.

MichaIng commented 2 years ago

@cclauss Okay, it doesn't hurt anyway. I made some comments as minor enhancements, otherwise good to be merged from my end.

I just invited you both as members to the orga. I'll send out invitations to all motionEye collaborators, which have their permissions preserved anyway. That way we also see who of those is still active and interested to continue contributing to the project 🙂.

jmichault commented 2 years ago

Hello, my python3-intl branch is ready to be merged : https://github.com/motioneye-project/motioneye/pull/2313

MichaIng commented 2 years ago

Awesome, many thanks for your work. From my end, I'd merge python3 first into dev and then rebase and merge PRs with python3 as base onto dev. It practically may not make any difference, after I resolved conflicts between those branches with the result that python is now up-to-date with dev, but it somehow feels more natural to me 😅.

jmichault commented 2 years ago

@kleini, Hello, I tried to modify Dockerfile to take into account all the changes made for python3 and internationalization. Can you take a look to see what's left to do?

MichaIng commented 2 years ago

From what I see it contains all changes which were applied to dev/python3 branches before, so should be fine. Only thing which went inside as well is that python3-pip is not purged for the final image, while python-pip was purged before. If I'm not mistaken, motionEye does not require pip, so to reduce the container size a bit, this could be re-added to the list of purged packages. But as always, also since you switched (reasonably!) to Bullseye, it simply needs to be tested 🙂.

kleini commented 2 years ago

Just had a quick look on the "Install in Docker" wiki page and the Dockerfile. Building the container image works and the container works. Getting a picture from my network cameras works as well. So for a first step everything is fine. General questions from my side would be:

cclauss commented 2 years ago

Where is CI gone?

https://github.com/motioneye-project/motioneye/tree/dev/.github/workflows

starbasessd commented 2 years ago

Initial configuration file /etc/motioneye/motion.conf does not work.

Because motion is controlled by motionEye, and the motion.conf settings needed are in /etc/motioneye/motioneye.conf

starbasessd commented 2 years ago

I think, it would be usefull to separate motionEye und motion into separate containers if communication is possible across container boundaries.

Why? Why increase the complexity? Multiple points of failure? Diagnostics issues when something does break? Different versions / builds / new dependencies when something is updated? Have one force update the other? When motion updates and breaks the 'current' version of motionEye (it has happened) how do you control either? With fixed versions in a single container, you update as a package. The Docker IMO brings everything into the package needed to run to assist with the above questions.

starbasessd commented 2 years ago

From what I see it contains all changes which were applied to dev/python3 branches before, so should be fine. Only thing which went inside as well is that python3-pip is not purged for the final image, while python-pip was purged before. If I'm not mistaken, motionEye does not require pip, so to reduce the container size a bit, this could be re-added to the list of purged packages. But as always, also since you switched (reasonably!) to Bullseye, it simply needs to be tested 🙂.

pip is purged (and the ability to exec in the container) to prevent people from making changes (similar to the RO file systems in motionEyeOS), from what I've discovered. Pretty effective. motionEye doesn't need pip after installed. Pip is only needed after install in a 'normal' install to do an upgrade:

pip install motioneye --upgrade

kleini commented 2 years ago

I think, it would be usefull to separate motionEye und motion into separate containers if communication is possible across container boundaries.

Why? Why increase the complexity? Multiple points of failure? Diagnostics issues when something does break? Different versions / builds / new dependencies when something is updated? Have one force update the other? When motion updates and breaks the 'current' version of motionEye (it has happened) how do you control either? With fixed versions in a single container, you update as a package. The Docker IMO brings everything into the package needed to run to assist with the above questions.

Because this large container needs to be rebuild completely for every little change. Maintaining a deployment is much easier, if different tools - motionEye and motion in this case - are in separate containers. The correct combination of containers can be controlled with various tools like docker-compose, kubernetes, Helm charts. And furthermore motion requires a lot of CPU resources. Having those split across multiple containers improves overall performance. An ideal case would be to have every process running in its own container. A container based on some normal OS like Debian Buster in this case, is often a problem with containers. Containers should not run an OS, making those containers error prone and vulnerable. As previously stated, a container just runs a single process. Having tools separated in this way, allows to have a motionEye container image, which only contains some Python runtime and motionEye, nothing else. If motionEye has any vulnerabilities the underlying container allows nearly no operations except running motionEye.

An incompatibility problem between motionEye and motion is a problem of pinning versions of both tools. This is not solved by a single container image. This must be solved by pinning these versions and it does not matter, whether they are in the same container image or in separated ones. And the motionproject already does provide a container image, so we don't need to download some built motion any more and include that in our container image.

starbasessd commented 2 years ago

Are you going to support cross host setups too, when people using clusters install motion on one host, and motionEye on another host?

kleini commented 2 years ago

Are you going to support cross host setups too, when people using clusters install motion on one host, and motionEye on another host?

This would be an interesting approach.

cclauss commented 2 years ago

Because this large container needs to be rebuilt completely for every little change.

This is not really true. There is tons of documentation about the order of commands in a Dockerfile to reduce long builds.

starbasessd commented 2 years ago

The advantage, IMO, of a complete container, is you don't care what the docker host is running. The same docker for motionEye runs on all the debians, the RHs, the Arch, whatever. (Theoretically, Windows, too) without consideration of what is needed vs what is already installed on the host, and no communications issues between the packages (if the sandbox system WORKED, they would not be able to easily talk to each other, or possibly other containers...)

starbasessd commented 2 years ago

Because this large container needs to be rebuilt completely for every little change.

This is not really true. There is tons of documentation about the order of commands in a Dockerfile to reduce long builds.

If you read the option 3 in Install In Docker it pulls existing base 'images' of the OS, installs only what motionEye needs, and doesn't need 'get a cup of coffee' break. This was modified because of the age of software included in the existing version, and documented in the spirit of open source / open documentation on how to 'make your own mods'. If it goes the way of 'single process per container, and the complexities of managing many (possibly many, many?) packages and containers, I may fork the project (I will for me) because I deal with average newby non-programmers and developers who want to learn how to make changes or fit their situation without the need to go through a 4 year IS college degree to understand it.

starbasessd commented 2 years ago

IMO motionEye is not a corporate project, but for the average street Joe who plays with RPis and SBCs or is getting into Linux on PCs and has a few IP or PiCams laying around. Corporate developers and programmers seem to not think about how a product is used, they write for a corporate environment, not a home environment. Maybe a bad analogy, but think about a dishwasher. What if you had to have a BUNCH of devices to do the same job as the single dishwasher? A machine to do the pre-rinse, a device to do the primary wash cycle, a device to do a final rinse, a device to do a sanitizing rinse? Would you buy all those devices or a single device?
My contribution to the previous version of motionEye was to support the end user (mostly street Joe), with testing to determine if their issue was Bug or PEBKAC, bad documentation, or something else. If I wasn't able to tell up front, I tried to reproduce the issue, and point it in the right direction. In the process, some things were simplified and better documented. I found ways around the pip2 issue and included them to extend the longevity of the project. I've been digging into the docker image issue to get it out of Debian 9 and up to Debian 10 (and soon Debian 11, maybe) and into motion 4.3.2. because I think this is a better product than most of the other options out there.

MichaIng commented 2 years ago

IMO split containers is overkill here and causes more issues (complexity for users) than what it may solve (the ability to update it independently of motionEye). Also AFAIK motionEye executes motion directly and accesses its config file, so it isn't possible.

starbasessd commented 2 years ago

Y'know, I just found a reason to possibly split motionEye from motion from motionEye, however, I still do not think it's a "Good Idea"(tm) for Joe Average-user, and that is the Hub Only functionality (no motion detection, but to control and view other motionEye Cameras. There isn't any motion detection capability, or transmogrifying video capability... Again, I don't think this is a needed option for motionEye... https://github.com/motioneye-project/motioneye/wiki/Installation#the-motion-daemon

cclauss commented 2 years ago

https://pypi.org/project/motioneye-client also exists.

starbasessd commented 2 years ago

Not a CCrisan project, or motionEye project. There are a number of unofficial apps for phones, too...

MichaIng commented 2 years ago

the Hub Only functionality

If one wants that, then one obviously wants things to be split explicitly for some reason, and in this case Docker may not be the preferred solution anyway. IMHO our Docker image should cover the average case and address especially the users who want to spin up motionEye as fast and easy as possible, which is a single container image so you can do docker run are things are working.

MichaIng commented 2 years ago

I reviewed all open pull requests now. Some became obsolete in the meantime (closed), some partly (asked for rebase), some are quite nice and seem safe to apply (asked for rebase and in case asked for review from some of you guys), some merged already, some require further work (converted to draft).

I hope we get outstanding replies soon, so rebases are done and we can review and in case merge those. If you guys find time to answer the review requests, that would be great, so in case we can merge what is ready from my end.

I'm quite happy to see, that there it nothing really depending or affected much by the move to Python 3. Most conflicts are due to extra moved to motioneye sub directory and utils.py + handlers.py being split into dedicated files, but on first view it doesn't look too complicated to migrate the changes over.

Gonioul commented 2 years ago

For docker, would be nice to merge with https://github.com/hassio-addons/addon-motioneye and have an official addon.

MichaIng commented 2 years ago

You mean to use the same Dockerfile? They install Mosquitto, Nginx, a whole build essential stack (for compiling motion, at least) and other things which seem unnecessary for our needs, while there may be some reason for this for a Home Assistant addon. Also they use the ghcr.io/hassio-addons/base/amd64 base container which may contain other things we do not need.

I think HA guys will know best what a HA addon requires while we know better what a standalone motionEye container requires 😉.

I'll do a suggestion for more generic install instructions soon, which may then serve as basis for the motioneye_init script, Dockerfile, Wiki and README, to align everything as much as possible. In theory, everything, including CI, could use motioneye_init then.

Gonioul commented 2 years ago

Of course what I meant was to minimize the differences to allow simpler upgrades and security updates. Not have the same image.

MichaIng commented 2 years ago

I'd say this is more on the HA addon's team to decide how closely to follow our reference instructions. But we can let them know about those, once defined, for the Python 3 release.

MarcelCoding commented 2 years ago

I could help provide the necessary configuration for GitHub Actions to build Docker on multiple architectures.

MichaIng commented 2 years ago

That would be great. I'll add you to the orga and repo as collaborator so you can create branches right here (not requiring a fork).

Nik71git commented 2 years ago

One other question: Will this be applied to motionEyeOS too, or no?

Since I move recently from MotionEye to motioneyeOS... I'm courious too about the question

MichaIng commented 2 years ago

https://github.com/motioneye-project/motioneye/issues/2307#issuecomment-1062407214

The motionEyeOS repository has been moved to this organization as well now, so generally we can take care of it. But what I said above stays valid: First of all we need to concentrate on a stable motionEye release. I'll see when I find time to check about updating motionEyeOS afterwards. But of course, if anyone has more insights/experience with motionEyeOS and is able to create a test version with current motionEye dev branch version, feel free to do so, open pull requests etc. We can add a dev branch for it as well and add more collaborators to it for easier/faster commits and building test images.

fulippo commented 2 years ago

I could help with the italian version if you like. Also can provide help on coding or CI

MichaIng commented 2 years ago

Very welcome. Quick translation update instruction are here. We, from my end at least, plan to switch strings from Esperanto to English, add instructions to the Wiki about how to update translations, and add a GitHub workflow to trigger automatic rebuilds + commits to a PR via command comments.

Generally on contributions at current stage: There are a few pull requests open with smaller changes and also some new features (WebDAV uploads, S3 uploads, and more). It is always great to have some more eyes on the changed code and in case testing it. Generally motionEye can be installed from any GitHub branch, following the install instructions from here and replacing branch and in case owner of the final URL argument for the pip command. Would be great if we could merge the open PRs soon, then make a feature freeze and concentrate on testing, bug fixes and minor polishing for a release 🙂.

VoeGalore commented 2 years ago

I am using last dev version of motioneyeos and last released version of motioneye by @ccrisan , glad this project is alive again!

I wish to help with Chinese translation of UI (natively Chinese simplified, but mostly compatible with Chinese traditional).

zagrim commented 2 years ago

We, from my end at least, plan to switch strings from Esperanto to English

Just as a note: I noticed one more reason in favour of this: The machine translation (that is applied when adding translatable strings) works better from English to any language than from Esperanto to any language (probably due to translations between "non-English" languages using English as a middle step).

zagrim commented 2 years ago

And for the record, I can do translation to Finnish. But it might be a good idea to try to first get all the UI strings within the translation support.

MichaIng commented 2 years ago

Also deepl.com (which works MUCH better than Google translator or any other translator I know to generate natural well sounding sentences) supports English but not Esperanto.

Nik71git commented 2 years ago

but really do you think esperanto worth the effort to translate?

MichaIng commented 2 years ago

As all strings (aside of possible new ones) are available in Esperanto already, and because I generally like the idea of a non-English plan language, I'd say yes. And we have someone in the team who knows it well + it's easy to translate from English to Esperanto via online translators.

But indeed, it's no ones mothers tongue, so in theory it is aimed to be how we use it currently (the i18n basis), not likely to be used as locale by end users. So when we switch to English as i18n basis, indeed it is left more for personal like or ideological reasons than for a practical user need, I guess. However, it does not hurt, and probably it catches someones interest about what Esperanto is and to learn it 🙂.

gustavovelascoh commented 2 years ago

Hi, I would like to help in the project. Initially, I could help with the Spanish translation if still required.

MichaIng commented 2 years ago

That would be great. See short instructions here: https://github.com/motioneye-project/motioneye/pull/1968#issuecomment-1067103098

Spanish .po (backend) and .js.po (frontend) files can be found here: https://github.com/motioneye-project/motioneye/tree/dev/motioneye/locale/es/LC_MESSAGES

You can use the English translation files to derive the original text, if Esperanto is an issue.

jmichault commented 2 years ago

@fulippo and @gustavovelascoh

If you need some help translating, create a new issue and i will guide you through the different steps.

Edit: translations are now managed on weblate : https://hosted.weblate.org/projects/motioneye-project/.

jmichault commented 2 years ago

We have received several proposals for contributing to the translation of motioneye. It would be easier for the translators if we interfaced with a translation site.

Personally I have a preference for weblate, which offers free hosting for free projects, and is interfaced with github.

Does everyone agree?