PeterB

Err... but shouldn't the pid file be removed when the application quits? Perhaps minidlna isn't closing down cleanly? File permissions look okay: -rw-rw-rw- 1 nobody users 3 May 21 13:31 /run/minidlna/minidlna.pid ... and directory permissions: drwxrwxr-x 1 nobody users 24 May 21 13:31 minidlna If I kill the minidlnad process, then the pid file does get removed and the container will restart in a fully functional condition. If I restart the container, without killing the minidlnad process then, on restart, the pid file date/time is unchanged from the earlier start, proving that the file has survived the restart. By what mechanism is/should the minidlnad process be terminated when the container is stopped or restarted?

Ha, it seems that if I delete the minidlna.pid file before I do the restart: root@Tower:/mnt/docker/appdata# docker exec -it binhex-minidlna rm /run/minidlna/minidlna.pid then the minidlna process starts up perfectly on the restart! root@Tower:/mnt/docker/appdata# docker exec -it binhex-minidlna ps -eaf | grep dlna nobody 62 1 0 13:29 ? 00:00:00 /usr/bin/minidlnad -f /config/mi root@Tower:/mnt/docker/appdata# The problem appears to be that, for me, at least, the pid file persists over a restart and/or a system reboot. As I understand it, the last update you issued was dealing with pid creation. I'm not sure why rolling back to the previous release [1.1.6-1-04] didn't fix the problem. Is this the complete answer? Why is it a problem for me, but not a problem for you? Confused!

I'm not sure whether I'd noted this before (and if not, why not)? : After Force Update: root@Tower:/mnt/docker/appdata# docker exec -it binhex-minidlna ps -eaf | grep dlna nobody 62 1 0 12:34 ? 00:00:00 /usr/bin/minidlnad -f /config/mi nobody 64 62 6 12:34 ? 00:00:01 /usr/bin/minidlnad -f /config/mi root@Tower:/mnt/docker/appdata# About three minutes later: root@Tower:/mnt/docker/appdata# docker exec -it binhex-minidlna ps -eaf | grep dlna nobody 62 1 0 12:34 ? 00:00:00 /usr/bin/minidlnad -f /config/mi root@Tower:/mnt/docker/appdata# After Restart: root@Tower:/mnt/docker/appdata# docker exec -it binhex-minidlna ps -eaf | grep dlna root@Tower:/mnt/docker/appdata# So, after a forced update, a minidlna scan is spawned as a child process, and it completes after about three minutes. This suggests that after a restart, either the minidlna process never launches or, if it does, it terminates very quickly. After a restart, one entry is added to the minidlna.log: [2017/05/21 13:12:10] minidlna.c:935: error: MiniDLNA is already running. EXITING. at the same time, supervisord.log has these lines added: Created by... ___. .__ .__ \_ |__ |__| ____ | |__ ____ ___ ___ | __ \| |/ \| | \_/ __ \\ \/ / | \_\ \ | | \ Y \ ___/ > < |___ /__|___| /___| /\___ >__/\_ \ \/ \/ \/ \/ \/ https://hub.docker.com/u/binhex/ 2017-05-21 13:12:07.891345 [info] Host is running unRAID 2017-05-21 13:12:07.924476 [info] System information Linux Tower 4.9.28-unRAID #1 SMP PREEMPT Sun May 14 11:03:53 PDT 2017 x86_64 GNU/Linux 2017-05-21 13:12:07.980942 [info] PUID defined as '99' 2017-05-21 13:12:08.054813 [info] PGID defined as '100' 2017-05-21 13:12:08.341885 [info] UMASK defined as '000' 2017-05-21 13:12:08.371429 [info] Permissions already set for volume mappings 2017-05-21 13:12:08.399995 [info] SCAN_ON_BOOT defined as 'no' 2017-05-21 13:12:08.428914 [info] SCHEDULE_SCAN_DAYS defined as '06' 2017-05-21 13:12:08.460774 [info] SCHEDULE_SCAN_HOURS defined as '02' 2017-05-21 13:12:09,120 CRIT Set uid to user 0 2017-05-21 13:12:09,120 INFO Included extra file "/etc/supervisor/conf.d/minidlna.conf" during parsing 2017-05-21 13:12:09,131 INFO supervisord started with pid 7 2017-05-21 13:12:10,134 INFO spawned: 'start' with pid 56 2017-05-21 13:12:10,135 INFO spawned: 'crond' with pid 57 2017-05-21 13:12:10,593 DEBG fd 8 closed, stopped monitoring <POutputDispatcher at 47968944308664 for <Subprocess at 47968944310896 with name start in state STARTING> (stdout)> 2017-05-21 13:12:10,593 DEBG fd 10 closed, stopped monitoring <POutputDispatcher at 47968944310824 for <Subprocess at 47968944310896 with name start in state STARTING> (stderr)> 2017-05-21 13:12:10,593 INFO success: start entered RUNNING state, process has stayed up for > than 0 seconds (startsecs) 2017-05-21 13:12:10,593 INFO exited: start (exit status 0; expected) 2017-05-21 13:12:10,593 DEBG received SIGCLD indicating a child quit 2017-05-21 13:12:11,594 INFO success: crond entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)

