[FPP 10] fpp-live-follow - compatibility & plugin check

[github-actions]

fpp-live-follow - FPP 10 readiness

Plugin name: Animatronic Live Follow
Repo: https://github.com/pgianotto/fpp-live-follow
Maintainer: @pgianotto

📢 FPP's plugin guidelines and submission process have been updated - see the Plugin Guidelines for what's expected of a listed plugin. Adding another plugin? Start at Submit a plugin.

🔄 As part of this new process, in the lead up to each new version release we will create a GitHub issue like this one and ask that you review compatibility of your plugin with the new version and outline any new best practices for plugins. Please review this information and update your plugin accordingly.

🧪 Get your plugin ready for FPP 10

FPP 10.0 beta3 has been released - FPP 10 full release is due shortly. Please test and update your plugin against beta3, available at https://github.com/FalconChristmas/fpp/releases/tag/10.0-beta3.

✅ Compatibility

A versions[] entry already declares FPP 10 support.

Areas of concern / optimisation

• 🛑 Blocker - install-in-hook
  • runs the plugin's own install/upgrade script from a lifecycle hook (scripts/preStart.sh:8: bash "$PLUGIN_DIR/fpp_install.sh") - this re-executes the entire install (package installs, service/proxy setup, network downloads) synchronously every time the hook's guard condition trips, blocking fppd startup for however long that takes.
  • Run any genuine self-heal step detached from the hook (e.g. systemd-run or nohup ... &) instead of inline, or use FPP's actual post-os-upgrade mechanism rather than reinventing one in preStart/postStart
• 🛑 Blocker - git-network-call-in-hook
  • unbounded git network call in a lifecycle hook (scripts/preStart.sh:7: runuser -u fpp -- git -C "$PLUGIN_DIR" pull --quiet 2>/dev/null || true) - git has no built-in timeout, so a stalled connection here blocks fppd startup/shutdown indefinitely.
  • Wrap it with timeout <seconds> git ... or move it out of the hook entirely
