Description of problem: Version-Release number of selected component (if applicable): 0.2.1 How reproducible: Always Steps to Reproduce: 1. Record a desktop session with sound (I'm also using 1/4 size) 2. Click "stop" Actual results: Tray icon locks up on the "hard drive" saving image. If run from the command line, python dumps this when Istanbul starts: DEBUG: final pipeline: oggmux name=mux ! filesink location=/tmp/tmp-OJbKk istximagesrc name=videosource show-pointer=false ! video/x-raw-rgb,framerate=10/1 ! videorate ! ffmpegcolorspace ! videoscale method=1 ! video/x-raw-yuv,width=256,height=192,framerate=10/1 ! theoraenc ! queue ! mux. gconfaudiosrc name=audiosource ! audioconvert ! vorbisenc ! queue ! mux. Traceback (most recent call last): File "/usr/local/lib/python2.4/site-packages/istanbul/main/tray_icon.py", line 56, in _trayicon_clicked self.current_screencast.start_recording() File "/usr/local/lib/python2.4/site-packages/istanbul/main/screencast.py", line 109, in start_recording self._pipeline = gst.parse_launch(final_pipeline) gobject.GError: could not link videorate0 to ffmpegcsp0 ...and dumps this when the "stop" button is clicked: Traceback (most recent call last): File "/usr/local/lib/python2.4/site-packages/istanbul/main/tray_icon.py", line 62, in _trayicon_clicked self.current_screencast.stop_recording() File "/usr/local/lib/python2.4/site-packages/istanbul/main/screencast.py", line 136, in stop_recording self._vsource.set_state(gst.STATE_NULL) AttributeError: Screencast instance has no attribute '_vsource' At this point istanbul has to be ^c'd to make it go away. Looking at the code it appears that the second error is caused by the first, since the _vsource attribute depends upon the _pipeline attribute to be set properly. However, I'm not sure what to do about the "gobject.GError: could not link videorate0 to ffmpegcsp0" error. Expected results: Save a desktop recording. Istanbul sounds ideal for some internal training videos I want to make, so if there's any kind of a quick fix available I'd love to hear about it.
Sorry, I was away at a conference. Does the crash happen only when you attempt to use the re-sizing options? If we can narrow down under what conditions we can get it to crash repeatedly we may be able to get the upstream developer to patch the bug. I have an fc6 system installed now so I can attempt to reconfirm crash conditions, but I can't garuntee I'll be able to fix it without the upstream developer for istanbul getting involved. -jef
I just attempted to reproduce your crash condition and I could not. Can you make sure you have all the fc6 updates installed and try again. I was able to make an ogg theora video with record 3d. record mouse and record sound enabled with quarter width and hieght selected. I can't actually test if sound recording is working.. but i did not get a crash. -jef
I am able to reproduce an almost identical error (see below) by: 1. click "Select Area to Record" in istanbul popup 2. click anywhere in the screen, actually selecting a one pixel wide area (I wanted to capture _only_ a window and misinterpreted the menu) [giallu@hal9001 ~]$ istanbul DEBUG: final pipeline: istximagesrc name=videosource use-damage=false show-pointer=false ! video/x-raw-rgb,framerate=10/1 ! videorate ! ffmpegcolorspace ! videoscale method=1 ! video/x-raw-yuv,width=1400,height=1050,framerate=10/1 ! theoraenc ! oggmux name=mux ! filesink location=/tmp/tmpAUsdzX SaveWindow with file: /tmp/tmpAUsdzX (992, 605) - (993, 606) DEBUG: final pipeline: istximagesrc startx=992 starty=605 endx=992 endy=605 name=videosource use-damage=false show-pointer=false ! video/x-raw-rgb,framerate=10/1 ! videorate ! ffmpegcolorspace ! videoscale method=1 ! video/x-raw-yuv,width=1,height=1,framerate=10/1 ! theoraenc ! oggmux name=mux ! filesink location=/tmp/tmpjxCvJB Traceback (most recent call last): File "/usr/lib/python2.4/site-packages/istanbul/main/tray_icon.py", line 56, in _trayicon_clicked self.current_screencast.start_recording() File "/usr/lib/python2.4/site-packages/istanbul/main/screencast.py", line 109, in start_recording self._pipeline = gst.parse_launch(final_pipeline) gobject.GError: could not link videoscale2 to theoraenc1 Traceback (most recent call last): File "/usr/lib/python2.4/site-packages/istanbul/main/tray_icon.py", line 62, in _trayicon_clicked self.current_screencast.stop_recording() File "/usr/lib/python2.4/site-packages/istanbul/main/screencast.py", line 136, in stop_recording self._vsource.set_state(gst.STATE_NULL) AttributeError: Screencast instance has no attribute '_vsource'
The mystery deepens... select area is working for me. I'll attach my example desktop area vorbis recording i just made for you to take a look at. So we need to figure out why this works for me and not for you. Are you on 32bit or 64bit? I'm on 32bit. Do you have all the available fc6/fe6 updates installed? What is the exact kernel version you have installed and running uname -r and yum list kernel and report back with the line for the installed kernel. My output: uname -r: 2.6.18-1.2798.fc6 yum list kernel: kernel.i686 2.6.18-1.2798.fc6 installed What video hardware are you using? -jef
Created attachment 140975 [details] Example recording using selection area feature of fc6 istanbul Example recording using selection area feature of fc6 istanbul
Here are the relevant specs for my system: [brad@satsuki ~]$ cat /proc/cpuinfo | grep model\ name model name : Mobile Intel(R) Pentium(R) 4 - M CPU 2.00GHz [brad@satsuki ~]$ lspci | grep VGA 01:00.0 VGA compatible controller: ATI Technologies Inc Radeon Mobility M7 LW [Radeon Mobility 7500] [brad@satsuki ~]$ uname -r 2.6.18-1.2798.fc6 The system is fully updated. I think the key lies in figuring out what the first crash means: DEBUG: final pipeline: oggmux name=mux ! filesink location=/tmp/tmp-OJbKk istximagesrc name=videosource show-pointer=false ! video/x-raw-rgb,framerate=10/1 ! videorate ! ffmpegcolorspace ! videoscale method=1 ! video/x-raw-yuv,width=256,height=192,framerate=10/1 ! theoraenc ! queue ! mux. gconfaudiosrc name=audiosource ! audioconvert ! vorbisenc ! queue ! mux. Traceback (most recent call last): File "/usr/local/lib/python2.4/site-packages/istanbul/main/tray_icon.py", line 56, in _trayicon_clicked self.current_screencast.start_recording() File "/usr/local/lib/python2.4/site-packages/istanbul/main/screencast.py", line 109, in start_recording self._pipeline = gst.parse_launch(final_pipeline) gobject.GError: could not link videorate0 to ffmpegcsp0 I've emailed the author but gotten no response.
Interesting... [brad@satsuki ~]$ locate ffmpegc /usr/lib/gstreamer-0.10/libgstffmpegcolorspace.so /usr/lib/gstreamer-0.8/libgstffmpegcolorspace.so I have to run now but I will try changing colordephts and see what happens. I'm currently using "Thousands of Colors" (16-bit?). I'll try changing it later and see if it makes a difference.
(In reply to comment #4) > The mystery deepens... select area is working for me. I'll attach my example > desktop area vorbis recording i just made for you to take a look at. Yap. it works (and I can do the same here) but maybe I missed to stress what is the cuplrit (at least in _my_ case): the error I see is triggered by selecting a 1x1 area to record. Of course that is a stupid thing to do BUT users often do stupid things :) > > So we need to figure out why this works for me and not for you. > Are you on 32bit or 64bit? I'm on 32bit. This is a laptop with a centrino (so 32 bit) processor 1.7 Ghz, > > Do you have all the available fc6/fe6 updates installed? Yes. And I am using FC/FE/livna repos only. I'm attaching the full pkg list in this machine > > My output: > uname -r: > 2.6.18-1.2798.fc6 > yum list kernel: > kernel.i686 2.6.18-1.2798.fc6 installed same here > > > What video hardware are you using? from lspci -v: ATI Technologies Inc RV350 [Mobility Radeon 9600 M10] (prog-if 00 [VGA]) from s-c-d: 1400x1050 resolution, millions of colors, radeon driver
Created attachment 140992 [details] list of packages installed in my PC
In reply to comment #9 Yippie! I can definitely confirm a crash condition if I make the selected area "too small." I don't know how small too small is at the moment..but now that I can reproduce the crasher I can start playing with gstreamer pipelines outside of istanbul and try to figure out more specifics and bound the problem space. My hunch is that there is an inherent limitation on the size of the video geometry for some of the gstreamer plugins in the pipeline. I'll know more once I can spin up standalone gstreamer pipelines to use with gst-launch at the cmdline. If that hunch is true the easiest quick fix in istanbul would be to pad the selected area up to whatever minimum geometry is allowed by the gstreamer objects. Can someone help me spin up a prototype patch that does the padding of the area select? We can play with the pad values in more detail later after I do more testing. On top of that maybe we can help the upstream author implement some error condition checking on the gstreamer pipeline, so istanbul can throw an error dialog instead of a traceback for other potential crashers related to pipeline errors. I still cannot reproduce a crash using the conditions laid out by the original reporter so far. The original reporter maybe hitting a related but different crash condition. -jef"slow progress is better than no progress"spsleta
Seeing the crash here with an up to date rawhide (FC7). I've got a Radeon 9700 Pro with the open source radeon driver, with the driver in 16 bit depth mode it crashes but it works in 24 bit. The minimum size bug seems unrelated (from what i can see) to the original reporters bug. Brad did this (bumping up the bith depth) solve it for you to?
(In reply to comment #11) > Seeing the crash here with an up to date rawhide (FC7). > I've got a Radeon 9700 Pro with the open source radeon driver, with the driver > in 16 bit depth mode it crashes but it works in 24 bit. > The minimum size bug seems unrelated (from what i can see) to the original > reporters bug. > Brad did this (bumping up the bith depth) solve it for you to? > This sounds like a problem with the underlying gstreamer module that deals with X capture. We need to find the cycles to test this with gstreamer pipelines outside of istanbul so we can narrow down the problem(s). I just haven't found the cycles to dig into this and hand you guys back some custom gstreamer pipelines to run. -jef
> Brad did this (bumping up the bith depth) solve it for you to? Interestingly enough, yes. It seems to work now.
maybe some more info... recording a area of half my desktop works recording the full desktop causes the following error istanbul DEBUG: final pipeline: istximagesrc name=videosource show-pointer=false ! video/x-raw-rgb,framerate=10/1 ! videorate ! ffmpegcolorspace ! videoscale method=1 ! video/x-raw-yuv,width=1024,height=768,framerate=10/1 ! theoraenc ! oggmux name=mux ! filesink location=/tmp/tmpxPplir SaveWindow with file: /tmp/tmpxPplir The program 'istanbul' received an X Window System error. This probably reflects a bug in the program. The error was 'BadAlloc (insufficient resources for operation)'. (Details: serial 46 error_code 11 request_code 140 minor_code 19) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the --sync command line option to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.)
Just an update, I'm working on updating istanbul to 0.2.2 if reported a crash condition in this bug ticket previously can you take my test rpms for a spin. You will need both the istanbul and the python-xlib rpms found at http://jspaleta.thecodergeek.com/Fedora%20SRPMS/istanbul/0.2.2-FC6-test/ I can't do the istanbul update till python-xlib passes review. But the my locally built rpms should be fine for testing. -jef
The 0.2.2 version of istanbul has been built and should be available on the mirrors very shortly. Please retest for this bug with the update and report back. -jef
When I try to reproduce this bug with Fedora 7, I only get this output: /usr/lib/python2.5/site-packages/istanbul/main/tray_icon.py:26: DeprecationWarning: the module egg.trayicon is deprecated; equivalent functionality can now be found in pygtk 2.10 import egg.trayicon DEBUG: final pipeline: oggmux name=mux ! filesink location=/tmp/tmp4tyNj6 istximagesrc name=videosource display-name=:0.0 screen-num=0 ! video/x-raw-rgb,framerate=10/1 ! videorate ! ffmpegcolorspace ! videoscale method=1 ! video/x-raw-yuv,width=320,height=256,framerate=10/1 ! theoraenc ! queue ! mux. gconfaudiosrc name=audiosource ! audioconvert ! vorbisenc ! queue ! mux. And the Icon stays at the harddrive Icon, but the cpu idles. I do not know, where there is the recording or how to acquire it, the icon does not change when I click on it and there is no context menu anymore. I used istanbul-0.2.2-2.fc7 on kde.
This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '7'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 7's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 7 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists. Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs: http://docs.fedoraproject.org/release-notes/ The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Just to follow up, I think the last problem reported in this bug has finally been fixed in recent updates to Fedora 8 and Fedora 9. There was a lingering problem with audio recording that has a patch now and I have confirmed fix that the F9 zero-day update for istanbul is working for people. But we arrived at the patch far too late for the inclusion of F7. The patched F8 version is heading to stable updates testing right now as well. -jef
Fedora 7 changed to end-of-life (EOL) status on June 13, 2008. Fedora 7 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.