dvd::rip

->ABOUT / NEWS

->DOCUMENTATION
-TABLE OF CONTENTS
-INSTALLATION
-USING THE GUI
-CLUSTER MODE
-FAQ

->KEY FEATURES

->DOWNLOAD

->SUPPORT

->TRANSLATIONS

->MAILING LIST
-SEARCH ARCHIVE

->CHANGE LOG

->CREDITS

->TODO

->LINKS

http://www.exit1.org/


Re: [dvd::rip] Problems with most filters

Subject: Re: [dvd::rip] Problems with most filters
From: Bruno Treguier <Bruno.Treguier@xxxxxxx>
Date: Mon, 30 Jan 2006 15:32:42 +0100
Hi Jörn,

> Bruno Treguier wrote:
> 
> > First of all, I've been unable to run most of the filters, and it seems
> > that in the end, the only ones I've managed to get working are the ones
> > that don't need any parameter. Any attempt to use a filter needing a
> > parameter results in a pop-up window spawning and stating something like
> > this (for the logo filter here):
> > [...]
> 
> I just reproduced this problem. transcode fails if more than one 
> parameter is passed to the module. Modules without any parameters or 
> just one parameter work.
> 
> I just posted a correspondent report to the transcode developers.

Thanks a lot !


> > of tcmodinfo -s, by the way). I know that this can happen: as long as
> > a process holds a file descriptor open on a file or socket, it can be
> > used without any reference to it being present and accessible via a
> > name on the filesystem, but I find this rather strange in dvdrip's
> > case...
> 
> Why? dvd::rip removes the socket just after transcode was started (which
> creates the socket). This way the socket doesn't leak if something fail
> badly, e.g. a dvd::rip or transcode crash. The filesystem entry is not 
> needed for proper operation once both processes are connected to the 
> socket, which was represented by it.

Ok. I hadn't thought about the possible socket leak...


> > An important detail: the
> > transcode command in the log window is really the one launched, from what
> > I can see via a "ps" command or examining directly the "cmdline" file
> > within the /proc pseudo-filesystem.
> 
> Hmm, what did you expect? ;)

Well, a bug wasn't excluded in that part, so I just wanted to state that
I had checked. ;-)

Regards,

Bruno

-- 
-- Service Hydrographique et Oceanographique de la Marine ---  EPSHOM/CIS/MIC
--     13, rue du Chatellier ---  BP 30316  --- 29603 Brest Cedex, FRANCE
--        Phone: +33 2 98 22 17 49  ---  Email: Bruno.Treguier@xxxxxxx

<Prev in Thread] Current Thread [Next in Thread>
 

Archive powered by MHonArc. Search powered by ht://dig.

[ top ]