On 1/6/06, James E. Flemer <address@hidden> wrote:
The upnp in FreeBSD ports was stale (old version) when I made the port
for GMS. I created a new port libupnp based on upnp for the latest
version of libupnp (I renamed it "libupnp" to match the distribution
name, and to avoid conflicts with the old incompatible version in the
ports tree). I submitted my changes for the new version of libupnp to
the maintainer... The devel/upnp port is *definitely* not the same as
my libupnp port (compare the patch files in the two).
I didn't actually compare any of the patches, I just assumed they were
based on the same "Linux SDK" sources. interesting that they're
different.
I might get around to updating the FreeBSD port to version 0.9 this
weekend, but don't get your hopes up. (Oskar any plans to put GMS under
CVS on savannah?)
Public CVS or SVN sure would be nice! :)
You do not need to do any of that manual multicast route crap on FreeBSD
if you are using my ports/packages for libupnp and GMS (I patched
libupnp code to correctly do an m-cast join on the address passed into
UpnpInit()). If your FreeBSD box is not multihomed (just one network
interface) I don't think you would need to set up m-cast routes or apply
my fixes to libupnp (multicast packets will be sent using the default
route if no more specific route is found, and the m-cast join did not
specify an interface address).
I'll await your port, whenever you get it done. I beleive my routing
table DIDNT have anything for that route in it by default, which is
why it added it. It shouldnt hurt either way, really. I know it's
working with the route in because the Intel SDK tools can see
gmediaserver running (but doing any tests with those tools promptly
*crashes* gmediaserver .8)
--falz