[APP] MiniDLNA original/patched for firmware V4+ (08/2017)

#89

diaahussein wrote:

@Nazar

 

great work my Man

 

I have started hosting a reprosatory for v4+ patched software if you wish to contribute please let me know

 

it is on http://diaa.ni-ip.com:8080

 

it would be great to have your binaries there for all the people

 

cheers

 

 

My builds are not standardized. Most not included with the dependencies flags so not suitable for repositories. I built them as my own liking haha. I believe Fox_exe is the correct person if you would like to sync repos.

#90

I have already syncup Fox_exe repo

I was trying to add yours too because you have some updated binaries like miniDlna 1.1.4 and 1.1.3 with the patches

Nazar78 wrote:

My builds are not standardized. Most not included with the dependencies flags so not suitable for repositories. I built them as my own liking haha. I believe Fox_exe is the correct person if you would like to sync repos.

#91

I’v built minidlna versions 1.0.25 and 1.1.4 for the DNS-323 and for a debian 386 system with a few problems doing the configure.  But in the end they all built and worked as designed.  But on the debian system with the WD build that will build

htop.  Even after getting the configure to work.  I get dozens of errors doing the make.  I know that the problem is not in the source.  Its either in the config.h file or the build environment.  every DPRINTF statement gets the following warning:

upnpsoap.c:1907:3: warning: deprecated conversion from string constant to ‘char*’ [-Wwrite-strings]

None of these messages occur with the other builds.  I know that if I add -w to the compile statement these messages will not appear.  But then I get the following errors:

upnpsoap.c:1894:24: error: invalid conversion from ‘const char*’ to ‘char*’ [-fpermissive]

My question is if htop builds what is the problem with minidlna?

Thanks  RAC

#92

@rac8006

htop is quite easy to build compared to minidlna. I suggest you take a look at the thread on my signature. Somewhere in it there’s a discussion about preparing debian environment for the 64k patch builds.

#93

Please excuse my lack of knowledge on this forum.  You said to see your thread on your signature?  Not sure what this means.  Also previously you said debian repo: ?  Could you show the source.list statement for that repo?

Thanks RAC

#94

@rac8006

I’m referring to the repo on a standard debian install:

deb  http://ftp.debian.org/debian wheezy main

deb-src  http://ftp.debian.org/debian wheezy main

This link on my signature:

https://community.wd.com/t5/WD-My-Cloud/GUIDE-Building-packages-for-the-new-firmware-someone-tried-it/m-p/769299

#95

Where did these deb files come from.  I went thru the process to get the minidlna-1.1.4 files or I thought.  I was able to

unzip and install the minidlna program but it didn’t install any of the libraries. 

Did I download the wrong files? 

RAC

#96

@rac8006

I don’t understand, are you trying to install from the repo? From my understanding you’re trying to compile from source. This means you’ll need to also compile all the dependencies to produce the binaries.

#97

I’m confused.  Yes I’m trying to compile minidlna-1.1.4.  I have actually been able to compile the program after I redid

the build setup.  I was trying to build using a amd64 build environment.  So I created a 32 bit environmment.  It built the

first time.

On the first page of this thread it says to go to your site to get a credential.  Then download the minidlna install code.

Which I did.  I then installed to program to MY Cloud.  When I tried to run it I was missing the libraries.    In the third

entry on page one shows all of the libraries being installed.  I was wondering how these libraries were being installed.

AS you klnow I have built version 1.1.4 for the DNS-323 and its working fine.  I’ve now built version 1.1.4 after following the

instructions mauromol posted at http://community.wd.com/t5/WD-My-Cloud/GUIDE-Building-packages-for-the-new-firmware-someone-tried-it/m-p/770653#M18650.  I only created the wheezy4k and wheezy64k folders.  After following

these instructions I was able to run configure and it worked the first time after I installed the libraries.  Not sure why the code fails to run on the MY Cloud.  It gets a sigkill as soon as it starts to run.  It dosen’t even get to trying to load the first library.  It should have displayed an error that the library was missing.

Thanks  RAC

#98