• ⚠️ Best practice - unpinned-third-party-clone
  • clones a third-party repo with no commit pin anywhere in the file (fpp_install.sh:53: runuser -u fpp -- git clone --quiet https://github.com/pgianotto/animatronic-motion-system.git "$CORE_DIR" \) - if that cloned code is imported or executed (verify this by hand; a static check can't prove it either way), a reinstall or update silently picks up whatever is currently on that branch, not what was reviewed at submission time - the same trust problem as curl | bash, just via git.
  • Pin to a specific commit (git checkout <sha> or git reset --hard <sha>) and update that sha deliberately when you've reviewed the new code, instead of tracking a floating branch
• ⚠️ Best practice - extra-pkg-manager
  • installs a second package/version manager on top of what FPP's image already provides (fpp_install.sh:21: python3 -m pip install --quiet --break-system-packages uv) - apt/pip/npm already cover system and language packages; a bolted-on manager (uv, pipx, nvm ...) is undesirable.
  • If there's a genuine need it can't cover (e.g. a Python/Node version the OS image doesn't ship), say so explicitly via /submit instead of adding a manager silently
• ⚠️ Best practice - no-restart-flag
  • registers command type(s) via commands/descriptions.json but doesn't request an fppd restart at every lifecycle point that needs one - install: fpp_install.sh present, no restart/reboot flag; uninstall: fpp_uninstall.sh present, no restart/reboot flag.
  • This plugin's code itself looks fine for FPP 10 - structurally safe to hot-load/unload without a restart there. The flag is still needed because pluginInfo.json's versions[] serves this exact branch/build to FPP majors before 10 too, which have no plugin load/unload feature at all - those installs still need a full fppd restart to pick up install/uninstall.
  • Add source ${FPPDIR}/scripts/common; setSetting restartFlag 1 to each script listed above (creating fpp_install.sh/fpp_uninstall.sh if missing - only fpp_upgrade.sh is optional, and only needs it if you already have one); only drop it once you split off a separate FPP 10+-only branch/sha in versions[]

We know our automated checks don't always get it 100% right. Please fix whatever above does apply first - then, for anything left that doesn't apply or you think deserves an exception, comment /submit with an explanation and a maintainer will take a look.

Once you have updated your plugin, please comment /recheck on this issue and we will automatically scan your plugin and comment the new results here.

Want to sunset this plugin? Request Plugin Removal

[github-actions]

🔄 Forced recheck (remediation sweep) - re-verifying with a real clone+lint pass after a bug let status be set from a metadata-only scan without one.

fpp-live-follow - FPP 10 readiness

Plugin name: Animatronic Live Follow
Repo: https://github.com/pgianotto/fpp-live-follow
Maintainer: pgianotto (https://github.com/pgianotto) (not @-mentioned automatically)

📢 FPP's plugin guidelines and submission process have been updated - see the Plugin Guidelines for what's expected of a listed plugin. Adding another plugin? Start at Submit a plugin.

🔄 As part of this new process, in the lead up to each new version release we will create a GitHub issue like this one and ask that you review compatibility of your plugin with the new version and outline any new best practices for plugins. Please review this information and update your plugin accordingly.

🧪 Get your plugin ready for FPP 10

FPP 10.0 beta3 has been released - FPP 10 full release is due shortly. Please test and update your plugin against beta3, available at https://github.com/FalconChristmas/fpp/releases/tag/10.0-beta3.

✅ Compatibility

A versions[] entry already declares FPP 10 support.

Areas of concern / optimisation

• 🛑 Blocker - install-in-hook
  • runs the plugin's own install/upgrade script from a lifecycle hook (scripts/preStart.sh:8: bash "$PLUGIN_DIR/fpp_install.sh") - this re-executes the entire install (package installs, service/proxy setup, network downloads) synchronously every time the hook's guard condition trips, blocking fppd startup for however long that takes.
  • Run any genuine self-heal step detached from the hook (e.g. systemd-run or nohup ... &) instead of inline, or use FPP's actual post-os-upgrade mechanism rather than reinventing one in preStart/postStart
• 🛑 Blocker - git-network-call-in-hook
  • unbounded git network call in a lifecycle hook (scripts/preStart.sh:7: runuser -u fpp -- git -C "$PLUGIN_DIR" pull --quiet 2>/dev/null || true) - git has no built-in timeout, so a stalled connection here blocks fppd startup/shutdown indefinitely.
  • Wrap it with timeout <seconds> git ... or move it out of the hook entirely
• ⚠️ Best practice - unpinned-third-party-clone
  • clones a third-party repo with no commit pin anywhere in the file (fpp_install.sh:53: runuser -u fpp -- git clone --quiet https://github.com/pgianotto/animatronic-motion-system.git "$CORE_DIR" \) - if that cloned code is imported or executed (verify this by hand; a static check can't prove it either way), a reinstall or update silently picks up whatever is currently on that branch, not what was reviewed at submission time - the same trust problem as curl | bash, just via git.
  • Pin to a specific commit (git checkout <sha> or git reset --hard <sha>) and update that sha deliberately when you've reviewed the new code, instead of tracking a floating branch
• ⚠️ Best practice - extra-pkg-manager
  • installs a second package/version manager on top of what FPP's image already provides (fpp_install.sh:21: python3 -m pip install --quiet --break-system-packages uv) - apt/pip/npm already cover system and language packages; a bolted-on manager (uv, pipx, nvm ...) is undesirable.
  • If there's a genuine need it can't cover (e.g. a Python/Node version the OS image doesn't ship), say so explicitly via /submit instead of adding a manager silently
• ⚠️ Best practice - no-restart-flag
  • registers command type(s) via commands/descriptions.json but doesn't request an fppd restart at every lifecycle point that needs one - install: fpp_install.sh present, no restart/reboot flag; uninstall: fpp_uninstall.sh present, no restart/reboot flag.
  • This plugin's code itself looks fine for FPP 10 - structurally safe to hot-load/unload without a restart there. The flag is still needed because pluginInfo.json's versions[] serves this exact branch/build to FPP majors before 10 too, which have no plugin load/unload feature at all - those installs still need a full fppd restart to pick up install/uninstall.
  • Add source ${FPPDIR}/scripts/common; setSetting restartFlag 1 to each script listed above (creating fpp_install.sh/fpp_uninstall.sh if missing - only fpp_upgrade.sh is optional, and only needs it if you already have one); only drop it once you split off a separate FPP 10+-only branch/sha in versions[]

We know our automated checks don't always get it 100% right. Please fix whatever above does apply first - then, for anything left that doesn't apply or you think deserves an exception, comment /submit with an explanation and a maintainer will take a look.

Once you have updated your plugin, please comment /recheck on this issue and we will automatically scan your plugin and comment the new results here.

Want to sunset this plugin? Request Plugin Removal

[github-actions]

👋 Reminder 1 - this tracking issue has had no activity in 8 days. Comment /recheck after updating your plugin, or /submit if you disagree with the findings.

Want to sunset this plugin instead? Submit a removal request at https://falconchristmas.github.io/fpp-data/submit_remove_plugin/

[github-actions]

🔄 Auto-rechecked after detecting new commits since the last check.

fpp-live-follow - FPP 10 readiness

Plugin name: Animatronic Live Follow
Repo: https://github.com/pgianotto/fpp-live-follow
Maintainer: pgianotto (https://github.com/pgianotto) (not @-mentioned automatically)

📢 FPP's plugin guidelines and submission process have been updated - see the Plugin Guidelines for what's expected of a listed plugin. Adding another plugin? Start at Submit a plugin.

🔄 As part of this new process, in the lead up to each new version release we will create a GitHub issue like this one and ask that you review compatibility of your plugin with the new version and outline any new best practices for plugins. Please review this information and update your plugin accordingly.

🧪 Get your plugin ready for FPP 10

FPP 10.0 beta3 has been released - FPP 10 full release is due shortly. Please test and update your plugin against beta3, available at https://github.com/FalconChristmas/fpp/releases/tag/10.0-beta3.

✅ Compatibility

A versions[] entry already declares FPP 10 support.

Areas of concern / optimisation

• ⚠️ Best practice - unpinned-third-party-clone
  • clones a third-party repo with no commit pin anywhere in the file (fpp_install.sh:57: runuser -u fpp -- git clone --quiet https://github.com/pgianotto/animatronic-motion-system.git "$CORE_DIR" \) - if that cloned code is imported or executed (verify this by hand; a static check can't prove it either way), a reinstall or update silently picks up whatever is currently on that branch, not what was reviewed at submission time - the same trust problem as curl | bash, just via git.
  • Pin to a specific commit (git checkout <sha> or git reset --hard <sha>) and update that sha deliberately when you've reviewed the new code, instead of tracking a floating branch
• ⚠️ Best practice - extra-pkg-manager
  • installs a second package/version manager on top of what FPP's image already provides (fpp_install.sh:25: python3 -m pip install --quiet --break-system-packages uv) - apt/pip/npm already cover system and language packages; a bolted-on manager (uv, pipx, nvm ...) is undesirable.
  • If there's a genuine need it can't cover (e.g. a Python/Node version the OS image doesn't ship), say so explicitly via /submit instead of adding a manager silently
• ⚠️ Best practice - no-restart-flag
  • registers command type(s) via commands/descriptions.json but doesn't request an fppd restart at every lifecycle point that needs one - install: fpp_install.sh present, no restart/reboot flag; uninstall: fpp_uninstall.sh present, no restart/reboot flag.
  • This plugin's code itself looks fine for FPP 10 - structurally safe to hot-load/unload without a restart there. The flag is still needed because pluginInfo.json's versions[] serves this exact branch/build to FPP majors before 10 too, which have no plugin load/unload feature at all - those installs still need a full fppd restart to pick up install/uninstall.
  • Add source ${FPPDIR}/scripts/common; setSetting restartFlag 1 to each script listed above (creating fpp_install.sh/fpp_uninstall.sh if missing - only fpp_upgrade.sh is optional, and only needs it if you already have one); only drop it once you split off a separate FPP 10+-only branch/sha in versions[]

We know our automated checks don't always get it 100% right. Please fix whatever above does apply first - then, for anything left that doesn't apply or you think deserves an exception, comment /submit with an explanation and a maintainer will take a look.

Once you have updated your plugin, please comment /recheck on this issue and we will automatically scan your plugin and comment the new results here.

Want to sunset this plugin? Request Plugin Removal