dvbstreamer-devel Mailing List for DVBStreamer
Status: Beta
Brought to you by:
charrea6
Menu
▾
▴
dvbstreamer-devel — For core and plugin development queries etc.
You can subscribe to this list here.
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(3) |
Sep
(3) |
Oct
|
Nov
(2) |
Dec
(1) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2007 |
Jan
(4) |
Feb
|
Mar
(1) |
Apr
(1) |
May
|
Jun
(1) |
Jul
(1) |
Aug
(1) |
Sep
|
Oct
|
Nov
(8) |
Dec
(4) |
| 2008 |
Jan
(16) |
Feb
(15) |
Mar
(6) |
Apr
(3) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
(3) |
Oct
|
Nov
|
Dec
|
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
(3) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2014 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Chris A. <chr...@gm...> - 2014-06-01 15:05:45
|
Hi, I noticed that when running in daemon mode, the parent creates the pid file after it has forked the child, so the child has no knowledge of the file location. I attach a patch to fix that and have also updated my ArchLinux package build at https://aur.archlinux.org/packages/dvbstreamer/ cheers Chris |
|
From: Adam C. <ad...@dv...> - 2012-03-25 20:59:08
|
On Sun, 2012-03-25 at 17:45 +0200, Johannes Zellner wrote: > Hi, > > I was trying to build svn trunk of dvbstreamer today and hit a > Makefile.in generation issue. > My build machine runs Archlinux. > > sh autogen.sh output: > > processing . > Creating ./aclocal.m4 ... > Making ./aclocal.m4 writable ... > Running libtoolize... > libtoolize: putting auxiliary files in `.'. > libtoolize: copying file `./ltmain.sh' > libtoolize: You should add the contents of the following files to > `aclocal.m4': > libtoolize: `/usr/share/aclocal/libtool.m4' > libtoolize: `/usr/share/aclocal/ltoptions.m4' > libtoolize: `/usr/share/aclocal/ltversion.m4' > libtoolize: `/usr/share/aclocal/ltsugar.m4' > libtoolize: `/usr/share/aclocal/lt~obsolete.m4' > libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.in and > libtoolize: rerunning libtoolize, to keep the correct libtool macros > in-tree. > libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am. > Running aclocal ... > Running autoheader... > Running automake --gnu ... > configure.in:35: installing `./compile' > configure.in:46: installing `./config.guess' > configure.in:46: installing `./config.sub' > configure.in:27: installing `./install-sh' > configure.in:27: installing `./missing' > include/Makefile.am:8: `pkgincludedir' is not a legitimate directory for > `DATA' > src/Makefile.am: installing `./depcomp' > Makefile.am:15: `pkgincludedir' is not a legitimate directory for `DATA' > Running autoconf ... > > afterwards Makefile.in are not generated since the include/Makefile.am > and src/Makefile.am issue. > > In order to fix that we need to replace "pkginclude_DATA" with > "-pkginclude_HEADERS" in those files. > > Is there a way how I could contribute here? like mergerequests and such? > > Thanks, > Johannnes > Thanks for the info, yes there is the dvbstreamer source is currently in subversion so its a case of old style patches submitted to the sourceforge tracker please. Cheers Adam |
|
From: Johannes Z. <web...@ne...> - 2012-03-25 14:03:47
|
Hi, I was trying to build svn trunk of dvbstreamer today and hit a Makefile.in generation issue. My build machine runs Archlinux. sh autogen.sh output: processing . Creating ./aclocal.m4 ... Making ./aclocal.m4 writable ... Running libtoolize... libtoolize: putting auxiliary files in `.'. libtoolize: copying file `./ltmain.sh' libtoolize: You should add the contents of the following files to `aclocal.m4': libtoolize: `/usr/share/aclocal/libtool.m4' libtoolize: `/usr/share/aclocal/ltoptions.m4' libtoolize: `/usr/share/aclocal/ltversion.m4' libtoolize: `/usr/share/aclocal/ltsugar.m4' libtoolize: `/usr/share/aclocal/lt~obsolete.m4' libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.in and libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree. libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am. Running aclocal ... Running autoheader... Running automake --gnu ... configure.in:35: installing `./compile' configure.in:46: installing `./config.guess' configure.in:46: installing `./config.sub' configure.in:27: installing `./install-sh' configure.in:27: installing `./missing' include/Makefile.am:8: `pkgincludedir' is not a legitimate directory for `DATA' src/Makefile.am: installing `./depcomp' Makefile.am:15: `pkgincludedir' is not a legitimate directory for `DATA' Running autoconf ... afterwards Makefile.in are not generated since the include/Makefile.am and src/Makefile.am issue. In order to fix that we need to replace "pkginclude_DATA" with "-pkginclude_HEADERS" in those files. Is there a way how I could contribute here? like mergerequests and such? Thanks, Johannnes |
|
From: Adam C. <ad...@dv...> - 2010-04-20 20:58:26
|
Just a quick email to say that I've uploaded a release candidate for
2.0.0 and the first release of the new python bindings for dvbstreamer.
For more information on both of these see my blog post about it here:
http://sourceforge.net/apps/wordpress/dvbstreamer/
Cheers
Adam
|
|
From: Adam C. <ad...@dv...> - 2010-04-03 06:31:50
|
On Thu, 2010-04-01 at 22:59 +0200, web...@ne... wrote: > Hi, > > I have attached a patch that fixes a segfault in setupdvbstreamer for me. > There were too many placeholders for valist. Many thanks I'll apply this to the 1.x branch. > Regards, > Johannes Cheers Adam |
|
From: <web...@ne...> - 2010-04-01 21:11:57
|
Hi, I have attached a patch that fixes a segfault in setupdvbstreamer for me. There were too many placeholders for valist. Regards, Johannes |
|
From: Chris A. <chr...@go...> - 2009-09-28 06:52:06
|
Hi, I have written a php class to control dvbstreamer remotely (using the remote control protocol - thanks for that, very easy to use). I wish to add future recording capability to it now but have stumbled upon a problem with the event listener. If I understand things correctly the event listener system is for listening out for future events and when they occur streaming the services data to the specified mrl - in effect being able to say to dvbstreamer "I wish you to record the 10 o'clock news from BBC ONE tonight to file:///news.ts" - have I got that correct? If I have I am lost at the moment as I cannot seem to get the eventlistener to listen for one specific event, it doesn't seem to accept <eventid> as a parameter. Could someone help me clear up my confusion regarding the purpose and use of event listeners please, thanks. regards Chris Allison -- Calling the unnamed register the unnamed register really does nothing but negate the name the unnamed register and render the unnamed register useless as a name, thus the unnamed register is named the unnamed register and is no longer the unnamed register as it is named the unnamed register, so where is the unnamed register to be found and what do we call it! Steve Oualline, The book of vim. |
|
From: Adam C. <ad...@dv...> - 2009-09-22 14:20:15
|
On Tue, September 22, 2009 10:31 am, Johannes Zellner wrote: > Hello, > > I'm using dvbstreamer on my mediacenter and since I encountered a bug with > special characters in dvb-t channel names, I'm starting to take a look at > the > codebase. > > During first compilation, the -Werror flag is set so the warning in > main.c:779 > leads to build error. > The attached patch just fixes this as a small first hellopatch ;-) Many thanks Johannes, patch applied (slightly modified) to svn trunk now (rev 621) Cheers Adam |
|
From: Johannes Z. <web...@ne...> - 2009-09-22 10:29:25
|
Hello, I'm using dvbstreamer on my mediacenter and since I encountered a bug with special characters in dvb-t channel names, I'm starting to take a look at the codebase. During first compilation, the -Werror flag is set so the warning in main.c:779 leads to build error. The attached patch just fixes this as a small first hellopatch ;-) Thanks, Johannes |
|
From: Adam C. <ad...@dv...> - 2009-07-06 10:10:08
|
On Sun, July 5, 2009 11:36 am, Marcel Ritter wrote: > Hi, > > found a bug in dvbctrl.c, that prevents compilation when using -Wall. > (Wrong/incomplete prototype definition of Authenticate()) > > Fix is attached as patch. > > Bye, > Marcel Thanks for that Marcel, I'll get it into trunk as soon as I have a moment. Cheers Adam |
|
From: Marcel R. <Mar...@rr...> - 2009-07-05 10:48:00
|
Hi, found a bug in dvbctrl.c, that prevents compilation when using -Wall. (Wrong/incomplete prototype definition of Authenticate()) Fix is attached as patch. Bye, Marcel |
|
From: Paul K. <pa...@st...> - 2008-04-04 11:36:29
|
On Fri, 4 Apr 2008, Paul Kelly wrote: > On Thu, 3 Apr 2008, Adam Charrett wrote: > >> I'll add a -L option (not -l as this is used by setupdvbstreamer and all >> the apps will get this new option) to allow you to specify a file to log >> to. I'll look into using a filename like '-' to mean stderr. >> >> By the way, I'm curious what exactly are you using DVBStreamer for? (No >> need to answer that if you not allowed ;-) ) > > Yes no problem - I'm writing a number of custom plugins to process and > save the content simultaneously from multiple services on each multiplex. > When they're finished and tested I expect to release them under the GPL. > A while ago I posted a previous iteration of a plugin to split the MPEG-TS > stream into minute-long files to this list I think. Another one transcodes > the MPEG video and audio in realtime into a more compressed format and > saves this. To do this it uses an external transcoding library. The > external library (FFmpeg) issues occasional warnings and errors to > stderr. My plugins have used (up to now) the dvbstreamer logging > mechanism, which also wrote to stderr and the messages from FFmpeg would > be interspersed in the correct order with the log output from my plugins, > allowing me to see easily when and as part of what sequence of events the > errors/warnings had occured. > > The "-l -" option would be useful, otherwise I think I will just change my > plugins to write the log info directly to stderr to get around this. Looks like I can get FFmpeg to use the dvbstreamer LogModule() function, so not to worry about that last comment. The user-specifiable log file will still be really useful though, thanks. Paul |
|
From: Paul K. <pa...@st...> - 2008-04-04 00:40:55
|
On Thu, 3 Apr 2008, Adam Charrett wrote: > I'll add a -L option (not -l as this is used by setupdvbstreamer and all > the apps will get this new option) to allow you to specify a file to log > to. I'll look into using a filename like '-' to mean stderr. > > By the way, I'm curious what exactly are you using DVBStreamer for? (No > need to answer that if you not allowed ;-) ) Yes no problem - I'm writing a number of custom plugins to process and save the content simultaneously from multiple services on each multiplex. When they're finished and tested I expect to release them under the GPL. A while ago I posted a previous iteration of a plugin to split the MPEG-TS stream into minute-long files to this list I think. Another one transcodes the MPEG video and audio in realtime into a more compressed format and saves this. To do this it uses an external transcoding library. The external library (FFmpeg) issues occasional warnings and errors to stderr. My plugins have used (up to now) the dvbstreamer logging mechanism, which also wrote to stderr and the messages from FFmpeg would be interspersed in the correct order with the log output from my plugins, allowing me to see easily when and as part of what sequence of events the errors/warnings had occured. The "-l -" option would be useful, otherwise I think I will just change my plugins to write the log info directly to stderr to get around this. Paul |
|
From: Adam C. <ad...@ch...> - 2008-04-03 15:46:09
|
On Mon, March 31, 2008 5:35 pm, Paul Kelly wrote: > On Mon, 31 Mar 2008, Adam Charrett wrote: > >> On Mon, March 31, 2008 1:32 pm, Paul Kelly wrote: >>> On Mon, 31 Mar 2008, Adam Charrett wrote: >>> >>>> Any thoughts people? Is it too soon to be using the all important 1.0? >>>> Is >>>> there anything else that needs/should go in this release? >>> >>> Hi Adam, I just checked out a clean SVN trunk and compiled and verbose >>> output doesn't seem to be working for me: >>> dvbstreamer -vvvv >>> doesn't produce any debug messages at all. >> >> Ahh, thats because all output is now sent to >> ~/.dvbstreamer/dvbstreamer-<adapter>.log. > > Ah OK. Is there/can there be an option to specify that file, or (better > still) just send the output to stderr? We run multiple dvbstreamer > instances on different DVB cards with stderr redirected to files with > various names (depending on external settings) on a separate logging disk > partition. (The new foreground daemon mode has been a big help for this > BTW.) I suppose we could create symlinks to the correct files before > starting dvbstreamer but that seems a bit of a hack. > I'll add a -L option (not -l as this is used by setupdvbstreamer and all the apps will get this new option) to allow you to specify a file to log to. I'll look into using a filename like '-' to mean stderr. By the way, I'm curious what exactly are you using DVBStreamer for? (No need to answer that if you not allowed ;-) ) Cheers Adam |
|
From: Paul K. <pa...@st...> - 2008-03-31 16:35:16
|
On Mon, 31 Mar 2008, Adam Charrett wrote: > On Mon, March 31, 2008 1:32 pm, Paul Kelly wrote: >> On Mon, 31 Mar 2008, Adam Charrett wrote: >> >>> Any thoughts people? Is it too soon to be using the all important 1.0? >>> Is >>> there anything else that needs/should go in this release? >> >> Hi Adam, I just checked out a clean SVN trunk and compiled and verbose >> output doesn't seem to be working for me: >> dvbstreamer -vvvv >> doesn't produce any debug messages at all. > > Ahh, thats because all output is now sent to > ~/.dvbstreamer/dvbstreamer-<adapter>.log. Ah OK. Is there/can there be an option to specify that file, or (better still) just send the output to stderr? We run multiple dvbstreamer instances on different DVB cards with stderr redirected to files with various names (depending on external settings) on a separate logging disk partition. (The new foreground daemon mode has been a big help for this BTW.) I suppose we could create symlinks to the correct files before starting dvbstreamer but that seems a bit of a hack. Thanks, Paul |
|
From: Adam C. <ad...@ch...> - 2008-03-31 13:41:36
|
On Mon, March 31, 2008 1:32 pm, Paul Kelly wrote: > On Mon, 31 Mar 2008, Adam Charrett wrote: > >> Any thoughts people? Is it too soon to be using the all important 1.0? >> Is >> there anything else that needs/should go in this release? > > Hi Adam, I just checked out a clean SVN trunk and compiled and verbose > output doesn't seem to be working for me: > dvbstreamer -vvvv > doesn't produce any debug messages at all. Ahh, thats because all output is now sent to ~/.dvbstreamer/dvbstreamer-<adapter>.log. > A minor inconsistency that I've noticed is when working with service names > that contain spaces, some dvbstreamer commands require the service name to > be quoted and some don't (and won't work if it is quoted!): To give an > example select doesn't require quotes but lspids does. Yep, the only way I can think of fixing this is by making all commands require quotes, this would break backwards compatibility with the available clients. I will think about this, but I think its fair to say this is an annoyance which may have to wait till after 1.0, when I won't mind breaking other things :-) > If I can think of any other niggling issues I'll let you know. > > Paul > Thanks for the feedback keep it coming.... |
|
From: Paul K. <pa...@st...> - 2008-03-31 12:32:59
|
On Mon, 31 Mar 2008, Adam Charrett wrote: > Any thoughts people? Is it too soon to be using the all important 1.0? Is > there anything else that needs/should go in this release? Hi Adam, I just checked out a clean SVN trunk and compiled and verbose output doesn't seem to be working for me: dvbstreamer -vvvv doesn't produce any debug messages at all. A minor inconsistency that I've noticed is when working with service names that contain spaces, some dvbstreamer commands require the service name to be quoted and some don't (and won't work if it is quoted!): To give an example select doesn't require quotes but lspids does. If I can think of any other niggling issues I'll let you know. Paul |
|
From: Adam C. <ad...@ch...> - 2008-03-31 12:03:16
|
Right it's now been 3 months or so since 0.9 was released and there has now been several major bugs fixed on the trunk I think its time for a new release :-). Given that Chris is hopefully going to rustle up a new database subsystem, I'm thinking about making the next release 1.0 and then the release after that (with the new db subsystem in) will be 1.1. Any thoughts people? Is it too soon to be using the all important 1.0? Is there anything else that needs/should go in this release? Cheers Adam PS. If I get silence I'll assume everyone agrees with me and go ahead and release :-P |
|
From: Adam C. <ad...@ch...> - 2008-03-19 21:05:11
|
On Wed, 2008-03-19 at 14:09 -0400, Chris Whiteford wrote: > Well I have been MIA for a while. The reason... I went to the dark > side. I got lured in by Myth and its web frontend. After getting it > running, I decided to start playing with it.... And so the fighting, > tweaking, and changing began. I realized that I never should have > bothered. There are SO many moving parts that its just not worth the > effort. > > I should have never left.... I see the error in my ways. :-) > > SO that being said I am back with a vengeance. I am tackling the DB > rework stuff and trying to wrap my head around how to deal with things. > > Some initial thoughts I have are to create a DB management "object" (ya > its C so not really an object, but you get the idea). > > It will be responsible for ALL the high level APIs that the rest of > dvbstreamer can use to talk to the data provider. This leads into the > next component. The data provider. First off a sqlite one that mirrors > the existing setup. Then after that a mysql version that lets all the > data be stored in mysql. > > The benefit of this approach is that all the data work is tucked away > and hidden from the other functional parts of dvbstreamer. We also gain > a simple way to synchronize access to the DB between multiple threads, > plugins, or what ever else is using the DB. > > Off the top of my head using some type of DSN for defining the DB > connection details on the command line sounds like a good way to go. > Something like > -db sqlite://~/.dvbstreamer > or > -db mssql://user:password@host/db > > If nothing is provided then the default rules kick in and the sqlite > provider is used and everything is just as it is now. > > I am going through the initial process of looking at the existing DB > access code and trying to come up with a sane way to structure these new > components. > > Once I have something a bit more concrete I'll post to the list for review. > > As a side note, I have 2 dvb cards working now running 2 diffrent > satellites each. So I'll have a test bed to play with a multi card > setup. :-) > > Comments, flames, and "I told you so" about myth are encouraged :-) > > Glad to be back in the land of the light. > chris. Glad your back, all help, especially with the database side of things is much appreciated. Oh and on the mythtv front, been there tried that settled for freevo in the end :-) Cheers Adam |
|
From: Chris W. <ch...@ch...> - 2008-03-19 18:09:55
|
Well I have been MIA for a while. The reason... I went to the dark side. I got lured in by Myth and its web frontend. After getting it running, I decided to start playing with it.... And so the fighting, tweaking, and changing began. I realized that I never should have bothered. There are SO many moving parts that its just not worth the effort. I should have never left.... I see the error in my ways. :-) SO that being said I am back with a vengeance. I am tackling the DB rework stuff and trying to wrap my head around how to deal with things. Some initial thoughts I have are to create a DB management "object" (ya its C so not really an object, but you get the idea). It will be responsible for ALL the high level APIs that the rest of dvbstreamer can use to talk to the data provider. This leads into the next component. The data provider. First off a sqlite one that mirrors the existing setup. Then after that a mysql version that lets all the data be stored in mysql. The benefit of this approach is that all the data work is tucked away and hidden from the other functional parts of dvbstreamer. We also gain a simple way to synchronize access to the DB between multiple threads, plugins, or what ever else is using the DB. Off the top of my head using some type of DSN for defining the DB connection details on the command line sounds like a good way to go. Something like -db sqlite://~/.dvbstreamer or -db mssql://user:password@host/db If nothing is provided then the default rules kick in and the sqlite provider is used and everything is just as it is now. I am going through the initial process of looking at the existing DB access code and trying to come up with a sane way to structure these new components. Once I have something a bit more concrete I'll post to the list for review. As a side note, I have 2 dvb cards working now running 2 diffrent satellites each. So I'll have a test bed to play with a multi card setup. :-) Comments, flames, and "I told you so" about myth are encouraged :-) Glad to be back in the land of the light. chris. |
|
From: Adam C. <ad...@ch...> - 2008-02-19 23:30:25
|
On Tue, 2008-02-19 at 20:17 +0000, Paul Kelly wrote: > On Tue, 19 Feb 2008, Adam Charrett wrote: > > > I've check in fixes for both the manualfilter and servicefilter issues today. > > The fixes where to add a new ServiceFilterDestroyAll() call which gets rid > > of all services filters (and their delivery method instances) and to add a > > new DeliveryMethodDestroyAll() that will clean up all delivery method > > instances before the plugins are shut down. > > Hmm, what about the cases of removing a filter manually or setting the MRL > to a new value (rmmf and setmfmrl commands)? Is the attached patch of any > interest? Doh, good point will try and get that in svn tomorrow. Cheers Adam |
|
From: Paul K. <pa...@st...> - 2008-02-19 20:17:07
|
On Tue, 19 Feb 2008, Adam Charrett wrote: > I've check in fixes for both the manualfilter and servicefilter issues today. > The fixes where to add a new ServiceFilterDestroyAll() call which gets rid > of all services filters (and their delivery method instances) and to add a > new DeliveryMethodDestroyAll() that will clean up all delivery method > instances before the plugins are shut down. Hmm, what about the cases of removing a filter manually or setting the MRL to a new value (rmmf and setmfmrl commands)? Is the attached patch of any interest? Paul |
|
From: Adam C. <ad...@ch...> - 2008-02-19 16:30:48
|
On Thu, February 14, 2008 9:36 am, Adam Charrett wrote: > On Wed, February 13, 2008 8:10 pm, Paul Kelly wrote: >> On Wed, 13 Feb 2008, Steve VanDeBogart wrote: >> >>> On Wed, 13 Feb 2008, Paul Kelly wrote: >>> >>>> Yes indeed - I've already got as far as seeing how to free the old >>>> instance >>>> when the MRL is changed (see attached patch, although it might need >>>> checking for a NULL instance as your patch does). >>> >>> Seems like the code should be changed to use >>> DeliveryMethodManagerFree() >>> and >>> ServiceFilterDeliveryMethodSet. >> >> Yes, although perhaps then some packets might be lost, while the >> delivery >> method is temporarily set to NULL? I don't konw if that's relevant or >> not. >> > I wouldn't worry about loosing a few packets, its what the broadcast > medium general does :-) > > As for the bug, it is a bug and needs to be fixed. I pretty sure that > servicefilter has the same issue, I will need to add a deinit function to > service filter to close down all the service filters and an install > feature to the manual filter plugin to do the same. > > I'm currently overhauling the command execution side of things at the > moment and adding a new Events framework, so I'll get round to it in the > next week or so. I'll open a bug report for it though so I don't forget > about it. > I've check in fixes for both the manualfilter and servicefilter issues today. The fixes where to add a new ServiceFilterDestroyAll() call which gets rid of all services filters (and their delivery method instances) and to add a new DeliveryMethodDestroyAll() that will clean up all delivery method instances before the plugins are shut down. The reason I haven't changed manualfilter to destroy the delivery methods is that these are all implemented in plugins, and as such there is no way to know whether they will be shut down before or after manualfilter. This way all delivery methods get closed gracefully before the plugins start shutting down. Cheers Adam |
|
From: Mark <mp...@or...> - 2008-02-14 11:13:42
|
Hi everybody. I've cleaned up the Client class code to make it easier to read and removed a few too many comments. I'm still trying to get my head around SVN, But I'm slowly getting there! Hehe.. I'm such a klutz. I've not really had much time of late to work on the interface part of the webui, So I'm not sure when I'll be getting a usable version on SVN, Anyway.. I've decided to create a sort of Basic UI, Nothing too fancy but usable. I was thinking about using pure HTML files for the design, Using AJAX to pull the data from a backend php script. For the design what type of color scheme do you guys want? (I can't believe I've just asked that question :o) Anyway.. Let us know what you guys think / want! -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ |
|
From: Adam C. <ad...@ch...> - 2008-02-14 09:36:16
|
On Wed, February 13, 2008 8:10 pm, Paul Kelly wrote: > On Wed, 13 Feb 2008, Steve VanDeBogart wrote: > >> On Wed, 13 Feb 2008, Paul Kelly wrote: >> >>> Yes indeed - I've already got as far as seeing how to free the old >>> instance >>> when the MRL is changed (see attached patch, although it might need >>> checking for a NULL instance as your patch does). >> >> Seems like the code should be changed to use DeliveryMethodManagerFree() >> and >> ServiceFilterDeliveryMethodSet. > > Yes, although perhaps then some packets might be lost, while the delivery > method is temporarily set to NULL? I don't konw if that's relevant or not. > I wouldn't worry about loosing a few packets, its what the broadcast medium general does :-) As for the bug, it is a bug and needs to be fixed. I pretty sure that servicefilter has the same issue, I will need to add a deinit function to service filter to close down all the service filters and an install feature to the manual filter plugin to do the same. I'm currently overhauling the command execution side of things at the moment and adding a new Events framework, so I'll get round to it in the next week or so. I'll open a bug report for it though so I don't forget about it. Cheers Adam |
