*** Bug 523133 has been marked as a duplicate of this bug. ***

I'm also having this problem, as well as another video problems. When I open Cheese (version 2.22.1 on Arch Linux), it won't load the videos:


[bladesonfire@alai ~]$ cheese

** (cheese:16136): WARNING **: could not load /home/bladesonfire/.gnome2/cheese/media/0003.ogg (video/x-theora+ogg)


The same message appears when creating a video.

*** Bug 524811 has been marked as a duplicate of this bug. ***

ok,

cheese-webcam.c:948
===================
void
cheese_webcam_stop_video_recording (CheeseWebcam *webcam)
{
  CheeseWebcamPrivate* priv = CHEESE_WEBCAM_GET_PRIVATE (webcam);

  /* Send EOS message down the pipeline by stopping video and audio source*/
  gst_element_set_state (priv->video_source, GST_STATE_NULL);
  gst_element_set_locked_state (priv->video_source, TRUE);
  gst_element_set_state (priv->audio_source, GST_STATE_NULL);
  gst_element_set_locked_state (priv->audio_source, TRUE);
}

fails because priv->video_source and priv->audio_source is NULL. you can get that result by either adding and if(priv->video_source == NULL) ... or with gdb.

those two variables are already NULL in

cheese-webcam.c:219
===================
static void
cheese_webcam_bus_message_cb (GstBus *bus, GstMessage *message, CheeseWebcam *webcam)
{
  CheeseWebcamPrivate* priv = CHEESE_WEBCAM_GET_PRIVATE (webcam);

  if (GST_MESSAGE_TYPE(message) == GST_MESSAGE_EOS)
  {
    g_signal_emit (webcam, webcam_signals [VIDEO_SAVED], 0);

    gst_element_set_locked_state (priv->video_source, FALSE);
    gst_element_set_locked_state (priv->audio_source, FALSE);
    cheese_webcam_change_sink (webcam, priv->video_display_bin,
                               priv->photo_save_bin, priv->video_save_bin);
    priv->is_recording = FALSE;
  }
}  

i tried to investigate every priv->video_source available:
------------------------
cheese-webcam.c:632
  priv->video_source = gst_bin_get_by_name (GST_BIN (priv->webcam_source_bin), "video_source");

in static gboolean cheese_webcam_create_webcam_source_bin (CheeseWebcam *webcam);

here priv->video_source gets created. it is NOT NULL.
------------------------
next step is
cheese-webcam.c:228
  gst_element_set_locked_state (priv->video_source, FALSE);

in static void cheese_webcam_bus_message_cb (GstBus *bus, GstMessage *message, CheeseWebcam *webcam);

priv->video_source is NULL, from the first callback to the last.
------------------------
next step is
cheese-webcam.c:954
  gst_element_set_state (priv->video_source, GST_STATE_NULL);
  gst_element_set_locked_state (priv->video_source, TRUE);

in void cheese_webcam_stop_video_recording (CheeseWebcam *webcam);

priv->video_source is NULL when the video recording gets stopped (does not get called before)


i suppose priv->audio_source behaves similar to video_source

While looking into the similar 
https://bugzilla.redhat.com/show_bug.cgi?id=443499
I was playing with this without a webcam plugged in and noticed that
in this case, priv->video_source is never set, since we are hitting
the fallback code in cheese_webcam_create_webcam_source_bin.

matthias, i hope i fixed that with revision 664
( http://svn.gnome.org/viewvc/cheese?view=revision&revision=664 )

Yes, that looks like the right fix - of course, it doesn't help for video recording running into a deadlock inside gstreamer...

somehow this happens just on certain computers with cheese installed.

> Yes, that looks like the right fix - of course, it doesn't help for video
> recording running into a deadlock inside gstreamer...

What/where is the deadlock? Do you have a stack trace?


FWIW, it would probably better to bump the GStreamer requirements to 0.10.16 and use the gst_element_send_event() method described in

http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gstreamer-libs/html/GstBaseSrc.html

in the 'Controlled shutdown of live sources in applications' section.

(Make sure you haven't got any pads blocked when you do that though, but that applies to the old method as well.).

Here is what I am seeing when I press the "Stop recording" button:

(gdb) bt

+ Trace 195891

And it is stuck there

> Here is what I am seeing when I press the "Stop recording" button:

Any chance you could you do one with 'thread apply all bt'?

Created attachment 109778 [details]
t a a bt

Tim, any further info I can provide ?

*** Bug 534616 has been marked as a duplicate of this bug. ***

*** Bug 539435 has been marked as a duplicate of this bug. ***

*** Bug 539498 has been marked as a duplicate of this bug. ***

I still see this bug in svn.

Is there any progress on that?

we werent able to find it yet. it also seems to happen just on some gstreamer installations and on some cameras

Details about my system:

Ubuntu hardy.
gstreamer0.10- 0.10.18-3
Acer crystal eye (uvcvideo latest svn)

camera used to hang just after few minutes with ubuntu drivers
I installed svn and this bug dissapered.

Also running latest -git of kernel.

This bug (no video restart) happens regardless of uvcvideo version

I am going to update to ubuntu 8.10 (want to have latest packages, and in my opinion alphas/betas/releases are all the same, all have bugs :-) )

Same happening here. Taking a picture works well, but Cheese hangs after capturing video, seemingly the camera turns off or disconnect from Cheese (the camera has a little blue light that indicates activity, it turns off), its necessary to close and open again.

System Info:

- Cheese 2.22.3 (latest stable, June 29th 2008)
- My camera is a HP Webcam (lsusb says it's a Chicony Electronics Co., Ltd camera).
- All GStreamer tools are 0.10.*
- Ubuntu Hardy Heron (8.04) up to date.
- gstreamer-properties says:

Sound:

Default output
Complement: Automatically detect
Device: Not supported
Pipeline autoaudiosinkd

Default input
Complement: ALSA
Device: Default
Pipeline: alsasrc

Video:

Default output
Complement: X Window System(X11/XShm/Xv)
Device: NV17 Video Texture
Pipeline xvimagesink device="0"

Default input
Complement: Video for Linux 2 (v4l2)
Device: HP Webcam
Pipeline: v4l2src device="/dev/video0"

- Video card: NVIDIA GeForce 8400M GS, driver 169.12., XServer version 1.4.0.90 (10400090) by X.Org Foundation; NV Version 1.14.

Any other info that I should post here?

I forgot, uname says: "Linux fmg-m003 2.6.24-19-rt #1 SMP PREEMPT RT Wed Jun 18 16:35:41 UTC 2008 i686 GNU/Linux" for my computer, it's a HP Pavilion dv6871us.

Closing, fixed in trunk.
I've bumped gstreamer requirements to 0.10.16 and used gst_element_send_event to make the video recording shut down properly, as suggested in GstBaseSrc docs and pointed out by Tim.
With the previous (deprecated) method no EOS message was being generated so the pipeline did not restarted.
Now the pipeline doesn't freeze anymore but registered video and audio are still sluggish and with poor quality. Opening another bug for this and for the video file loading problem (comment #2).