A (real) long time ago, I started to work on a big rework of the whole database schema to improve performance on the one hand and to improve various other things (like maintainability, flexibility, support for DLNA devices) on the other hand.

Yesterday, I finally managed to fix the last bug which affected among other things the LowResourceMode. This allows me to release this new version 0.70.0 of pDLNA.

With this version comes, as already mentioned, a lot of improvements (for instance PostgreSQL support as a database backend).As always, please see the » changelog « section for all changes and to download the new tarball and/or the latest version of the Installation, Configuration and Debugging Guide.

I also decided to move from the closed VMware images to the Open Virtualization Format (OVF) for the » virtual machines images «.

Today pDLNA v0.64.0 has been released, which includes support for a MySQL backend.
The » changelog « section gives a detailed overview regarding all the changes and where to download the release and the Installation, Configuration and Debugging Guide.
There are also updated » VMware images « available.

The current development state of pDLNA reveals a lot of changes, which affect the performance of pDLNA.

At first, I would like to specify my testcase: The ContentLibrary, pDLNA needs to handle, contains 3659 files in 805 directories with a size of 1.55 TB. One of those files is an image and 14 of them are audio files.

At first there is the change of gathering the relevant media information. Version 0.63.0 uses the Perl Module Movie::Info, which uses Mplayer. Since Movie::Info is not part of most repositories, I decided to move to use FFmpeg natively. So Mplayer and Movie::Info is not a dependency to pDLNA any more. As it turns out, FFmpeg is faster than Movie::Info and Mplayer. This performance difference can be seen in the following graph. The first two bars show the difference between using Mplayer and FFmpeg.

The next step to improve the performance of pDLNA was to disable AutoCommit in the database for inserting all the MediaItems initially. So when inserting all the MediaItems initially to the database, a commit will be done after each directory. And when inserting the details from FFmpeg to the Database, a commit will be done after every 50 MediaItems. This performance improvement can be seen in the graph above, where the bars two and three show the mentioned test results.

And the last bar in the graph above shows the test results, when using MySQL as a database backend. Gathering the details with FFmpeg has not been improved since opening every single file depends on the disc IO, which is the bottleneck in this functionality. But if you compare pDLNA in v0.63.0 and pDLNA v0.64.0b with a MySQL database, the initial time to store all available MediaItems in the database decreases from around 280 seconds to about 10 seconds.

And finally, the graph below, shows the amount of time, which is needed to get a full DirectoryListing of all MediaItems with VLC media player. The graph shows the performance enhancement, when a MySQL database (instead of a SQLite3 database) is used.

pDLNA v0.64.0 will be released soon. So stay tuned.

Today pDLNA in version 0.63.0 has been released. It includes a lot of improvements, some bug fixes and some less dependencies. The » changelog « section gives a detailed overview regarding the changes and where to download the release and the Installation, Configuration and Debugging Guide.
There are also new/updated » VMware images « available, especially the Debian VMware image has been reinstalled with Debian 7.

Since the release of pDLNA v0.60.0 had a problem with different versions of the SQLite Perl modules, the new version 0.60.1 has been released, which solves this issue.
For more details have a look into the » changelog « section or even download on of the prepared » VMware images « to test the new version (which will be available in a few hours).