I've put together a patch that allows mediatomb 0.8.1 to compile on freebsd 6.x, and also adds a postgresql storage driver. The storage driver seems pretty messy, I messed around with libpqxx a while but couldn't make it work well enough within the expected framework, so I went straight with the C library.
For configure to work, you still need to set LDFLAGS=-L/usr/local/lib and
CPPFLAGS=-I/usr/local/include.
The other issue that remains is with multiple clients... Mediatomb only seems to allow one concurrent connection, whether browsing or streaming. I'm assuming this is a problem with libupnp and not mediatomb because I see the same issue with gmediaserver.
well.. I do not know how to say this, but this seems like a wasted effort... the upcoming 0.9.0 will support *BSD, further - the code and the database have undergone significant changes, so I doubt that it will be possible to easily integrate 0.8.x-storage postgresql changes into the 0.9.0 codebase.
I do admit, that we are responsible for this situation because our SVN is not on SourceForge, however, we plan to check in the 0.9.0 codebase to SF SVN this year.
Still, nice that you were interested enough to hack around :)
By the way, the multiple client issie is solved in 0.9.0, libupnp is not integrated into our code and I added quite a few patches to fix various issues and extend functionality. You should also have more fun with configure now, it has been improved a lot!
So let's hope we can keep our promise, the major blocks are already solved and I am confident that we will have some testable pre-prerelease code ready this year :)
Greetings,
Jin
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
no ofense, but I'don't think it is wasted effort. The *BSD support was announced and morganw apparently wanted it urgently, and took the calculated risk to implement it in parallel, and by the way, got there before you ;-)
IIUC, 0.9.0 will not support postgres, therefore the patch will be a good starting point, no matter how hard it would be to integrate.
Regarding the multiple clients issue and libupnp. Could you please clarify if the issue was indeed with libupnp or mediatomb in the first place ? AFAICT, libupnp has no such restriction.
When you say libupnp is not integrated into your code you mean that it remains a separate library you link against or that you don't use it at all?
Finally, my best wishes for you to reach your goal and have a shiny 0.9.0 release this year.
nek
who knows how much effort and love(?) you've put in this release.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
well hehe :) I guess what I was trying to say is, that the BSD patch can not be applied to 0.9.0 not only because the support is already there, but also because a lot has changed. I'm really happy that morganw was interested in this that he hacked 0.8.1... I of course do not know how long it took, I just had doubts that it was worth it considering that we are about to make the code public. On the other hand - we are probably known for missing deadlines and indeed - he now has a working version :)
Regarding libupnp, maybe I did a typo or something, I meant that libupnp *is* integrated into our source tree. The "restriction" is a bug in libupnp threading, I do not remember it in detail now, it took quite a while until I figured out what it was. Basically it did not launch new threads when all jobs were busy, I'll have to look it up, it was somewhere in the depths of the threadutil part. By the way, have you come to a conclusion - will pupnp be rereleased under LGPL or is it staying under the BSD license?
Thanks, we indeed put *a lot* of effort into this! What we promise is, to move the code to SourceForge SVN this year. The official release will probably take a little longer, but with most functionality present people can already start testing and hacking so we could get going with a prerelease early june.
Greetings,
Jin
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
no need to dig about the thread bug. I believe we have this fixed in trunk, although we didn't get there as a problem with multiple-clients, but as problem with applications acting as control-point and devices at the same time.
The license discussion didn't reach to any conclusion. The last post is from me a month ago, stating exactly that and asking about GPL+exception in place of LGPL.
I think, I'll be awfully offtopic if I say word more.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hmm, I will have to check... I do check out your trunk from time to time and look for bugfixes, I have not done so in the
recent couple of weeks, I guess I will have a look today. As far as I remember this was an internal ThreadPool think though,
so I do not think that it was sdk-client/sdk-server related. The problem was that an incoming job was delayed if all worker therads were busy, even if the maximum thread setting in the config was of some higher value.
By the way, I also rewrote the socket code - it was using blocking IO, with some renderers which did not properly shutdown the TCP connection the socket was hanging around, so the worker thread that was serving content via that socket was blocked for quit some time. This was an issue when shutting down the server - it hung indefinetely.
Well.. I guess we both are on the wrong list here :)
Talk to the other project members and simply decide... go LGPL, then we can merge our efforts :) As far as I remember the overall feedback on the lists about this was quite positive.
Greetings,
Jin
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ooops, I did a quick check on the log and didn't find it. I'am sure we had a patch and a long discussion about it on the old forum, but this probably was never commited. I'll have to dig in my work dir to find it. I'll let you know.
Anyway, the case was that a single process was acting as both device and control-point, this was a dead-lock when as CP attempted to send an action request while serving another one as a device.
I'll contact the members for the license...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well unless 0.9 was released last week with postgres support, I don't consider it a waste to avoid installing Linux and mysql. I'll just make a postgres driver for the new version whenever that comes out... Just try to avoid mysql-specific clauses like LIMIT X,Y.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK, you got a point there. On the other hand - you could have simply asked :) We gave out one or two test versions to BSD users to see if everything is working as it should.
I can't comment on the mysql specific stuff, I guess this is a question for Leo. I know that he is trying to optimize each database driver as much as possible. I also know that the database structure has changed a lot, but again - this is a question for Leo :)
Greetings,
Jin
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think that won't make much sense now, because we will move our (private) SVN repository to the public SourceForge SVN repository in a few days. Our deadline for the migration to SF is currently the 26th of December, so you'll have the full and always up-to-date code in five days anyways. Until then we want to commit some important fixes and update the copyright headers. I hope you can wait five more days :)
Thank you in advance for making mediatomb work with PostgreSQL. I've actually planned to do this for quite some time, but I've always found "more important" things to do :)
By the way: thanks for pointing out the "LIMIT" issue. In the current development code we use "LIMIT ... OFFSET"; I think that should work with most DBMS. The SQL we use is quite simple, so I think there shouldn't be any more compatibility issues.
greets, Leo
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi all,
I've put together a patch that allows mediatomb 0.8.1 to compile on freebsd 6.x, and also adds a postgresql storage driver. The storage driver seems pretty messy, I messed around with libpqxx a while but couldn't make it work well enough within the expected framework, so I went straight with the C library.
For configure to work, you still need to set LDFLAGS=-L/usr/local/lib and
CPPFLAGS=-I/usr/local/include.
The other issue that remains is with multiple clients... Mediatomb only seems to allow one concurrent connection, whether browsing or streaming. I'm assuming this is a problem with libupnp and not mediatomb because I see the same issue with gmediaserver.
Anyway, the patch can be found at http://files.chemikals.org/mediatomb-fbsd.patch.gz.
I can also report that mediatomb works flawlessly with a D-Link DSM-520.
Er, that link obviously shouldn't have a trailing period:
http://files.chemikals.org/mediatomb-fbsd.patch.gz
Hi,
well.. I do not know how to say this, but this seems like a wasted effort... the upcoming 0.9.0 will support *BSD, further - the code and the database have undergone significant changes, so I doubt that it will be possible to easily integrate 0.8.x-storage postgresql changes into the 0.9.0 codebase.
I do admit, that we are responsible for this situation because our SVN is not on SourceForge, however, we plan to check in the 0.9.0 codebase to SF SVN this year.
Still, nice that you were interested enough to hack around :)
By the way, the multiple client issie is solved in 0.9.0, libupnp is not integrated into our code and I added quite a few patches to fix various issues and extend functionality. You should also have more fun with configure now, it has been improved a lot!
So let's hope we can keep our promise, the major blocks are already solved and I am confident that we will have some testable pre-prerelease code ready this year :)
Greetings,
Jin
Hi Jin,
no ofense, but I'don't think it is wasted effort. The *BSD support was announced and morganw apparently wanted it urgently, and took the calculated risk to implement it in parallel, and by the way, got there before you ;-)
IIUC, 0.9.0 will not support postgres, therefore the patch will be a good starting point, no matter how hard it would be to integrate.
Regarding the multiple clients issue and libupnp. Could you please clarify if the issue was indeed with libupnp or mediatomb in the first place ? AFAICT, libupnp has no such restriction.
When you say libupnp is not integrated into your code you mean that it remains a separate library you link against or that you don't use it at all?
Finally, my best wishes for you to reach your goal and have a shiny 0.9.0 release this year.
nek
who knows how much effort and love(?) you've put in this release.
Hi Nek,
well hehe :) I guess what I was trying to say is, that the BSD patch can not be applied to 0.9.0 not only because the support is already there, but also because a lot has changed. I'm really happy that morganw was interested in this that he hacked 0.8.1... I of course do not know how long it took, I just had doubts that it was worth it considering that we are about to make the code public. On the other hand - we are probably known for missing deadlines and indeed - he now has a working version :)
Regarding libupnp, maybe I did a typo or something, I meant that libupnp *is* integrated into our source tree. The "restriction" is a bug in libupnp threading, I do not remember it in detail now, it took quite a while until I figured out what it was. Basically it did not launch new threads when all jobs were busy, I'll have to look it up, it was somewhere in the depths of the threadutil part. By the way, have you come to a conclusion - will pupnp be rereleased under LGPL or is it staying under the BSD license?
Thanks, we indeed put *a lot* of effort into this! What we promise is, to move the code to SourceForge SVN this year. The official release will probably take a little longer, but with most functionality present people can already start testing and hacking so we could get going with a prerelease early june.
Greetings,
Jin
Hi Jin,
no need to dig about the thread bug. I believe we have this fixed in trunk, although we didn't get there as a problem with multiple-clients, but as problem with applications acting as control-point and devices at the same time.
The license discussion didn't reach to any conclusion. The last post is from me a month ago, stating exactly that and asking about GPL+exception in place of LGPL.
I think, I'll be awfully offtopic if I say word more.
Hmm, I will have to check... I do check out your trunk from time to time and look for bugfixes, I have not done so in the
recent couple of weeks, I guess I will have a look today. As far as I remember this was an internal ThreadPool think though,
so I do not think that it was sdk-client/sdk-server related. The problem was that an incoming job was delayed if all worker therads were busy, even if the maximum thread setting in the config was of some higher value.
By the way, I also rewrote the socket code - it was using blocking IO, with some renderers which did not properly shutdown the TCP connection the socket was hanging around, so the worker thread that was serving content via that socket was blocked for quit some time. This was an issue when shutting down the server - it hung indefinetely.
Well.. I guess we both are on the wrong list here :)
Talk to the other project members and simply decide... go LGPL, then we can merge our efforts :) As far as I remember the overall feedback on the lists about this was quite positive.
Greetings,
Jin
Ooops, I did a quick check on the log and didn't find it. I'am sure we had a patch and a long discussion about it on the old forum, but this probably was never commited. I'll have to dig in my work dir to find it. I'll let you know.
Anyway, the case was that a single process was acting as both device and control-point, this was a dead-lock when as CP attempted to send an action request while serving another one as a device.
I'll contact the members for the license...
Well unless 0.9 was released last week with postgres support, I don't consider it a waste to avoid installing Linux and mysql. I'll just make a postgres driver for the new version whenever that comes out... Just try to avoid mysql-specific clauses like LIMIT X,Y.
OK, you got a point there. On the other hand - you could have simply asked :) We gave out one or two test versions to BSD users to see if everything is working as it should.
I can't comment on the mysql specific stuff, I guess this is a question for Leo. I know that he is trying to optimize each database driver as much as possible. I also know that the database structure has changed a lot, but again - this is a question for Leo :)
Greetings,
Jin
Well, pass me one along and I'll get working on a postgres driver for it.
I think that won't make much sense now, because we will move our (private) SVN repository to the public SourceForge SVN repository in a few days. Our deadline for the migration to SF is currently the 26th of December, so you'll have the full and always up-to-date code in five days anyways. Until then we want to commit some important fixes and update the copyright headers. I hope you can wait five more days :)
Thank you in advance for making mediatomb work with PostgreSQL. I've actually planned to do this for quite some time, but I've always found "more important" things to do :)
By the way: thanks for pointing out the "LIMIT" issue. In the current development code we use "LIMIT ... OFFSET"; I think that should work with most DBMS. The SQL we use is quite simple, so I think there shouldn't be any more compatibility issues.
greets, Leo