#3 various usability details

[Bela Lubkin]

Hi!

Is this thing on? I see sporadic tickets & patches over the years, so perhaps...

Some mishaps:

• I had a great deal of trouble getting the archive features to work, until I realized that all three options were required. On further thought this is probably my fault for using '-c /dev/null', the 'how often' and 'how many' options would probably have been set to some sort of sane defaults without my override; but it still feels like there's something amiss there.

• for my purpose, I wanted '-M' to mean 'take this many images, then stop' -- not 'take images forever, and keep cleaning up the tail so there are never more than this many'. An option for 'stop at this many images' (and maybe another for 'run for no more than this much total time') would be nice.

• I used '-f /dev/null' to discard unwanted stdout, then had to repair my system's /dev/null device node! Because I was running as root because my user account wasn't properly setup to access /dev/video0. So again, my fault, but some care could be taken. Perhaps you could stat() before removing the target file, and balk if it exists and is not a regular file.

• Using this to try to troubleshoot a webcam which will take stills, but anything that tries to take video from it hangs. So I wanted to see what would happen if I took images rapid-fire, like 15FPS with '-L 66667'. And wanted to archive each frame. The best I could do was '%S' which would then overwrite the same file however many times per second (not 15, since about 1-in-4 runs took several seconds for no apparent reason). Please add a % decoder which emits 'frame sequence number in specified format', like '%03i', using whatever letter is available outside of strftime()'s grasp. (fiJKLNoQqv, according to Linux man page in front of me; the used letters are a strict superset of what Open Group prescribes.)

If this is 'on' and you want be to break this up into separate 'actionable tickets', tell me.

[Ludovic Rousseau]

I am the latest maintainer. But I have not made any changes since 2016.
Feel free to provide patches.

I am not admin of this project. So I don't think I can add you as maintainer.

[gmaniac]

No bugs. At all.

• There's simply no use case to provide /dev/null as config file.
• Make a shell script to loop that number of times.
• No default advertised in help/man page: there's none.
• If you want to suppress stdout either use daemon mode or redirect stdout pipe to /dev/null.
• Not reaching 15fps is expected behaviour.
• "Slowliness" of your system is not within the scope of vgrabbj.

Feel free to submit patches, if you whish to enhance vgrabbj.

[Bela Lubkin]

• /dev/null: your product is a sharp knife, and I understand that, but I still question the decision to ship it with no handle and all edges sharpened
• shell script to loop: the /dev/video0 on this system takes a significant amount of time to open; a shell script which brings up the utility to capture one frame, exits, and does it again, will be still vastly slower than doing it inside the utility
• no default in man page: then the man page should clearly state 'you must set all 3 of these for archiving to work'
• 'slowness' not in scope: as I said, I was attempting to use it as a troubleshooting tool. It did not succeed in that regard; I get that it's not intended as such a tool, but perhaps you could see that it might nevertheless be useful in that way and could possibly be enhanced in that direction. I'm not going to patch it as I can find a better tool for the job elsewhere. I still think it's clumsy that the program offers a microsecond precision timer, but cannot write files with distinct names more frequently than once a second

[Bela Lubkin]

oh, and 'no bugs': I did not click 'open a bug', I clicked 'open a ticket'. It's true that the issue tracker conforms the address to /bugs/%d but this, like many items that might come through an 'issues' interface, was more of a set of enhancement requests.