It seems to be nothing to do with the template, or my settings. I have completely removed the container, including deleting the image and deleting the appdata directory. I then re-installed and didn't change any settings whatsoever. For a minute, or so, it is possible to restart the container and the dlna service will still be visible on the network. However, after this time, restarting the container, results in the service no longer being visible on the network. From this, I conclude that something that minidlna is doing at 'initial' start (perhaps initial scan/creating the files.db database?) prevents subsequent 'clean' restarts. After a forced update, I note that files.db starts small and grows and also the art_cache directory is created (but only if I don't restrict /media to point to photos only). Could it be some resource issue? However, if I restrict the number of photos pointed to by the /media mapping, thereby restricting the size of files.db, the problem still persists.

That's a little difficult to determine since it appears to be impossible to edit the parameters without the container restarting. However, I'm beginning to convince myself that the problem is being caused by the way in which the container is started/restarted. When the container is 'updated', either by editing the parameters, or by 'force update', the command which is used to launch the container is displayed in the web gui, and I can use the same command to launch the container from a console window. This requires that the old container is removed, or else the name has to be changed. In this case. the application always starts up in a functional mode. This is the command: If the container is already running, and I issue: "docker restart binhex-minidlna" then the application is non-functional even though the container appears to be active. Clearly, for me/my system, docker restart does not leave the container (or its app) in the same condition as it is when the container is first run. Now, I'm guessing that the autostart procedure doesn't use docker run - perhaps it does a docker load followed by docker start? The big question, of course, is: Why does this problem only affect me and, perhaps, one other person? What is the difference between my system and yours?

Okay, I've proven that there's nothing magical about changing network mode. Any edit to the container settings, resulting in the xml file being updated, will cause the container/app to be restarted in a functional mode. Eg, typing a space into the 'Extra Parameters' field, then deleting it, followed by clicking the 'Apply' button, will restart the container in a functional mode. This makes me wonder whether the container restart after 'Applying' a parameter change is somehow different to any other start/restart. It's a little frustrating that clicking the 'Apply' button will always start the container even if it was stopped and 'autostart' is not enabled.

Is it possible to approach this from another direction? I know that after doing the network mode switch, minidlna will start up in a 'working' condition - I know that doing this causes the xml file to be changed, but is there anything else that gets changed/modified by doing this?

Okay, I've installed BubbleUPnP on my phone and, yes, I can access photos on minidlna. If I then perform an ordinary restart on the minidlna container, although it appears to have cached information and thumbnails from minidlna, Bubble reports "Error downloading image from server" when I attempt to 'play' images which were playing a moment before. If I perform the network mode switch, I can start playing images again. My conclusion is that BubbleUPnP is behaving in a manner very similar to that of my photoframe. Yes, the photoframe does receive OTA firmware updates, but I am not aware of an update within the last three months.

I can confirm that setting minidlna to not autostart, then starting manually more than four hours after the server booted, does not enable the service to be seen by my photoframe - I still have to perform the network mode switch.

I'm still not quite sure what Ben means when he says: As far as I'm aware, all settings relating to the docker are either in its appdata folder, or in its xml template file. If I delete the appdata/minidlna files, then I lose my minidlna.conf file and my files.db, neither of which I think I want to do. If I delete the my-binhex-minidlna.xml file, then I lose my host path settings etc. Again, I don't think I want to do this. However, clearly, when I change the network mode, the xml file gets re-written. I can't see anything in the appdata folder which gets modified as a result of switching network mode. Perhaps he's referring to something within the docker image?

