minidlna not working on reboot?

[obs0lete]

Hi here!

I've recently got my hands on an RT-N66U device and have flashed v380.64 on the router.
After setting up all my details, I wanted to get minidlna working on the device.

These are the steps I took - apologies for the lengthy post, just adding as much detail as I can recall:

1. Under USB Application > Media Services and Server > Media Enable UPnP Media Server is OFF.
2. Connected an ext3 formatted 8GB USB drive (/tmp/mnt/Data) and installed entware on it via entware-setup.sh which was successful.
3. Connected a 500GB drive (/tmp/mnt/NAS) formatted with ext3.
4. Ran opkg install minidlna to install minidlna which worked.
5. Edited /opt/etc/minidlna.conf as needed to point to the proper directories and settings.

Now, when i execute minidlna from an SSH window, the DNLA service is started and I can access it without issue across my network. I then rebooted the router and noticed that I could no longer see DNLA, so I went to the SSH window aagain and run minidlna and it is working again.

I did some research and came across https://github.com/RMerl/asuswrt-merlin/wiki/User-scripts which after reading, looks like I need to add minidlna to post-mount. So I simply added the command at the end of this script like so:

#!/bin/sh

if [ "$1" = "/tmp/mnt/Data" ] ; then
ln -nsf $1/entware /tmp/opt
fi
# Wait 60 seconds in case mount is not seen, then launch minidlna
sleep 60
minidlna
​

The script was already set as an executable, so I rebooted the router but minidlna did not start up. I then went to the SSH window again and executed minidlna but this time it complained that it could not find my media directories. I took a look at the file system and notice that I now had 3 mounts instead of 2:

/tmp/mnt/Data <- 8GB drive, this is ok
/tmp/mnt/NAS <-500GB drive, this is ok
/tmp/mnt/NAS (1) <- Not sure why this is here

Next I removed minidlna from the post-mount script and rebooted. I then checked the file system again and now only see the two mounts. Launching minidlna manually now works again.

What is it that I am doing wrong?
How can I simply get minidlna to launch after a reboot?
Why do I see /tmp/mnt/NAS (1) when modify the script?

Again, apologies for the lengthy post. I'm coming from using a router based with OpenWRT so am fairly familiar with the concepts on asuswrt-merlin but I simply can't get my head around this.

Thank you!

 

[latenitetech]

I'll take a stab at it. I bet the 'sleep 60' is simply not long enough. If that's the case, here's what's happening:

1) Minidlna starts up, and reads your .conf file, which tells it to look for the database on '/tmp/mnt/NAS'.
Either you have the db folder explicitly located on your NAS volume (as in 'db_dir=/tmp/mnt/NAS/…'), or it's defaulting to '/tmp/mnt/NAS/.minidlna'.

