Minidlna Persistence over Reboots ?

[foxyboy]

I have recently have 2 occassions where reboots have resulted in minidlna failing to pickup what was a perfectly good configuration. The end result being no media being seen on the USB drive and empty directories for the 2 shared folders.
I had multiple folders on the usb drive and had shared out 2 folders /Movies and /TVShows, there was 2.7TB content in total.
I was fortunate enough to unmount the drive and chkdsk it on windows which did recover the data but im unsure why this happended. Theres nothing major in the logs.

Looking at other minidlna configuration tips out there it would appear to be best practise to put the db_dir and log_dir configurations somewhere other than /tmp.
https://www.raspberrypi.org/forums/view ... 49#p221049

Gargoyle does not facilitate this and will ignore changes in /etc/config/mindlna.conf setting and rewrite /tmp/minidlna.conf on each restart.

Is there any way to prevent or override this ?
Or should the minidlna web gui allow for these parameters ?

[Lantis]

Last I checked, it gets stored on the drive itself. Are you really seeing it stored in /tmp?
The issue you’re seeing is usually when minidlna starts before the USB device is ready.

When this happens, killing minidlna, mounting the USB drive again, and restarting minidlna usually recovers the issue.

[foxyboy]

Technically speaking its the /tmp location of the mounted usb drive but as you point out this is likely due to a timing issue at start up. thats why its seen occassionally.

As the config introduces this boot dependancy on the usb drive surely allowing to set db_dir & log_dir to a location other than /tmp would be a solution?

[Lantis]

Well it’s not really IN “tmp”. It’s just a location for the mount to be referenced to.
But if you want to move it, /etc/init.d/USB_storage

It won’t be any more or less temporary than before. While I genuinely think there is a race condition issue here, I think you’re barking up the wrong tree for how to fix it.

[foxyboy]

I have no preference for the fix itself.
If its a case that minidlna is getting started before usb drive is ready on occassion then i guess the best approach would be not to autostart minidlna and avert the OMG wheres my 2.7TB feeling :

Im usually restarting manually so i could do it but its probably possible to automate. When i look at the respective init scripts minidlna is set to start before usb_storage.
Now perhaps this is essential IF your plug_root is on usb but i dont see why if your usb is used for serving dlna media.
So perhaps changing this start order is a good approach

/etc/init.d/minidlna has a start sequence
START=50
/etc/init.d/usb_storage has a start sequence
START=56

If not then i could do something else like this.

while test -e /tmp/UUUIDOFUSB
do
echo "waiting for usb to mount"
sleep 1
done

Ill have to investigate the best approach in my case and report back

[Lantis]

Both of those methods should work.
I think the second one is a little more robust. But I would also maybe include a timeout so it doesn’t get stuck forever

[Lantis]

Let me know where you get to with this and I’ll try to fix it for future builds.
It used to be an issue that was very close to me, but I ended up getting a proper NAS so it isn’t a high priority for me these days.

[foxyboy]

Lantis,
Here is my stab at a generic filewatch script with timeout

I will modify /etc/init.d/minidlna and hardcode around the
line service_start /usr/bin/minidlna -f "$MINIDLNA_CONFIG_FILE" for now to achieve what i want.

I guess ideally it should be put into its own function, where the actual file used for test is extracted from "$MINIDLNA_CONFIG_FILE", or if theres an easy way to label the usb disk then there would be no need.

Im sure you can suggest an elegant way to do this

>
#!/bin/sh
timeout=20
filewatch="/tmp/test.txt"

echo "timeout set to..." $timeout

while [ ! -f $filewatch ]
do
echo "waiting for file" $filewatch
sleep 1
timeout=$(( $timeout - 1 ))
echo "timeout..." $timeout

if [ "$timeout" -eq 0 ]; then
break
echo "timeout reached, exiting"
fi
done

<

[foxyboy]

Ok, this occurred again when i had to restart due to reports of wifi aint working dad !!!

I did kill the minidlna process but when i tried to remount usb
by issuing /etc/init.d/fstab stop followed by /etc/init.d/fstab start i got an error saying
"this file has been obsoleted. please call /sbin/block mount directly"

At a guess this is NOT the correct way to remount the usb device on the fly ?

Anyway i looked into the start order and i decided to change
START=50 in /etc/init.d/minidlna to START=57

this should ensure that usb_storage attempts to start before it as /etc/init/usb_storage has START=56

After making that change and retstarting all was well again so it might be the easiest fix to try first.
It this proves to not be reliable i will try to timedelay the minidelay startup as above

root@Gargoyle:/etc/init.d# grep -i "START=5" *
bwmon_gargoyle:START=55
cron:START=50
dropbear:START=50
minidlna:#START=50
minidlna:START=57
p910nd:START=50
qos_gargoyle:START=50
uhttpd:START=50
usb_storage:START=56

[Lantis]

Correct. You use /etc/init.d/usb_storage to remount.
Let me know how the reorder goes.