egeis Posted February 20, 2017 Share Posted February 20, 2017 Hey team, Gotta question that I can't seem to resolve... I brought in a slew of FLACs. MiniDLNA does NOT find them as subdirectories in my mapped directory. Some strangeness... 1. I have a "media/audio" directory that is directly mapped into miniDLNA. 2. I created a directory in this folder called "FLACs" and moved several full folders of high resolution FLAC music into this directory, e.g. "Radiohead OK Computer 24 bit 96k", "Pink Floyd - The Wall - Vinyl 24 bit". 3. I restarted miniDLNA (with SCAN_ON_BOOT = YES). 4. Started miniDLNA... Nothing was there. It didn't find any of the FLACs. Test. 1. Copy and move one flac file from the Radiohead directory into the "media/audio/FLACs" folder. 2. Restart miniDLNA. 3. Start up my client and suddenly I can see that SINGLE flac file. Next. 1. Move all flacs from several directories and restart miniDLNA. 2. 3 out of 4 directories of music recognized. 4th directory, not a single flac file recognized. ...so here's my quandary... Why is it skipping the subdirectories with these files to being with? Shouldn't it do a depth-first-search and find every file with a recognized extension? I followed the directions on this page [https://community.netgear.com/t5/Using-your-ReadyNAS/ReadyDLNA-does-not-find-all-files-dirs-files-missing/td-p/903290] to update the systemd services file to execute "minidlna -S -R". Refreshing the entire database still doesn't work to recognize the FLAC files I've put there. Any help? Quote Link to comment
binhex Posted February 21, 2017 Author Share Posted February 21, 2017 (edited) On 20/02/2017 at 1:42 AM, egeis said: Hey team, Gotta question that I can't seem to resolve... I brought in a slew of FLACs. MiniDLNA does NOT find them as subdirectories in my mapped directory. Some strangeness... 1. I have a "media/audio" directory that is directly mapped into miniDLNA. 2. I created a directory in this folder called "FLACs" and moved several full folders of high resolution FLAC music into this directory, e.g. "Radiohead OK Computer 24 bit 96k", "Pink Floyd - The Wall - Vinyl 24 bit". 3. I restarted miniDLNA (with SCAN_ON_BOOT = YES). 4. Started miniDLNA... Nothing was there. It didn't find any of the FLACs. Test. 1. Copy and move one flac file from the Radiohead directory into the "media/audio/FLACs" folder. 2. Restart miniDLNA. 3. Start up my client and suddenly I can see that SINGLE flac file. Next. 1. Move all flacs from several directories and restart miniDLNA. 2. 3 out of 4 directories of music recognized. 4th directory, not a single flac file recognized. ...so here's my quandary... Why is it skipping the subdirectories with these files to being with? Shouldn't it do a depth-first-search and find every file with a recognized extension? I followed the directions on this page [https://community.netgear.com/t5/Using-your-ReadyNAS/ReadyDLNA-does-not-find-all-files-dirs-files-missing/td-p/903290] to update the systemd services file to execute "minidlna -S -R". Refreshing the entire database still doesn't work to recognize the FLAC files I've put there. Any help? i would think the issue is with the flac files themselves, try copying the flac files in question and then stripping out the id tag info, then restart the container and see if it sees them, if it does then the issue is corrupt tag info causing minidlna to skip the files. Edited February 21, 2017 by binhex Quote Link to comment
hgeorges Posted March 19, 2017 Share Posted March 19, 2017 Hello; Thanks for making this docker available. I decided to experiment with it; simplicity is definitely a huge advantage over all the other media servers out there... Can you check if you have the same error message in your log and if not, suggest why is happening to me, and a possible solution: [2017/03/12 16:18:28] utils.c:279: warn: make_dir: cannot create directory '/var/run/minidlna' [2017/03/12 16:18:28] minidlna.c:400: error: Unable to create pidfile directory: /var/run/minidlna/minidlna.pid Further to that - I've got quite a few warnings about some issues found with my music. (corrupted oggs, names too long, not valid header, etc. How do you suggest to clean these up? do you recommend a tool whichcan check for corruptions, and other issues (like the one mentioned above)? Thanks hg Quote Link to comment
binhex Posted March 24, 2017 Author Share Posted March 24, 2017 On 19/03/2017 at 7:06 PM, hgeorges said: Hello; Thanks for making this docker available. I decided to experiment with it; simplicity is definitely a huge advantage over all the other media servers out there... Can you check if you have the same error message in your log and if not, suggest why is happening to me, and a possible solution: [2017/03/12 16:18:28] utils.c:279: warn: make_dir: cannot create directory '/var/run/minidlna' [2017/03/12 16:18:28] minidlna.c:400: error: Unable to create pidfile directory: /var/run/minidlna/minidlna.pid Further to that - I've got quite a few warnings about some issues found with my music. (corrupted oggs, names too long, not valid header, etc. How do you suggest to clean these up? do you recommend a tool whichcan check for corruptions, and other issues (like the one mentioned above)? Thanks hg Thanks for the feedback, ive now fixed up the issue relating to pid file creation, you should see this in the next release. As far as cleaning up metadata, for music i highly recommend using the excellent windows app mp3tag (http://www.mp3tag.de/en/) you can multi select and delete tags using it, its my tool of choice. Quote Link to comment
PeterB Posted April 2, 2017 Share Posted April 2, 2017 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? Quote Link to comment
PeterB Posted April 8, 2017 Share Posted April 8, 2017 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. Quote Link to comment
hedrinbc Posted April 15, 2017 Share Posted April 15, 2017 Yes, also having issues with the latest version. New video files don't get re-scanned quickly so I often restart the container and after the latest update the container doesn't boot properly and the logs are not helpful (supervisor and cron comments only) then the service is not visible form my Roku. My "fix" has been to delete all the files in the settings directory manually and restart then it starts every time. Any thoughts? Thanks, -Ben Quote Link to comment
binhex Posted April 15, 2017 Author Share Posted April 15, 2017 OK leave it with me guys I will take a look tonightSent from my SM-G900F using Tapatalk Quote Link to comment
PeterB Posted April 15, 2017 Share Posted April 15, 2017 On 3/25/2017 at 0:11 AM, binhex said: As far as cleaning up metadata, for music i highly recommend using the excellent windows app mp3tag (http://www.mp3tag.de/en/) you can multi select and delete tags using it, its my tool of choice. 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 .... Quote Link to comment
binhex Posted April 16, 2017 Author Share Posted April 16, 2017 On 15/04/2017 at 10:16 AM, binhex said: OK leave it with me guys I will take a look tonight Sent from my SM-G900F using Tapatalk bit later than expected, but i think ive found the issue, please give the latest image a whirl and let me know how you get on. Quote Link to comment
PeterB Posted April 17, 2017 Share Posted April 17, 2017 (edited) 16 hours ago, binhex said: bit later than expected, but i think ive found the issue, please give the latest image a whirl and let me know how you get on. 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. Edited April 17, 2017 by PeterB Quote Link to comment
binhex Posted April 17, 2017 Author Share Posted April 17, 2017 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.Hmm OK so a simple restart of the container never works? You always have to do the network mode switch?Sent from my LG-V500 using Tapatalk Quote Link to comment
PeterB Posted April 17, 2017 Share Posted April 17, 2017 (edited) 3 hours ago, binhex said: Hmm OK so a simple restart of the container never works? You always have to do the network mode switch? 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. Edited April 17, 2017 by PeterB Quote Link to comment
binhex Posted April 18, 2017 Author Share Posted April 18, 2017 On 08/04/2017 at 4:28 PM, PeterB said: 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. ok lets narrow this down a bit, can you try running the earlier version, the tag you want is "1.1.6-1-04", if your unsure how to specify this tag then see my sig, general docker faq, i think its in there. Quote Link to comment
PeterB Posted April 18, 2017 Share Posted April 18, 2017 (edited) 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. Edited April 18, 2017 by PeterB Quote Link to comment
PeterB Posted May 1, 2017 Share Posted May 1, 2017 On 4/15/2017 at 9:16 AM, hedrinbc said: My "fix" has been to delete all the files in the settings directory manually and restart then it starts every time. 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. Quote Link to comment
binhex Posted May 1, 2017 Author Share Posted May 1, 2017 20 hours ago, PeterB said: 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. i feel your frustration, am idea, have you tried a delayed start on this container, perhaps the networking stack isnt up at the time this docker starts, just try switching auto start to off in unraid webui, then once your server is running then just start it (dont flip the network mode), if it works then you could potentially use the CA plugin to delay startup. Quote Link to comment
PeterB Posted May 2, 2017 Share Posted May 2, 2017 16 hours ago, binhex said: ...st try switching auto start to off in unraid webui, then once your server is running then just start it ... 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. Quote Link to comment
PeterB Posted May 2, 2017 Share Posted May 2, 2017 (edited) I'm still not quite sure what Ben means when he says: Quote delete all the files in the settings directory 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? Edited May 2, 2017 by PeterB Quote Link to comment
binhex Posted May 2, 2017 Author Share Posted May 2, 2017 ive got no idea what he's on about tbh @PeterB as you said deleting either appdata or xml will result in having to either reconfigure the container settings and/or reconfigure the application, im pretty sure this is not the "fix". i will do a bit of testing tonight and see if i can replicate this issue. Quote Link to comment
PeterB Posted May 5, 2017 Share Posted May 5, 2017 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. Quote Link to comment
binhex Posted May 5, 2017 Author Share Posted May 5, 2017 13 minutes ago, PeterB said: 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. ok it was a bit of a long shot, im not really sure where we go with this, esp as rolling back to a previous version does not fix the issue, so that isnt even an option. I know this doesnt help but to confirm - I dont have a photo frame, but i do use BubbleUPnP to connect to minidlna from time to time and ive never had a problem connecting, up to this time ive never had to flip network mode to make it visible on the network, could you perhaps try connecting to minidlna using some other client, just to rule out your photo frame being the issue (do photo frames get firmware updates?!? :-) ) Quote Link to comment
PeterB Posted May 5, 2017 Share Posted May 5, 2017 38 minutes ago, binhex said: I know this doesnt help but to confirm - I dont have a photo frame, but i do use BubbleUPnP to connect to minidlna from time to time and ive never had a problem connecting, up to this time ive never had to flip network mode to make it visible on the network, could you perhaps try connecting to minidlna using some other client, just to rule out your photo frame being the issue (do photo frames get firmware updates?!? :-) ) 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. Quote Link to comment
binhex Posted May 5, 2017 Author Share Posted May 5, 2017 26 minutes ago, PeterB said: 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. ok im out of suggestions on this, just did a restart of minidlna and i can connect to it straight away using bubbleupnp and also windows media player *shrug*. Quote Link to comment
PeterB Posted May 5, 2017 Share Posted May 5, 2017 1 hour ago, binhex said: ok im out of suggestions on this, just did a restart of minidlna and i can connect to it straight away using bubbleupnp and also windows media player *shrug*. 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? Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.