Requiring using the launcher is silly

[pfalcon]

Failing with #6, we're proceeding with python3.7 -m venv .... Looking at setup.py there're bunch of dvr-* entrypoint. But running them have no effect:

(.venv) dvrip$ dvr-info
Usage:  info
(.venv) dvrip$ dvr-info 192.168.1.10
Usage:  info
(.venv) dvrip$ dvr-info -h 192.168.1.10
Usage:  info

That's apparently because "calling conventions" for subcommands have changed, and nowadays

	if host() is None:
		usage()

is always true.

[pfalcon]

But from #6 (comment) we know that "calling conventions" are still exec'ing individual dvr-* executables!

Now the reason behind funkiness like:

		environ[DVR_HOST] = host
		environ[DVR_SERV] = str(serv)
		environ[DVR_USERNAME] = username
		environ[DVR_PASSWORD] = password

becomes clear - dvrip.cmd.__init__ parses command line options (with getopt! In 2019 with python3.7!), and passes their values via child process environment!

[pfalcon]

There's a bit more funkiness for reverse engineers among us:

	port = environ.get('DVR_PORT', '34567')
...
		environ[DVR_SERV] = str(serv)

So, dvr command can take port from DVR_PORT envvar, but will pass it to downstream commands via DVR_SERV. And for majority of people, "serv" is abbreviation of "server", though of course reverse engineers among us will find out, that in this case, it's abbreviation of "service" (as in: textual name of a port number).

[alexshpilkin]

The dvr-* commands never did work standalone. I admit that my attempt to factor out some of the boilerplate into the dvr launcher came out a bit silly, but... it made sense at the time, and I haven’t gotten around to fixing it. (I should.)

You don’t have to reverse engineer anything, you can just ask :)

[pfalcon]

The dvr-* commands never did work standalone. I admit that my attempt to factor out some of the boilerplate into the dvr launcher came out a bit silly,

If you take votes on this, I'd suggest to drop individual dvr-* commands and exactly use "launcher" with subcommands. You know, OS command namespace is not made of rubber, so dropping 1 new command into user environment is generally better than dropping a dozen (depends of course, with a dozen you get "free" shell completion for those commands).

Likewise, I'd second suggestion to make it runnable using Python's -m switch. Because dvr runs with whatever Python version is hardcoded into it, whereas with -m, user chooses which version to run, and that may be useful.

[pfalcon]

You don’t have to reverse engineer anything, you can just ask :)

Thanks for quick replies, but I'm that kind of guy who thinks that looking at the code is easier than asking stupid questions ;-). It's only when there're too many questions, some have to be asked.

I also probably should elaborate why this bunch of comments/tickets posted. I just looked at https://github.com/topics/xmeye , and got following thoughts: "There seems to be a club of folks who hack on that Sofia protocol, but each seem to duplicate work. Why would be that?" and "One of the project seems to be ahead of others in terms of project organization, let's look into that first. Uggh, still not stellar (well, just doesn't really work for me). But given all the effort put into the project already, perhaps the author would be interested in feedback on some problem spots".

Dunno how well the last part goes ;-). But I definitely would need to give myself reasons why I'd join "duplicate effort" club, and the idea that doing that aloud might help wider community (because otherwise I of course just hack up yet another crappy tool which doesn't work for anybody else but me). Sorry if that's not the case ;-).

[Vasiliy1992]

Is there a command to turn off the DVR?
Can you tell me how to safely turn off the DVR before turning off the power?