GNOME Bugzilla – Bug 581789
An error message should be shown when required codecs are not installed.
Last modified: 2011-08-29 10:12:28 UTC
Please describe the problem: When establishing or receiving a call, if the "gstreamer bad" codecs are not installed, the connection cannot be established. On the local side, the status bar of the call window shows "disconnected". On the remote side, the user never gets the call or an answer (depending on who established the call). No other feedback or error message is presented to the user. Steps to reproduce: 1. Be sure not to have the "gstreamer bad" codecs installed. 2. Call one of your contacts or receive a call. Actual results: The status bar of the call window shows "disconnected". The remote contact never receives the call or the answer. Expected results: An error message should be shown, explaining why the connection can't be established. Does this happen every time? Yes Other information:
The same kind of problem occurs if no H263 decoder is installed. It is impossible to have a video conversation but no error message is shown.
Even better, it should trigger PackageKit (or what ever the distros use) to download the required codecs (à la Totem).
Tester says that codec discovery is implemented in farsight, but right now, Empathy can't really access that info. I guess that we will have to wait for modifications in farsight before being able to fix this bug.
Is there a bug reported against farsight so it can be tracked?
Farsight should implement the GStreamer missing codecs messages. That will require some re-factoring of the codec discovery stuff... Well, even better, a complete rewrite. It is on the long term todo list.
The error message should link to the doc once the section has been written (bug #599165).
Currently 17 Empathy tickets are set as GNOME 2.30 blockers, hence mass-removing. Guillaume: Please use normal Target Milestones instead. If you really think that this specific issue here is a 2.30 blocker then please restore the GNOME target and set corresponding importance values.
Created attachment 146993 [details] [review] http://git.collabora.co.uk/?p=user/cassidy/empathy;a=shortlog;h=refs/heads/codec-581789 libempathy/empathy-call-handler.c | 1 + libempathy/empathy-tp-call.c | 58 ++++++++++++++++ src/empathy-call-window.c | 136 +++++++++++++++++++++++++++++++++++++ src/empathy-call-window.ui | 13 +++- 4 files changed, 206 insertions(+), 2 deletions(-)
Created attachment 146995 [details] screenshot
Note that this currently doesn't work in all the cases because of limitations in Jingle and telepathy-farsight but the code should work once they'll be improved. See http://bugs.freedesktop.org/show_bug.cgi?id=24935 for details.
Review of attachment 146993 [details] [review]: +g_object_get(priv->handler,"tp-call",&call,NULL); +g_assert(call!=NULL); that should return if call == NULL, not assert empathy_call_window_{audio,video}_stream_error are basically the same apart from the icon and the string, maybe move the common code to display_error ? both these functions throw away the message that was part of the signal, they probably shouldn't.. both functions also ignore the error if they don't understand the reason, they probably should still display something even if it's just unknown error (raw msg) ?.. So at least the user can see something went wrong + /* TODO: support more error */ *more errorS
(In reply to comment #11) > both these functions throw away the message that was part of the signal, they > probably shouldn't.. That message is not translated, so it probably shouldn't be in the UI.
(In reply to comment #11) > Review of attachment 146993 [details] [review]: > > +g_object_get(priv->handler,"tp-call",&call,NULL); > +g_assert(call!=NULL); > > that should return if call == NULL, not assert fixed. > empathy_call_window_{audio,video}_stream_error are basically the same apart > from the icon and the string, > maybe move the common code to display_error ? done. > both these functions throw away the message that was part of the signal, they > probably shouldn't.. > > both functions also ignore the error if they don't understand the reason, they > probably should still display something > even if it's just unknown error (raw msg) ?.. So at least the user can see > something went wrong Agreed. Let's use the error message for now. > + /* TODO: support more error */ > *more errorS fixed
Merged in master. This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.