Thanks for the suggestion. I will give it a try, but I'm not too hopeful. Simply stopping and starting the container while the server is running results in a non-functioning dlna service, so I don't believe that it's to do with a delayed network startup. My suspicion is that it's something to do with the state of the settings at the time the container starts. I guess that switching network mode is re-initialising some settings in the same way as Ben deleting the contents of the settings directory.

Ben, which particular files do you delete? I'm looking to automate the restart process - I'm getting fed up with having to intervene manually after every power outage, on average twice a day here, in order to get my photo frame to restart.

1.1.6-1-04 appears to behave in exactly the same way as latest. Restarting a working container results in the service not being visible. Switching network mode -> Bridge -> Host restores normal operation.

That is correct. If minidlna is running okay, serving photos, and I restart the container, the service can no longer be seen on the network. If I then do the network mode switch, the server immediately pops up on the "service search screen" on my photo frame. I presume that switching network mode is resetting some configuration parameters, similar to what hedrinbc does when he deletes the settings files.

Thanks for your attention, but ..... it doesn't appear to have resolved my issue - I still need to switch to bridge and back to host before the service is visible to my photoframe.

In a similar vein, I would highly recommend kid3 for Linux users. Multi file select, delete and amend tags, create tags from filename/path, create filename/path from tags ....

Exactly the same occurrence again. On system restart after a lengthy power cut, my photo frame couldn't see the dlna service. I edited the docker settings, changing network mode to 'bridge' and back to 'host' (clicking the 'Accept' button both times) and the dlna service pops up in the photo frame search. I really don't know whether this is caused by the minidlna docker update, or the system update to 6.3.3, and I'm at a loss to know how to resolve it.

When I installed the 6.3.3 unRAID upgrade (from 6.3.2), I also installed the latest MiniDLNA update. Since doing that, I have great trouble in getting the DLNA service visible on my network. MiniDLNA appears to be running within the docker and there are no unusual messages recorded in either the supervisor or the minidlna log files. The only method I have found to get the dlna service visible is to switch the network mode to 'bridge' and then back to 'host' (this has worked twice, so probably not a total fluke). Any ideas what may be going wrong?

Okay, that seems to have worked - thanks.

So, what should I do about this one? All plugins are up to date. I have closed the browser window, and opened a new one. I do have these entries in the log: Feb 4 23:18:38 Tower root: error: webGui/include/DeviceList.php: missing csrf_token Feb 4 23:18:47 Tower root: error: webGui/include/DeviceList.php: missing csrf_token

I have just updated the system to v6.3.0. When I attempt to run preclear it sticks at "Please wait... retrieving information!" There is no button available for downloading a log. I presume that it will stay like this until I reboot?

Has the default "no" been changed? At first this seemed to work but, lately, my installation appears to again be scanning on boot. I have added --env "SCAN_ON_BOOT=no" to the Extra Parameters, but this does not appear to have any effect. EDIT to add: Ah, yes - it would appear so: if [[ ! -z "${SCAN_ON_BOOT}" ]]; then echo "[info] SCAN_ON_BOOT defined as '${SCAN_ON_BOOT}'" | ts '%Y-%m-%d %H:%M:%.S' else echo "[warn] SCAN_ON_BOOT not defined,(via -e SCAN_ON_BOOT), defaulting to 'yes'" | ts '%Y-%m-%d %H:%M:%.S' export SCAN_ON_BOOT="[b]yes[/b]" fi It would also appear that the reason that my addition to the Extra Parameters wasn't working was because the quotation marks don't get parsed correctly in the Docker tab web interface. Removing the quotation marks appears to resolve this.

Great - I no longer have to edit "/etc/supervisor/conf.d/minidlna.conf" every time the docker gets updated!

I have just followed that procedure on binhex-emby (twice, once with CA 2016.06.12, and then with CA 2016.06.13). The problem still persists (and I note that it also affects the Apps tab). Edit to add: Okay, it seems that a reboot was required. All is back to normal after this afternoon's powercut.

I removed, and re-added, the emby docker. The dates/times of the xml files in templates/binhex have updated, but the problem is still present. The reported lineno refers to the DonateLink element in every case.