[Support] binhex - MiniDLNA


Recommended Posts

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?

 

 

 

 

Link to comment
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 by binhex
Link to comment
  • 4 weeks later...

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

Link to comment
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.

Link to comment
  • 2 weeks later...

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?

Link to comment

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.

Link to comment

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

Link to comment
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 ....

Link to comment
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.

Link to comment
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 by PeterB
Link to comment
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

Link to comment
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 by PeterB
Link to comment
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.

Link to comment
  • 2 weeks later...
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.

Link to comment
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.

Link to comment
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.

Link to comment

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 by PeterB
Link to comment

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.

Link to comment

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.

Link to comment
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?!? :-) )

Link to comment
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.

Link to comment
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*.

Link to comment
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?

Link to comment

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.