amiaopensource/vrecord

Fixed missing init of ffmpeg-bin locations before calling decklink list.

pjotrek-b opened this issue ยท 13 comments

...but must be invited as collaborator (?) to create a pull request?

I'm using the ffmpeg binaries in /usr/local/opt/ffmpegdecklink/bin on my setups.
It seems that if those are the primary/preferred executables, the shell variables were not initialized when trying to list the decklink devices.

I've added a call to _gather_ffmpeg_vars in _get_decklink_inputs to fix that.

I'd also like to propose adding /opt/ffmpeg/decklink/bin to vrecord's search paths?
That would be more unix-compliant (/opt), and allow multiple ffmpeg-versions in parallel (as subfolders of /opt/ffmpeg).

Maybe even introduce a plain "PATH"-like variable, replacing the if-then-elif-fi blocks?

Anyways: So I'd like to provide a patch (pull-request). ๐Ÿ˜ƒ

@pjotrek-b - you should be able to file a PR, was it not allowing you?

@privatezero : indeed I had the PR already open and when I clicked on Create - it said I don't have sufficient rights (or so).
Wasn't sure, because haven't done a PR in a while, so I thought I'd report back.

Just tried again right now.
Github says:

"Pull request creation failed. Validation failed: must be a collaborator"

Very strange! That certainly isn't something we've intentionally set, and we've recently has PRs from people who are not 'collaborators', so not sure what the underlying issue is beyond it probably being some function of Github that I haven't noticed yet.

If you still are having issues with creating a PR and this is ready to go, let me know if you'd like me to initiate a PR for you as it looks like I can (although won't know until I try I guess).

@privatezero : sorry for the delay. Was out of office.

I'll read up on github what that thing is with "collaborators" - and how to configure it, and get back here when I know more.

Getting back to this.

So, I think I know where to add "collaborators" now ๐Ÿ˜„
On your repo select "Settings > Collaborators > Add people":
github_collaborators2

(Taken from the official github docs on "inviting collaborators to a personal repository")

@pjotrek-b this is still very confusing for me about what is blocking you as our settings definitely don't limit PRs only to collaborators. I just confirmed this myself with a test PR from a dummy account .

Could you maybe upload a screenshot of the error screen it is giving you so I can maybe have some clues to try to hunt down what could possibly be blocking in the GitHub documentation?

Thanks for circling back to this by the way - I'd love to get this merged as part of some broader rethinking of how vrecord searches for dependency paths. I've been working on some very basic install helper scrips for people who would like to build dependencies that way, and I see that having more path flexibility would be very helpful for your vrecordx build system as well!

@privatezero: I've taken a look at your "install helper scripts" - and unless I'm overlooking anything, you can use the Makefiles provided by vrecordX for the very same thing.

I haven't (on purpose) changed anything (vitally) in the vrecord script itself (yet), but provided a reproducible Makefile-based installation package (tested and used productively on Xubuntu 20.04/22.04).

Github still won't "allow" me to make a PR:
github-pull_request-must_be_collaborator-20240202

Here's what the form looks like before clicking the green "create PR" button:
github-pull_request-must_be_collaborator-20240202a

@pjotrek-b for makefiles vs helper scripts, I think both could be potentially useful for different users of vrecord depending on degrees of how dependent they want to be on using linuxbrew for their installs.

My thoughts were to do some heavy updating of the install docs soon to point people towards your make based package as an excellent install option but to have some helper scripts as a quick solution for someone who might want to rely on linuxbrew installs but was having issues with a silly gtkdialog build error or something.

Thanks for posting that screenshot - I've been searching around and the suggestions I've found point to it possibly being an overzealous spam filter in Github. I've contacted their support to see if we can get any information about how that might be happening and how it could be rectified.

Thanks for your patience with this! We of course would very much value your contributions!

@privatezero: You'll let me know whan I shall re-issue any PR-request ๐Ÿ˜„ ?

@pjotrek-b yes - will do! I don't actually have terribly high hopes for support getting back to us soon, so we ultimately can go with plan B of temporarily making you a 'collaborator' if we need to.

I'd much rather figure out if there is a more solid fix though, as if you are having this problem it suggests it might be an issue for others as well!