After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 592167 - Missing plugin handling not implemented correctly
Missing plugin handling not implemented correctly
Status: RESOLVED INVALID
Product: totem
Classification: Core
Component: GStreamer backend
2.27.x
Other Linux
: Normal normal
: ---
Assigned To: Maintainer alias for GStreamer component of Totem
Maintainer alias for GStreamer component of Totem
Depends on:
Blocks:
 
 
Reported: 2009-08-18 06:19 UTC by Sebastian Dröge (slomo)
Modified: 2009-08-18 08:33 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Sebastian Dröge (slomo) 2009-08-18 06:19:15 UTC
Hi,
the missing plugin handling in totem's gstreamer backend is not correctly implemented.

Currently it works as follows:
a) Missing plugin message(s) arrive and are queued
b) An error message is expected (of type CORE/MISSING_PLUGIN or STREAM/CODEC_NOT_FOUND)

And then the plugin installation is started.

The problem here is, that you can't expect an *error* message after the missing plugin message(s). There could as well be a warning message (of one of the above mentioned types).

See bug #591677 at the bottom for an example.


Also there's an assumption in bvw_error_from_gst_error(), that CORE/MISSING_PLUGIN will always mean that a single plugin is missing but there could be many missing plugin messages before that.
Comment 1 Tim-Philipp Müller 2009-08-18 07:51:18 UTC
> the missing plugin handling in totem's gstreamer backend is not correctly
> implemented.
> 
> Currently it works as follows:
> a) Missing plugin message(s) arrive and are queued
> b) An error message is expected (of type CORE/MISSING_PLUGIN or
> STREAM/CODEC_NOT_FOUND)
> 
> And then the plugin installation is started.
> 
> The problem here is, that you can't expect an *error* message after the missing
> plugin message(s). There could as well be a warning message (of one of the
> above mentioned types).

Not quite. The way it currently works / should work is:

 - if there is an error (with the right code),
   check for missing plugin messages, try to
   install and retry playback if anything was
   installed.

 - when we're prerolled, check for missing
   plugin messages and show a warning if the
   missing plugins could not be installed (and
   then blacklist that type). Grep for
   bvw_check_missing_plugins_on_preroll()

What exactly do you think is wrong with this?

I am not sure if handling warning messages is needed, or adds anything useful.

 
> Also there's an assumption in bvw_error_from_gst_error(), that
> CORE/MISSING_PLUGIN will always mean that a single plugin is
> missing but there could be many missing plugin messages before that.

Well, at least in the past this error code was only used when something else than a decoder was missing, and that would typically only be a source element. Of course theoretically more could be missing, esp. if your installation is busted and you're missing converters, scalers, volume, etc. Mostly a let's-cross-that-bridge-when-we-get-to-it issue IMHO.
Comment 2 Sebastian Dröge (slomo) 2009-08-18 08:33:37 UTC
(In reply to comment #1)
> > the missing plugin handling in totem's gstreamer backend is not correctly
> > implemented.
> > 
> > Currently it works as follows:
> > a) Missing plugin message(s) arrive and are queued
> > b) An error message is expected (of type CORE/MISSING_PLUGIN or
> > STREAM/CODEC_NOT_FOUND)
> > 
> > And then the plugin installation is started.
> > 
> > The problem here is, that you can't expect an *error* message after the missing
> > plugin message(s). There could as well be a warning message (of one of the
> > above mentioned types).
> 
> Not quite. The way it currently works / should work is:
> 
>  - if there is an error (with the right code),
>    check for missing plugin messages, try to
>    install and retry playback if anything was
>    installed.
> 
>  - when we're prerolled, check for missing
>    plugin messages and show a warning if the
>    missing plugins could not be installed (and
>    then blacklist that type). Grep for
>    bvw_check_missing_plugins_on_preroll()
> 
> What exactly do you think is wrong with this?
> 
> I am not sure if handling warning messages is needed, or adds anything useful.

Then the question is, what uridecodebin should post after the missing plugin message. Should it post an error message if it's not pre-rolled yet and a warning message if it pre-rolled? How can it detect if it's pre-rolled btw?
 
> > Also there's an assumption in bvw_error_from_gst_error(), that
> > CORE/MISSING_PLUGIN will always mean that a single plugin is
> > missing but there could be many missing plugin messages before that.
> 
> Well, at least in the past this error code was only used when something else
> than a decoder was missing, and that would typically only be a source element.
> Of course theoretically more could be missing, esp. if your installation is
> busted and you're missing converters, scalers, volume, etc. Mostly a
> let's-cross-that-bridge-when-we-get-to-it issue IMHO.

Ok, then uridecodebin should post a CODEC_NOT_FOUND message usually and a MISSING_PLUGIN if the source plugin is missing?



I guess then there was just a misunderstanding on my side and this bug can be closed and we can continue in bug #591677.