@rac8006

You said you were missing the libraries when you tried to run MiniDLNA from my installer from the first page of this thread, which libraries were missing? What is your WDMyCloud current firmware version?

If you get SIGKILL when you try to run the ones you built on WDMyCloud, it means your 64K patch build wasn’t successful. Though it will work on the normal 4K page size kernel i.e. firmware V3.

#99

When I did the install of minidlna-1.1.4_static.tar.  It installed /etc/minidlna.conf /usr/sbin/minidland and the share/locale files.  No libraries were installed.  My My Cloud is version .421. 

I’m not is the process of trying to build all of the dependencies.  But I’m not sure what the dependencies are.  I’m going to use the list of libraries installed from page 1.  Either I’m not very smart or the information to build minidlna-1.1.4 is not complete.  On the first page it shows the library files being installed.  But does not show the command to start the install.

It would be nice to know the necesssary apt-get source command to get the necessary dependencies. 

What I’ve been doing is doing a apt-cache search library name.  Looking for the packages to load.  Also not sure what should be in the sources.list to get the correct files for the wd build environment. 

I have two 6TB clouds.  Both are basic out of the box systems running -421 frimware.  They both have the exact same sources.list file.  But one system will install the libraries.  But the other can’t find the libraries.  I don’t think the sources.list file is correct.  Yet when I used apt-get to install the necessary libraries.  They were loaded.  minidlna-1.1.4 is working on the one My Cloud. 

I did the build in the 64k-wheezy folder.  Are you saying that it actually built the 4k version?  What tells the build to do 4k or 64k versions.  Either it is a compile time option or it is based on the current compiler being used.  Not sure what mistake I made while setting up the build environment.  I suspected that since the program failed so quick that it might be a 4k version.  I don’t know it there is a way to tell if a pogram is built using 64k or 4k.

/etc/apt/sources.list

deb http://ftp.us.debian.org/debian/ jessie main

Note, wheezy is not 64K page aligned.

##deb http://ftp.us.debian.org/debian/ wheezy main
#deb http://ftp.us.debian.org/debian/ sid main
#deb http://ftp.us.debian.org/debian/ experimental main
#deb-src http://ftp.us.debian.org/debian/ jessie main

Thanks for your help.

RAC

#100

@rac8006,

I think you’re confused. If you’re building a static builds (cross-compile with the 64k patched cross-tool), you should not have to install any extra debs on your WDMyCloud. Get their tar source ready extracted in your build environment before you configure MiniDLNA so the config can include them. Then if successful, proceed to make.

When you mentioned 64k-wheezy folder (think you derived from the posted guide to build 64K), and debs from the first page, this is not cross-compiling and you can’t get static builds using this method in the guide. Even for this method you will need to individually build every dependencies you see on the first page.

#101

Yes I am confused. I was under the impression that to build minidlna-1.1.4.  I needed to create a cross compile build

environment.  So I have a i386 PC.  I installed Debian linux 32bit on the system.  After that I followed the instructions

to create the build environment.  At this point I installed the source for minidlna-1.1.4.  I then ran the configure.  Which

got errors saying the different libraries were missing.  So I’m not building on the MY Cloud.

OK question 1 after installing minidlna-1.1.4 to My Cloud.  I got errors when I tried to run the progam saying the libraries were missing.  So how do I get the necessary libraries on My Cloud.  I thought that is what the installes on page one were being used for.

Question 2.  What is the proper procedure to create a build environment to firmware 421. 

Question 3 Is the following instructions correct to create a poper buikld environment?

Once the guest VM is installed, we need to make just a couple little tunings. First of all, Debian Wheezy comes with qemu-user-static package version 1.1.2. Qemu is an environment needed to emulate an actual ARM system on another platform, like the AMD64 platform our build system consists of. It’s a good idea to update Qemu to version 2.x from the wheezy-backports repository. To do this, start the build system and login. Then:

sudo su

echo “deb http://ftp.debian.org/debian wheezy-backports main contrib non-free” >>/etc/apt/sources.list

apt-get update

