Many users of mediatomb are annoyed by the 2 GB file size problem.
From the threads on that topic I learn that part of the problem is the libupnp itself and mediatomb is using the version from Intel?
Might this alternative help solve the problem:
This is not an "alternative" libupnp version - it is the one that we are using. The difference is that we added some patches to improve support for the DSM-320 renderer and we also changed some configuration settings in order to improve the performance of the internal webserver.
Recently a patch for largefile support was posted to the libupnp page - so in that point you are right - we can use that. However, the libupnp project itself is in a desolate condition, it seems that it is not really being maintained. For that reason we are moving libupnp sources into the MediaTomb project tree. This will allow us to apply patches and make changes to the library as we need them. I already finished the integration process and created an autotools environment, next step will be to look at the patches that were submitted for libupnp and integrate them. After that adaptions to the MediaTomb sources will be made, in order to use those new libupnp features.
So yes - you can expect a fix for the 2GB problem, that is definetely something that we want to have.
I am the author of the largefile patch for libupnp and should point out that it is not suitable for production yet as the cross platform largefile handling is flawed and requires more work.
Although it is true that the previous developers are no longer actively maintaining libupnp, there are some new developers who are keen to progress with improvements. I and others hope to take a more active role in the maintenance of the source code.
I can understand the frustration with the lack of progress in making improvements to libupnp and if I don't see a willingness by the previous developers to allow active maintenance then I will fork the library into a new project.
It would be a shame to fork libupnp into a subset of mediatomb where the code would likely lose some of its separation and become mediatomb specific. I see that as diluting the already thin development support for upnp even further.
As an aside, you may be disappointed with largefile support as even though the specification states a file size may be more than 32 bits, I suspect a number of hardware and software players and media servers have taken a short cut and used 32 bits.
I have seen this behaviour with Nero ShowTime (but interestingly not Nero Home) and the ushare and mediatomb media servers.
I have updated ushare to support largefiles and it is kind of interesting streaming an ISO image. Bear in mind you don't get much out of this since a player needs to support this method of access to an ISO and there are no media tags (yet...). It will certainly be useful for higher quality avi rips.
Hi, I know that you made the patch, I guess you missed my post:
I indeed had concerns regarding cross platform compatibility, so I am not taking the patch 1:1 but keeping the old implementation along with the new one (using #ifdefs). Unfortunately I could not yet figure out what what defines I should look for. It all seems a little weird, certain defines enable access to certain system functions and so on. If you have any hint - let me know :>
You are also saying that it does not yet have production quality, could you be more precise, what exactly is missing? I did not apply it yet, still finalizing the autotools environment but I think that I will start tomorrow.
Now, regarding libupnp:
I created a nested autotools environment for the library, so it could easily be taken out of our sourcetree. Allthough creation of static libraries and use of libtool is currently disabled, it would not be much effort to put it back in.
But indeed you are right - we made this move in order to be able to apply patches and make required changes as wee see fit, without fearing to break the systemwide library.
Actually we have plans to write our own UPnP SDK, but that will not happen anytime soon, currently MediaTomb development has our full attention.
However, we do plan to keep the separation between the SDK and MediaTomb. Not only because the SDK is written in C, while MediaTomb is written in C++, but also because we want to be able to easily replace the SDK at some point without having to change much in the MediaTomb code. This means that the changes and imrovements that we make could be taken back to the original library.
By the way, we are evaluating the possibility of relicensing our forked SDK under LGPL (probably, like FLTK, with exception to allow static linking). I have to read through all those legal issues, but as far as I know the original BSD license would allow this move.
I also read your post (at least I assume that it is you :) on the UPnP mailing list and I think it would be very good if someone who is interested in active maintanence would take over the project.
Yeah it was me on the upnp list. May have been a bit bold but I hate procrastination.
The problem with the patch relates to my use of off_t. The largefile dilemna is nicely summarised here:
Ah as long as you are keeping it separate that is great as any contributions can be rolled back into the general library.
I've add ushare to the NSLU2 feed which provides a nice lightweight upnp media server on this hardware. I intend to try getting mediatomb up and running on it too but it is a bit more work.
When will you be moving mediatomb to public svn?
Thanks for the link, I'll study hat before doing any further integration.
Regarding NSLU2, take a look at this thread:
Someone already compiled MediaTomb under OpenSlug for the NSLU2, as far as I remember no changes to the sourcecode were required, just some config.xml tweaking, that's it.
Regarding public svn, I remember SF was doing a beta run, I have to check if it is already deployed for production. Anyway, we will not move the sources before the upcoming release. I can not tell you any exact date but we are making good progress and are on the way.
I've updated my patch for libupnp in line with the largefile recommendations.
I saw that someone had mediatomb running on openslug but building a package so joe blow can run it on unslung is a rather different matter. That said, I'm in the process of doing so.
Ok, I will use your latest patch then. By the way, I did not know that libupnp was already autoconfed, I guess I could have saved myself some work :)
But well, to be honest I am still not sure if I should use a nested configure environment or integrate the library into the mediatomb configuration.
Regarding NSLU2 - that's great! I would be happy to see an easy to install package.
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.