Wrong preconfigured ffmpeg path

[foosel]

Copying from OctoPrint/OctoPrint#3821 by @JohnOCFII

What were you doing?

I started with a new installation of OctoPi 0.18.0 (the RC). I upgraded the default 1.4.2 OctoPrint to 1.5.0rc1. I then performed a restore of OctoPrint 1.5.0rc1 from my previous installation on an older nightly build of OctoPi 0.18.

As I reviewed configuration settings, I noticed in Settings --> Webcam & Timelapse there is a setting for Path to FFMPEG. This field is pre-populated with /usr/bin/avconv. That item does not exist on this fresh installation.

What did you expect to happen?

I expected either avconv to exist at the specified path, or that the field would be pre-populated with /usr/bin/ffmpeg

What happened instead?

Field needed to be manually updated to /usr/bin/ffmpeg

Did the same happen when running OctoPrint in safe mode?

n/a

Version of OctoPrint

OctoPrint 1.5.0rc1

Operating System running OctoPrint

OctoPi 0.18.0 (RC)

Printer model & used firmware incl. version

Prusa MK3S w/MMU2S

Browser and version of browser, operating system running browser

Safari Version 14.0.1 (15610.2.11.51.10, 15610)
macOS Catalina 10.15.7

Link to octoprint.log

https://gist.github.com/JohnOCFII/af96d79e4768bb90f0dcf9e9f958b481

Link to contents of terminal tab or serial.log

n/a

Link to contents of Javascript console in the browser

n/a

Screenshot(s)/video(s) showing the problem:

I have read the FAQ.

---

TLDR

The preconfigured ffmpeg path is wrong on OctoPi 0.18.0rc1.

[cp2004]

OctoPi/src/modules/octopi/filesystem/home/pi/.octoprint/config.yaml

Line 4 in e2f38c7

ffmpeg: /usr/bin/ffmpeg

Looks like the preconfigured path is right, maybe something in their configuration that has messed it up.

[foosel]

Yeah, just saw that this was supposedly fixed in #600... Will flash an 0.18.0rc1 in a couple of minutes for 1.5.0rc2 update testing anyhow and will crosscheck then.

[JohnOCFII]

Interesting. If the default image has it correct, then my issue was probably related to my upgrade path -- which looked like this:

1. Upgraded existing environment (OctoPi nightly from July 2020) and production OctoPrint to OctoPrint RC 1.5.0rc1
2. Ran a test print but had a variety of timelapse issues -- decided I should start clean before submitting any tickets against rc1
3. Created backup of existing OctoPrint 1.5.0rc1 environment using OctoPrint tool
4. Re-imaged with OctoPi rc1
5. Attempted to restore my OctoPrint backup - restore failed as I could not restore since the backup from was 1.5.0rc1 which was newer than the default (1.4.2?) OctoPrint on OctoPi RC
6. Upgraded my new image to OctoPrint 1.5.0rc1
7. Performed restore of my OctoPrint 1.5.0rc1 environment
8. Started to review configuration - saw the above issue with avconf and opened ticket

[cp2004]

existing environment (OctoPi nightly from July 2020)
Did timelapse work properly until 1.5.0rc?

Do you still have a copy of the backup, from one that worked? The only way I can see this occurring is something misconfigured that got backed up and carried forward by the backup. If you unzip the backup, config.yaml should be there and you can take a look inside, see what is configured there. Don't post it here unless you have removed the identifying sections (access control salts, API keys etc.)

[foosel]

Aaaaah... a backup, of course! Yeah, ok, the backup was the issue, that still contained the old path. Can also confirm that OctoPi 0.18.0rc1 contains the right path:

This raises the question though how to proceed with issues like this going forward. It's an environmental specific setting, so nothing that OctoPrint can actually detect or take care of. But it also causes trouble for people who'll migrate to 0.18 through the backup/restore route.

[foosel]

Closing as there's no immediate todo to be created from this and the image per se is fine, however, the whole problem is something to think about.

I'm wondering if it would make sense to extend the config overlay mechanism in OctoPrint going forward, and add an environment overlay config in OctoPi that sets settings like this, so they won't land in a backup. Will have to brainstorm about this a bit. Until then an FAQ entry will probably be a good idea, and a small heads-up in the release notes & announcement of OctoPi 0.18.

[cp2004]

I'm surprised that this has shown up now, rather than in the migration from 0.16 > 0.17, when this was actually changed (maybe it did, I haven't looked). Not something that has caused many people a problem I guess?

[JohnOCFII]

Do you still have a copy of the backup, from one that worked? The only way I can see this occurring is something misconfigured that got backed up and carried forward by the backup.

Here's the webcam section of config.yaml from the backup:

webcam:
    ffmpeg: /usr/bin/avconv
    ffmpegVideoCodec: libx264
    snapshot: http://127.0.0.1:8080/?action=snapshot
    stream: /webcam/?action=stream
    streamRatio: '4:3'
    timelapse:
        fps: 25
        options:
            minDelay: 5.0
            retractionZHop: 0.6
        postRoll: 1
        type: zchange

And yes, time lapses were working before upgrading to OctoPrint 1.5.0rc1. I was using an OctoPi Daily from July or August, as well as the release version of OctoPrint at the time (after having gone through many of the previous OctoPrint RC release cycles)