Persistence of improper settings

[privatezero]

With the current method of storing config variables (such as FFMPEG_BIN) it appears to be possible for incorrect values to get stored and used for a while. (Such as the wrong version of FFmpeg). Probably should think about a way to test for this!

[retokromer]

I second this… I was going to open a similar issue.

[dericed]

@privatezero, can you retest with main

[dericed]

@privatezero what should cause the VRECORD_VARS_FILE to be regenerated? @retokromer could you describe the scenario you mentioned. IIUC, this issue would happen if you had an ffmpeg installed that is match by one of the else conditions in https://github.com/amiaopensource/vrecord/blob/3adb39cf79c2778967596928607c3b12bbfc8248/vrecord#L206-L228, then you install the ffmpeg referenced in the primary if. And since the VRECORD_VARS_FILE is already written, the condition is not rerun so you stay on the ffmpeg of the else.

[retokromer]

@dericed It was a while ago and I don’t remember the exact details from the top of my head, but I will try to find it in our logs.

[dericed]

will close. @retokromer, please reopen you can suggest how to recreate.

[privatezero]

Re-opening as this is still an issue, I just haven't thought of a good way to handle it yet (beyond something very blunt like storing a counter and rechecking the variables every 5 times vrecord runs or something like that).

This recently cropped up on my end (linux) again where the version of ffplay-dl stored in the vrecord variables file had developed conflicts with other libraries. Vrecord would have run as expected if it was able to rescan variables, but it was stuck on the ffplay path value stored and wouldn't fix itself without deleting the config file. Easy to fix for me, but probably not obvious to a casual user.

I think that having these config values essentially become hard coded with no rescans is a weakness we should think about addressing.