I am using 0.9.6 on Fedora 20 with ffmpeg-2.1.4-1.
Gui crashes when using ffmpeg
The settings of ffmpeg (Normal MPEG) are:
Code: Select all <http://forum.kde.org/viewtopic.php?f=265&t=120391#> f=mpeg
acodec=mp2 ab=128k ar=48000 vcodec=mpeg2video minrate=0 vb=4000k
If I do the following steps
1. Go to Record Monitor tab in Clip Monitor
2. Select FFmpeg in combo box
3. Select either Video or Audio
4. Click on Record button
5. Click on Stop button
then kdenlive GUi freezes [image: :(]
The only useful information is
[wav @ 0x7f676015cc40] Encoder did not produce proper pts, making some up.
And I have to send a signal to term the process...
The Screen grab works fine... any ideas?
Thanks in advance
Sergio Belkin http://www.sergiobelkin.com
LPIC-2 Certified - http://www.lpi.org
In case readers don't know, this page describes what a merge review is:
In short: when fedora core and extras merged, a Package Review was opened for
every package in core. The idea was that every core package would be reviewed
to ensure it met with the extras packaging guidelines. It has never blocked
anything, it's just a best effort 'we should do this one day'.
Since 1 year ago (2013-03-24), 8 merge reviews have been closed as either
RAWHIDE, CURRENTRELEASE, or NEXTRELEASE.
There's currently 126 open merge reviews. Of those, since 2013-03-24, 8 have
received new comments. The breakdown is:
Not related to any progress on the merge review (account closings mostly):
Related to the merge review but not indicative of any progress being made
(pings, 'what is this bug for', ...): 225755, 226425
Varying amounts of attempted review (4 bugs): 225989, 226209, 225708, 226140
So in the past 12 months, there's been some positive activity on 12 merge
reviews. But 116 have sat totally dormant. Many have not been touched for over
Keeping these reviews open has a real cost:
- Developer confusion in the form of 'what is this bug, why should I care'
(there's lots of that in the comments of these reviews from over the years).
- Reviewer confusion when they go to this page:
http://fedoraproject.org/PackageReviewStatus/ I experienced this when I
first went to the page, and had to go read up on it.
- Reviewer energy, for those folks that make a valiant attempt only for
repeated pings to go unanswered. And yet I don't blame maintainers for not
caring much about a merge review. And they are easy to ignore: personally I
don't track bugs assigned to me so much as I track bugs belonging to the
packages I care about, so I'm sure many maintainers don't even know these open
bugs exist, since the component is 'Package Review'.
- Bugzilla search times on open bugs (okay that's probably a stretch :) )
I suggest we just close all these bugs. I'm happy to do the autoclosing, add
myself to the CC, and handle any follow up comments. I propose a message like
"We've decided to close all merge reviews:
<link to this thread>
If there is any in-progress work lingering, or if anyone is interested in
completing this review, please reopen this bug and reassign the bug to the
An alternative would be to reassign every open merge review to the component
in question, and let maintainers handle it as they like.
Welp, we're still in a pre-F21 holding pattern, and I'm not aware of any
specific Fedora.next stuff we need to discuss or any other important
agenda items. If anyone's aware of any please let us know, otherwise I'm
proposing we cancel the meeting on Monday.
If someone has a topic and would like to have the meeting, please do
reply to this, and/or send out a meeting announcement in the usual
format (see https://fedoraproject.org/wiki/QA:SOP_IRC_meeting_process );
otherwise, let's say the meeting's off. Thanks!
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
test-announce mailing list
My Lenovo X220, running up-to-date F20 occasionally gets into a state where
closing the laptop lid does not trigger suspend.
I want to narrow down on the problem, but I'm slightly lost on how
"the signal is routed" through the stack. udev->?-> systemd-suspend ->
- ask interesting questions
- don't get distracted with shiny stuff - working code first
Recently, I was hitting a number of odd behaviours that look like races.
Filed a couple of bugs:
But this feels unsatisfactory, because reproducibility is extremely
low for all cases. Bugs aren't going to cut it.
So, I'm wondering if anyone has an idea where to dig.
Here's what I recall seeing:
- The audio volume applet does not always react to plugging headphones.
Re-plug and it goes away.
- Screensaver forgetting to blank. Move cursor and problem disappears.
- Applications may not map on screen on start. Click on activity again
usually fixes the problem.
I think there were more, I just can't remember them all.
In each instance it's easy to blame firmware, kernel, whatever. But
there are several. If RAM was bad, I imagine I'd see crashes. But no,
system is stable. Also, F19 worked fine.
Of course it's most difficult to find a black cat in dark room when
it is not in the room, so I'm wondering if I'm seeing things. If anyone
else is seeing a sudden onset of racing behaviours after upgrade to F20,
please let me know.
= Proposed Self Contained Change: Apache Mesos =
Change owner(s): Timothy St. Clair <tstclair(a)redhat.com>
Apache Mesos  is a cluster manager for sharing distributed application
frameworks. This change brings Mesos to Fedora, which many have called a
micro-kernel for the data center.
== Detailed Description ==
Apache Mesos is a cluster manager that provides efficient resource isolation
and sharing across distributed applications, or frameworks. It can run Hadoop,
MPI, Hypertable, Spark, and other applications on a dynamically shared pool of
== Scope ==
* Proposal owners: Currently our Mesos package has been accepted into Fedora.
It should feature all of the functionality available from the upstream
* Other developers: N/A (not a System Wide Change)
* Release engineering: N/A (not a System Wide Change)
* Policies and guidelines: N/A (not a System Wide Change)
devel-announce mailing list