2) Your NAS volume has not yet mounted (it's taking longer than 60 secs to get there). Minidlna doesn't find /tmp/mnt/NAS, so it creates that directory, making an assumption that this is a fresh start. It then goes ahead and creates an initial database there. Now it trys to find your media (of which there is none yet), so it just stops media indexing, complaining about missing media. Unfortunately, it has contaminated /tmp/mnt/NAS by creating an empty db there.

3) A few seconds later, your NAS drive finally gets around to mounting, but /tmp/mnt/NAS is no longer an empty directory (recall that a mount point is just an empty directory until it's mounted to). Rather than take it over, or abort the mount, Linux is kind enough to create another mount point that it names NAS(1) that it then mounts your volume to.

I'll quite sure if you were to look closely at /tmp/mnt/NAS you'll find that nearly empty minidlna db, and your real NAS content is mounted to /tmp/mnt/NAS(1).

The simple fix is just make the sleep longer; hell, make it 2 mins, it doesn't really matter so long as you ensure your NAS volume is always mounted before minidlna is started.

A more elaborate fix (and this what I've done), is add some additional logic that prevents minidlna from starting until all of its required media folders are mounted, but that's probably more effort than you're looking for here.

Good luck. Report back if that fixes it for you.

-Mark

 

[latenitetech]

Actually, after thinking about it a little more, I'm going to retract part of what I said. I think the failure scenario is correct, but it's not the timeout value. I believe post-conf is a blocking script in that it won't allow another drive to mount until it's completed its work. So it doesn't matter how long the sleep value is, the NAS drive can't mount until the post-conf call for the Data volume completes and exits. Thus it just hangs there for 60 seconds, minidlna starts (and causes the failure scenario I described), then it exits and NAS probably immediately mounts as NAS(1).

How about you try to put the minidlna start under a block which executes when post-conf is called for the NAS volume? Something like this:

#!/bin/sh

if [ "$1" == "/tmp/mnt/Data" ] ; then
    ln -nsf $1/entware /tmp/opt

    # check if NAS has already mounted, if so, start minidlna
    if [ -e /tmp/mnt/NAS ] ; then
        minidlna
    fi
fi

if [ "$1" == "/tmp/mnt/NAS" ] ; then
    if [ -e /tmp/mnt/Data ] ; then
        # Data has already mounted, OK to start minidlna now
        minidlna
    fi
fi

I think that will work regardless of which volume mounts first. It's a bit crude, and there are certainly more elaborate ways of handling it, but if you're looking for something quick, try it out. One other thought: are you sure minidlna is in your PATH? May need to put the full path to minidlna in that script.

-Mark

 

[obs0lete]

Actually, after thinking about it a little more, I'm going to retract part of what I said. I think the failure scenario is correct, but it's not the timeout value. I believe post-conf is a blocking script in that it won't allow another drive to mount until it's completed its work. So it doesn't matter how long the sleep value is, the NAS drive can't mount until the post-conf call for the Data volume completes and exits. Thus it just hangs there for 60 seconds, minidlna starts (and causes the failure scenario I described), then it exits and NAS probably immediately mounts as NAS(1).

How about you try to put the minidlna start under a block which executes when post-conf is called for the NAS volume? Something like this:

#!/bin/sh

if [ "$1" == "/tmp/mnt/Data" ] ; then
    ln -nsf $1/entware /tmp/opt

    # check if NAS has already mounted, if so, start minidlna
    if [ -e /tmp/mnt/NAS ] ; then
        minidlna
    fi
fi

if [ "$1" == "/tmp/mnt/NAS" ] ; then
    if [ -e /tmp/mnt/Data ] ; then
        # Data has already mounted, OK to start minidlna now
        minidlna
    fi
fi

I think that will work regardless of which volume mounts first. It's a bit crude, and there are certainly more elaborate ways of handling it, but if you're looking for something quick, try it out. One other thought: are you sure minidlna is in your PATH? May need to put the full path to minidlna in that script.

-Mark

Mark,

Thank you for the very detailed reply! I have not had a chance to try your solution, but I will give it a shot and let you know.

 

[elorimer]

Why aren't you having rc-unslung start minidlna?

 

[latenitetech]

Why aren't you having rc-unslung start minidlna?

I didn't see this post yesterday, but you make an excellent point. Since obs0lete said he installed minidlna from entware, that installation would have created a startup file under /opt/etc/init.d (named S90minidlna -- I tried it just to verify). That just complicates the original problem. He's actually got minidlna now being started in 2 places, both causing the same error condition. The entware-installed start-up script has the same problem as the built-in minidlna, in that it just blindly starts up before all the required storage volumes are loaded. The classic solution seen in many threads is just another blind wait (which is what he originally tried to do), or a wait loop checking on required volumes similar to what's in the entware installed services-start. Neither are very efficient solutions.

So, obs0lete, I'm going to offer yet another suggestion: run 'opkg remove minidlna'. Unless there's a specific reason you want v1.1.5-1a (the version currently provided by entware), just run the version that came bundled in the firmware (under /usr/sbin), which is v1.1.6, a newer version anyway. That will remove the extra start-up being done by entware's rc.unslung. Once you've done that, I think the solution I provided earlier should work.

But I also have an amendment to that solution as well:
In the two places where I have the code
"if [ -e /tmp/mnt/[mnt_point] ] ; then" (e.g. /tmp/mnt/NAS)
have a check for an actual folder in the root of each volume, so it will look like:
"if [ -e /tmp/mnt/[mnt_point]/folder ] ; then" (e.g. /tmp/mnt/NAS/Music).

While I think the original version should work (since those mount points are not created until the drive is mounted), checking for an actual folder is a bit safer.

Now, all that being said, that is still not my preferred solution for minidlna. What I came up with is a config that maintains the built-in minidlna and its web GUI functionality (which is actually kind of nice to have), but adds smarts so that it only starts when all required volumes are mounted. And it doesn't rely on arbitrary delays or wait loops. I'm intending to write a how-to for the Wiki, but it's not ready yet. So stay tuned, and obs0lete, keep us informed of your progress.

 

[obs0lete]

I didn't see this post yesterday, but you make an excellent point. Since obs0lete said he installed minidlna from entware, that installation would have created a startup file under /opt/etc/init.d (named S90minidlna -- I tried it just to verify). That just complicates the original problem. He's actually got minidlna now being started in 2 places, both causing the same error condition. The entware-installed start-up script has the same problem as the built-in minidlna, in that it just blindly starts up before all the required storage volumes are loaded. The classic solution seen in many threads is just another blind wait (which is what he originally tried to do), or a wait loop checking on required volumes similar to what's in the entware installed services-start. Neither are very efficient solutions.

So, obs0lete, I'm going to offer yet another suggestion: run 'opkg remove minidlna'. Unless there's a specific reason you want v1.1.5-1a (the version currently provided by entware), just run the version that came bundled in the firmware (under /usr/sbin), which is v1.1.6, a newer version anyway. That will remove the extra start-up being done by entware's rc.unslung. Once you've done that, I think the solution I provided earlier should work.

But I also have an amendment to that solution as well:
In the two places where I have the code
"if [ -e /tmp/mnt/[mnt_point] ] ; then" (e.g. /tmp/mnt/NAS)
have a check for an actual folder in the root of each volume, so it will look like:
"if [ -e /tmp/mnt/[mnt_point]/folder ] ; then" (e.g. /tmp/mnt/NAS/Music).

While I think the original version should work (since those mount points are not created until the drive is mounted), checking for an actual folder is a bit safer.

Now, all that being said, that is still not my preferred solution for minidlna. What I came up with is a config that maintains the built-in minidlna and its web GUI functionality (which is actually kind of nice to have), but adds smarts so that it only starts when all required volumes are mounted. And it doesn't rely on arbitrary delays or wait loops. I'm intending to write a how-to for the Wiki, but it's not ready yet. So stay tuned, and obs0lete, keep us informed of your progress.

This make sense. I didn't realize that it was actually being loaded from two places. Thank you!

Through a series of events, the N66U router I was using is now at my in-laws as their router happened to crap out over the weekend, so I won't be able to test this until next time I am there as they would also need minidlna running - will report back once I have tried this out.

 

[latenitetech]

obs0lete -

I completed my Wiki article on minidlna, it's now available here:
https://github.com/RMerl/asuswrt-merlin/wiki/Minidlna:--Common-Issues-&-Solutions

Take a look at it if you get a chance, and if willing, implement the solution proposed at the bottom of the article in your config. It should work fine, and be a better solution than what I proposed to you earlier.

Feedback welcome of course, both on the article, and the proposed solution.

-Mark

 

[elorimer]

Wow, that is a lot of work. I'll go through it slowly and try it out. I've noticed some significant differences in the way my Rpi serves up its files and AsusWrt serves up its files.

In the meantime, two things. First, I wouldn't call the built-in entware install script outdated. It is true that it doesn't create a swap file, but it does install entware-ng into a directory called /entware. If I recall correctly, the older setup instructions you cite to do create a swap file, but the directory is called /entware-ng. Otherwise, same deal.

Second, what the directory is called can lead to some confusion. I think TLC handles both possibilities in his ab-solution script but you will see in that thread it took some effort.

You might suggest to TLC that he add the swap install into his ab-solution script while it is installing entware.

 

[latenitetech]

I've noticed some significant differences in the way my Rpi serves up its files and AsusWrt serves up its files.

Really? I'm assuming you're running just a standard minidlna distro on your Rpi? I'm really curious if the differences can be explained purely by .conf file settings, or if the minidlna included in the Merlin firmware is fundamentally different. I just made the leap of faith that it was a standard distro as I hadn't seen anything to make me believe otherwise. If I'm in error, I'd like to correct that Wiki article.

In the meantime, two things. First, I wouldn't call the built-in entware install script outdated. It is true that it doesn't create a swap file, but it does install entware-ng into a directory called /entware. If I recall correctly, the older setup instructions you cite to do create a swap file, but the directory is called /entware-ng. Otherwise, same deal.

I just picked the one I thought was easiest for a noobie. They're both referenced in the Wiki. The one from Entware-NG is basically the same script as the one built into the firmware except it has the swapfile section included, which I just assumed came later. I have remove the "outdated" editorial comment, in case that might offend someone. I also opened an issue with RMerlin requesting an update to the built-in entware install script to include the swapfile creation step.

Second, what the directory is called can lead to some confusion. I think TLC handles both possibilities in his ab-solution script but you will see in that thread it took some effort.

Well, that may be the topic of another religious debate. I'm a big believer in modular software, and Merlin and Entware are as close to a perfect implementation as I can imagine. There is exactly one place where the name of the "entware directory" matters, and that is where it is linked to '/tmp/opt' (which is linked to '/opt' internally in the firmware). From that point on, all other references should be exclusively to '/opt'. So it should make zero difference to any add-on apps what the entware directory is actually named. I chose to name mine "opt," because that way if I access it via Samba it's "opt" and if I access via telnet or ssh, it's "/opt." Just made a lot more sense to me that way. I've not had any issue with any package I've installed so far, but I've not installed AB, which I'm assuming now would have an issue with my naming convention.

You might suggest to TLC that he add the swap install into his ab-solution script while it is installing entware.

I'll leave that to AB users to make such suggestions. My personal bent on modularity is that as an add-on package, he shouldn't be installing Entware at all. Or at least if he does as a convenience to noobies, does not mess with a previously-installed entware instance other than to possibly warn of legitimate issues detected.

But the beauty of this kind of environment is there is room for all religious beliefs, use what works and makes the most sense to you.