apt-get -t wheezy-backports install qemu-user-static

This should also install binfmt-support, which is another packages needed by the build environment. If this is not the case, also type:

apt-get install binfmt-support

Now, let’s prepare the actual build environment. Let’s create a folder in the /root directory of the build system and download the WD My Cloud 4.x firmware source package from WD website.

cd /root

mkdir wdmc-build

cd wdmc-build

wget http://download.wdc.com/gpl/gpl-source-sequoia-04.00.00-607.zip

In case the link changes, refer to WD My Cloud support page to find the new one: http://support.wdc.com/product/download.asp?groupid=904&lang=en

I then suggest to create different folders for different build scenarios. These are the possibilities:

the target system may be firmware 3.x (4k) or firmware 4.x (64k)

the source package base may be wheezy (Debian stable) or jessie (Debian testing); wheezy contains older packages, but that should run happily in My Cloud (which has a Wheezy in it!), while jessie contains newer packages that might also work and provide updated versions of many applications; I would personally recommend to build packages from wheezy, unless you absolutely need a newer version that is only in jessie

I don’t recommend to mix things, so I would create different folders for any different combination. You’re free to create just the one you are interested in, so among the following commands type fhe first ones, then only the block of commands of the combination(s) you’re interested in, then the last command:

cd /root/wdmc-build

