VCS 1.13.4 released
Prompted by a couple reports, here's a new bugfix release of VCS. It most importantly fixes an incompatibility with Bash 5.0 which made the script put all the captures in a single row.
A couple minor bugs are also fixed, where using mawk would produce some errors and print the wrong file sizes, and the evasion offsets (which are used to avoid blank screengrabs) weren't really being used.
See the full changelog for more details.
- vcs 1.13.4
- vcs-1.13.4.gz (script only)
or
vcs-1.13.4.tar.gz (script, sample configuration, manpage and profiles) - deb, rpm, PKGBUILD & xz
- as usual at p.outlyer.net/vcs
I appreciate it, Thank you so much!!
I was looking for a similar tool for some time.
I had to modify it a bit according to my needs.
It was easy with almost zero BASH knowledge as the script is very well-organized.
Thank you, tip granted!
Thank you! I did my best to keep it organized and documented since it's a fairly complex and big script, I'm glad that was useful for someone else. If you think your modifications can be of use to others I'm always open to suggestions and patches.
Hello Toni,
sorry i just saw your reply now. 🙁
I modified script behavior if output file exists.
I use another bash script to invoke VCS for every video file on a folder recursively and for me it was handy to add an option to keep already existing output to reduce overall runtime.
I send you the modified script via e-mail and you can decide if it is useful or not.
Also i failed to find out where to add jpeg quality settings to reduce jpeg output sheet size. I think this feature would be useful as well.
Thank you again for this great – and free – tool! 🙂
Thank your for your suggestion and submission.
As for JPEG quality, while there's no specific command-line option to set it, it can be set through command-line overrides or configuration files (see https://p.outlyer.net/vcs/docs/conf_files)
To set it from the command-line use, e.g.:
$ vcs -O quality=85 …
Wow, i did not notice this feature. Thank you for quick response! :bow:
Excellent! 🙂
I am happy again, that I now can continue using the -S option, and that the Footer has finally returned.
However, some new thing seems to have entered the realm of vcs: -T pc3
I replaced the line "if [[ 8 = "$(tput -T pc3 colors)" ]]; then" with the line "if [[ 8 = "$(tput colors)" ]]; then" and colors returned. Before the change I always got the error: "tput: unknown terminal "pc3""
The system I run the vcs script on is old, very old, so it has no knowledge of updated Terminal versions, if that might be the case.
The code though, seems to me that you only need to compare the number 8 with how many colors the Terminal actually supports, and in my case that's 8. What the -T option has got to do with anything, I am not sure. Something more modern perhaps? Or has it something to do with your system? Personally I could live without the colors. They are not necessary for the functionality of the application.
Anyway, great work! 🙂
Thank you for your input. Getting tput to produce consistent output across different OSes is harder than I'd like and it involved some hair pulling when dealing with BSDs, so that may be the source of the pc3 type, I honestly can't remember right now.
Nonetheless, I'm taking note of this for further testing.
Best Regards.
I used vcs-1.13.2 for a long time, but after my system upgrade the media info on the upper right side shifted out from the contact-sheet.
I upgraded to vcs-1.13.4 but it would not run as a script starting from my filebrowser (this is handy to right-click a file, start vcs and get an easy contactsheet for the file)
As I found out the problem is the tput detection:
"stty: 'standard input': Inappropriate ioctl for device"
"tput: No value for $TERM and no -T specified"
I went back to the old detection, pasted/replaced it into the new script and now it is working again:
I thought I let you know. Perhaps you can improve your new detection to run without exiting if no Terminal is found.
It definitely can be improved. As I replied above I ended up with some solution that seemed to work across systems at the time but it wasn't that solid, obviously.
Thank you for your feedback, I'm taking note to refine it further.
It seems the version 1.13.4 jumps over the function that was there in earlier versions (if memory serves me), the function that corrected timing for "decimal seconds". If a thumbnail landed on, say 05:24.100, the script corrected that to 05:25.00. But now it is left as an exercise to the reader to figure out what that 05:24.100 means. 🙂
Not a big problem, it just looks a little weird with three digits instead of the "normal" two. I put that in quotes since nothing in 2020 so far has been "normal".
Live well and prosper, and breathe carefully when you're out there. 😉
I'm not sure what you mean, I can't remember having such correction, timestamps are explicitly printed with two decimals. I'm getting two decimals on my system, maybe it is some weird interaction with a newer version of some package?
There was no rounding either as you seem to imply, the closest I can think of is when using MPlayer as capturer seeking doesn't have such precision. You can force using MPlayer with the -M switch if you prefer that behaviour.
output file is in 64b bit depth. how can I set it to lower bit such as 24?
I've haven't encountered such problem yet, and it sounds fairly weird.
You may try editing the script and adding
-depth 8to the final bigconvertcommand (on line 4135 in version 1.13.4) and see if that does the trick.