Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • gstreamer gstreamer
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 930
    • Issues 930
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 444
    • Merge requests 444
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Container Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • GStreamerGStreamer
  • gstreamergstreamer
  • Issues
  • #22
Closed
Open
Issue created Apr 17, 2011 by Bugzilla Migration User@bugzilla-migration

Better handling of blacklisted plugins: re-scan occasionally, store reason for blacklisting

Submitted by Tim Müller @tpm

Link to original bug (#648010)

Description

+++ This bug was initially created as a clone of Bug 503675 +++

<__tim> nekohayo, your registry file is full of BLACKLISTED. The problem isn't
registry file writing or parsing, but that plugins get blacklisted for some
reason
<nekohayo> When does blacklisting occur?
<__tim> nekohayo, when an error occurs when loading the plugin, usually a
missing symbol or library or somesuch
<nekohayo> videomixer was indeed on the gst-inspect blacklist

<__tim> are you sometimes downgrading versions of core or gst-plugins-base?
<nekohayo> no, not that I know of. Downgrading was downright impossible in
ubuntu, and I haven't used downgrade in fedora yet
<__tim> GStreamer installed in different prefixes?
<nekohayo> currently this machine is using the official gstreamer packages from
fedora + rpmfusion

<nekohayo> I'm wondering why those blacklisted plugins are never "re-scanned"
by gstreamer
<__tim> that's a fair question I guess. But when would one rescan them? You
don't want to do it every time. So once an hour? once a day? once a week?

<nekohayo> what if they were rescanned when apps try to access them? like when
pitivi tries to use videomixer (on top of your approach of rescanning
periodically maybe)
<__tim> interesting, maybe one could do something clever there
<__tim> ideally we'd store the reason for the blacklisting as well
<ocrete> arent they rechecked if the file changes already ?
<thaytan> the plugins are rescanned if they change
<__tim> but if they don't change ...
<thaytan> but if they failed because some underlying lib was broken and then
fixed, that's not detected
<__tim> right
<ocrete> hmm interesting point
<thaytan> storing the reason for the blacklisting is probably hard
<ocrete> also check if ld.so.cache has changed ?
<thaytan> since it's usually just 'failed to g_module_open() because of an
unresolved symbol'
<ocrete> and ignore blacklists if ld.so.cache has changed (and rescan)
<__tim> thaytan, it doesn't mention the symbol? I think it does..
<ds> if the so fails to load, there isn't much overhead trying to load every
time
<ocrete> that said, doesnt help if one use using LD_LIBRARY_PATH
<thaytan> ds: except for forking the scanner process to re-check an otherwise
clean registry
<ds> oooh, maybe recheck blacklisted plugins whenever the scanner is run, but
not run the scanner just for blacklisted plugins. Although, also mark potential
crasher blacklist plugins

See also

  • http://bugs.debian.org/867574
Assignee
Assign to
Time tracking