Usage examples

[nishant2019]

Can you give an example to use your code ?

[alexshpilkin]

Thanks for your interest in the project and sorry for the late reply.

Do you mean the command-line tools or the library code?

For the command-line tools, try

dvr -h HOST time

replacing HOST with the hostname or IP address of your DVR. You can get a list of subcommands to try in addition to time by listing the files in the dvrip/cmd subfolder of the source code; currently the available commands are cat, discover, find, info, log, reboot, and time.

For using the code as a library, you can look at the source code for the command-line tools. It should be quite readable if you ignore the error handling. Here's an even simpler example to get you started:

from socket import AF_INET, SOCK_STREAM, socket
from dvrip import DVRIP_PORT
from dvrip.io import DVRIPClient

HOST = ...          # FIXME replace with hostname of the DVR
USERNAME = 'admin'  # FIXME replace with actual credentials
PASSWORD = ''       # FIXME replace with actual credentials

sock = socket(AF_INET, SOCK_STREAM)  # Create the socket we'll be using for communication
conn = DVRIPClient(sock)  # Create a client connection using that socket
conn.connect((HOST, DVRIP_PORT), USERNAME, PASSWORD)  # Connect and authenticate ourselves to the DVR
print(conn.time().isoformat())  # Print DVR date and time in ISO format
conn.logout()  # Deauthenticate
sock.close()  # Disconnect

Does this answer your question?

[pfalcon]

I'd say that README definitely could use some love. Taking as an example a commit like 5e30a72 (3 levels of fallbacks to getting an app version!!1), even if half of that time and lines were put into sprinkling life into the README, that would make the project much better.

[pfalcon]

dvr -h HOST time

Btw, why do you pass "HOST" parameter to the help (-h) option? ;-) (Example of "Help Plz" support questions which will never subside.)

[alexshpilkin]

Btw, why do you pass "HOST" parameter to the help (-h) option? ;-) (Example of "Help Plz" support questions which will never subside.)

Because I didn’t think about it, it seems. I do prefer that option descriptions exist on a separate manual page and not be embedded in program code, but in this particular case I just didn’t realize the clash.

I'd say that README definitely could use some love. Taking as an example a commit like 5e30a72 (3 levels of fallbacks to getting an app version!!1), even if half of that time and lines were put into sprinkling life into the README, that would make the project much better.

Well, yes, but writing is painful, so I haven’t gotten around to it. PRs welcome! (It’s not three levels of fallbacks, it’s one option for built distributions and another for source checkouts... with a fallback, yes, I did get a bit carried away).

[pfalcon]

Because I didn’t think about it, it seems.

I'd suggest to reserve "-h" for help. "-a" (for "address"), "-s" (for "server") would be good alternatives. And fairly speaking, the hostname shouldn't necessarily be an option, can be a positional param (unless the intention is to support passing it as an environment var, which seems to be the case, then option is a better way to deal with it indeed).

Well, yes, but writing is painful, so I haven’t gotten around to it.

Ack. That's why I gave an example of writing "too much code" (from outsider's PoV), even if 1 line doc = 10 lines code, could make a beneficial effort exchange.

PRs welcome!

I'm afraid if outsider would start writing docs from scratch, result may be much worse than if one wrote some code-drop (e.g. using spaces instead of tabs of indentation ;-), re: #5). See #7 as an example - I thought one would use individual dvr-info, dvr-discover, etc. tools, but turns out, that wasn't an intention.

Anyway, thanks for your project, and please treat these comments just as votes from various people regarding priorities which would be helpful for the project ;-).