unzip gpl-source-sequoia-04.00.00-607.zip packages/build_tools/debian/*

mkdir 64k-wheezy

cp -R packages/build_tools/debian/* ./64k-wheezy

echo ‘#!/bin/bash’ >>64k-wheezy/build.sh

echo ‘./build-armhf-package.sh --pagesize=64k $1 wheezy’ >>64k-wheezy/build.sh

chmod a+x ./64k-wheezy/build.sh

mkdir 64k-jessie

cp -R packages/build_tools/debian/* ./64k-jessie

echo ‘#!/bin/bash’ >>64k-jessie/build.sh

echo ‘./build-armhf-package.sh --pagesize=64k $1 jessie’ >>64k-jessie/build.sh

chmod a+x ./64k-jessie/build.sh

mkdir 4k-wheezy

cp -R packages/build_tools/debian/* ./4k-wheezy

echo ‘#!/bin/bash’ >>4k-wheezy/build.sh

echo ‘./build-armhf-package.sh --pagesize=4k $1 wheezy’ >>4k-wheezy/build.sh

chmod a+x ./4k-wheezy/build.sh

mkdir 4k-jessie

cp -R packages/build_tools/debian/* ./4k-jessie

echo ‘#!/bin/bash’ >>4k-jessie/build.sh

echo ‘./build-armhf-package.sh --pagesize=4k $1 jessie’ >>4k-jessie/build.sh

chmod a+x ./4k-jessie/build.sh

rm -rf packages/

In this way, in every folder will be created a build.sh script that passes the right parameters to the WD provided script, requiring only the name of the package to build. This would work straight away if there weren’t the problem with qemu I mentioned in the beginning, so another step is required to finish the prepare phase. Again, only type commands for the scenario(s) you’re interested in:

64k-wheezy:

cd /root/wdmc-build/64k-wheezy

./setup.sh bootstrap/wheezy-bootstrap_1.24.14_armhf.tar.gz build

mv build/usr/bin/qemu-arm-static build/usr/bin/qemu-arm-static_orig

cp /usr/bin/qemu-arm-static build/usr/bin/qemu-arm-static

64k-jessie:

cd /root/wdmc-build/64k-jessie

./setup.sh bootstrap/jessie-bootstrap_5.14.14_armhf.tar.gz build

cp /usr/bin/qemu-arm-static build/usr/bin/qemu-arm-static

4k-wheezy:

cd /root/wdmc-build/4k-wheezy

./setup.sh bootstrap/wheezy-bootstrap_1.24.14_armhf.tar.gz build

mv build/usr/bin/qemu-arm-static build/usr/bin/qemu-arm-static_orig

cp /usr/bin/qemu-arm-static build/usr/bin/qemu-arm-static

4k-jessie:

cd /root/wdmc-build/4k-jessie

./setup.sh bootstrap/jessie-bootstrap_5.14.14_armhf.tar.gz build

cp /usr/bin/qemu-arm-static build/usr/bin/qemu-arm-static

The meaning of the above is the following: prepare an emulated ARM system and replace the qemu-arm-static binary provided by the bootstrap with the recent one we’ve installed in our actual build system.

Ignore any errors produced by setup.sh: that script is really buggy and many things it tries to do seem to be useless, unless we apply the mentioned qemu fix.

As a final step, I would recommend to edit the sources file list within the armhf build subsystem in order to be able to build packages that are in any of the distribution repositories. To do this, type the following:

cd /root/wdmc-build

nano /build/etc/apt/sources.list

by replacing with the desired one (64k-wheezy, 64k-jessie, 4k-wheezy, 4k-jessie); the nano editor will open, then replace the contents of the existing file with the following:

For 64k-wheezy and 4k-wheezy:

deb http://security.debian.org/ wheezy/updates main contrib non-free

deb-src http://security.debian.org/ wheezy/updates main contrib non-free

deb http://ftp.debian.org/debian wheezy-updates main contrib non-free

deb-src http://ftp.debian.org/debian wheezy-updates main contrib non-free

deb http://ftp.debian.org/debian wheezy main contrib non-free

deb-src http://ftp.debian.org/debian wheezy main contrib non-free

#deb http://ftp.debian.org/debian wheezy-backports main contrib non-free

#deb http://ftp.debian.org/debian wheezy-backports main contrib non-free

For 64k-jessie and 4k-jessie:

deb http://security.debian.org/ jessie/updates main contrib non-free

deb-src http://security.debian.org/ jessie/updates main contrib non-free

deb http://ftp.debian.org/debian jessie-updates main contrib non-free

deb-src http://ftp.debian.org/debian jessie-updates main contrib non-free

deb http://ftp.debian.org/debian jessie main contrib non-free

deb-src http://ftp.debian.org/debian jessie main contrib non-free

In case of wheezy, uncomment the last two lines if you want to build package versions from wheezy-backports. I don’t know however if additional changes to the build.sh script (or better to the WD provided one) are needed to instruct apt to download and build the source from the backports repository. I don’t have tried it yet. Anyway, I would recommend to leave those two lines commented unless you actually need something from the backports repository.

Save the file by hitting Ctrl+X, Y, Enter.

Now you’re ready to build your first package!

Optional additional step (not strictly required) for wheezy scenarios

You may also want to use an updated C++ compiler to build packages in the wheezy scenarios. Debian Wheezy provides g++ package 4.6, but 4.7 is also available. With the following commands you can install the new version and then switch from one to the other using update-alternatives:

cd /root/wdmc-build/

chroot build

apt-get update

apt-get install g++ g+±4.7

update-alternatives --install /usr/bin/g++ g++ /usr/bin/g++.4.6 10

update-alternatives --install /usr/bin/g++ g++ /usr/bin/g+±4.7 20

update-alternatives --install /usr/bin/gcc g++ /usr/bin/gcc-4.6 10

update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-4.7 20

rm /usr/bin/cpp

update-alternatives --install /usr/bin/cpp cpp /usr/bin/cpp-4.6 10

update-alternatives --install /usr/bin/cpp cpp /usr/bin/cpp-4.7 20

exit

After these commands, the default C++ compiler will be version 4.7. You can then switch to the old version by typing:

cd /root/wdmc-build/

chroot build

update-alternatives --set cpp /usr/bin/cpp-4.6

update-alternatives --set gcc /usr/bin/gcc-4.6

update-alternatives --set g++ /usr/bin/g+±4.6

exit

#102

@rac8006

  1. Where did you get the minidlna-1.1.4? Was this from your attempt to build it yourself? If yes then you’re missing a lot of stuffs which why the program failed to run due to missing libraries. How to get them? You need to manually build them like how you did for minidlna-1.1.4, every each of them. They doesn’t get built automatically when you build minidlna-1.1.4 alone.

2-3) The ones you posted (and understood) seems extracted from the 64k build guide in this thread http://community.wd.com/t5/WD-My-Cloud/GUIDE-Building-packages-for-the-new-firmware-someone-tried-it/m-p/770653#M18650 and yes you should follow the OP’s guide in that thread to prepare the build environment.

#103

I followed the instructions on page one of this thread. I downloaded the patched version from your site.  I did not try to build minidlna-1.1.4 for the My Cloud.  I have built it from source on the DNS-323 and it is working as expected.

On the previous install I used apt-get to get the libraries.

OK I just went back to page one and reinstalled minidlna-1.1.4.patched-1.  This time it did install the dependencies.

Not sure why it didn’t do that previously.

I have followed the instructions to create a 64k build environment.  But I did notice some thing strange in the file build-armhf-package.sh script.  It seems to always install the binutil  But never uninstalls them.  Which to me seems like an unnecessary step after the first time.

The source that I’m using for the build came from the Authors site.  Plus I downloaded your two patches. I’m not in a hurry to build minidlna-1.1.4 for the My Cloud.  Since I have a working version. 

Right now I need to figure out why the disk goes into standy a few seconds to a minute and then wakes up again.  If I

stop samba/wdmcserverd/wdphotodbmergerd it starts going to sleep for a few hours.

Thanks for your responses.  They have been helpful.

RAC

#104

@rac8006

The binutil is a 64k patched version. Everytime you run the script, it will be replaced from the bootstrap tar, at least part of it I think (I never checked as I cross-compiled using the old conventional config make).

For the wakeups I’m not sure as my nas is being accessed all the time from my installers, hosted sites and other custom jobs.

#105

I’ve found that after the first time thst you run there script.  It is only necessary to do the code in the script

from the chroot thru the EOF.    Where the apt-get update and the apt-get source --compile.  I just striped those lines

and put them in a smaller script.  It works just fine.

I’ve built the dependencies.  Though the libav build took more time than it takes to rebuild  the entire UnixWare

tree.  But I now can compile minidlna-1.1.4 and run it on my My Cloud.  I just need to verify that the notification is working

correctly.

As for the wakeups.  It has something to do with the samba.  If samba is running and another pc has access to one of

the shared folders it seems to write to disk every minute.  If samba is not running.  The drive will go to sleep for several

hours at a time.  Though there are times that it will enter standy mode and 8 seconds later it will wake up again.  I can’t

seem to find what samba is writting yet.

Thanks for your help.

PS not sure it means anything but I was able to backup My Cloud and restore it to a foler on my debian build system.  I then was able to chroot to that folder and run commands.

#106

@rac8006

Glad it works for you, do remember to enable back the binutils installation if you were to clear the bootstrap else it will still be 4K and won’t run on 64K firmware. I’m doing a different approach which is by loading the entire bootstrap into a dedicated ram space and do the config make there. I prefer this as it’s faster on ram. On top of that, I’m able to multi-thread in the make job process utilizing 100% of all available CPUs, i.e. 8 concurrent compile threads at once in conjunction with the number of logical CPUs.

Yes, you also would be able to loop mount and chroot into the original rootfs from V4 firmware on your Debian build system. The V4 rootfs also works on WDMyCloud itself, though you’ll need to extract the rootfs as WDMyCloud kernel wasn’t compiled with loop mount. But you’ll not be able to do it the other way round, i.e. 4K bootstrap on the 64K WDMyCloud.

#107

Hi,

First, a big thank you to Nazar for this great work.

I’ve installed MiniDLNA trying to solve this problem, everything went smooth, but MiniDLNA does not support pictures keywords (I think), which is the main reason I want a DLNA server.

So… how can I completly uninstall MiniDLNA (or at least stop it from running) or make it search keywords in my jpeg files?

Thanks in advance.

#108

@jopereira

I’m not sure about keyword search support as I’m using only directly from my smart tv to browse.

You can uninstall the main app itself but I do not recommend removing the installed dependencies as I cannot confirm if it would break something else.

dpkg --purge minidlna