INTERACT FORUM

More => Old Versions => JRiver Media Center 24 for Linux => Topic started by: tlenthe on December 08, 2018, 03:31:17 pm

Title: Maximum number of supported directories at one level
Post by: tlenthe on December 08, 2018, 03:31:17 pm
I recently consolidated all of my music files from multiple drives onto a single 8TB disk.  When I ran import on the new disk, I noticed that some of the last directory entries in the audio->files list were missing.  I did a little more investigation and it appears that there is a limit of ~512 directories at one level as that's about where the entries stopped.  All the content in the directories beyond the cut-off point are not present in the database for any searches, etc.

I can work around this by adding some additional "artificial" levels of directories, but as drives get larger, this might be a limitation that should be reconsidered.

Running Media Center 24.0.64 (64-bit) on Ubuntu 18.04

Title: Re: Maximum number of supported directories at one level
Post by: mwillems on December 08, 2018, 07:25:32 pm
I have about 3000 directories in one parent directory that MC scans, and it picks them all up (it does not stop at 512). 

Is what you're seeing repeatable (i.e. does it happen when you trigger a manual import)?  Any special info about the disk?  The filesystem, etc.?
Title: Re: Maximum number of supported directories at one level
Post by: tlenthe on December 09, 2018, 07:27:42 pm
I tried manual import multiple times with no change.  After "nesting" folders it did get all the way to the last directory.  The directory is mounted from a network location using nfs.  I thought I checked the directory using system tools at the mount point, but I'm not 100% sure.   Is it possible this is a linux/ubuntu nfs artifact? 
Title: Re: Maximum number of supported directories at one level
Post by: bob on December 10, 2018, 10:05:42 am
I tried manual import multiple times with no change.  After "nesting" folders it did get all the way to the last directory.  The directory is mounted from a network location using nfs.  I thought I checked the directory using system tools at the mount point, but I'm not 100% sure.   Is it possible this is a linux/ubuntu nfs artifact?
I wonder if there is inode limit for dirs that's set in the NFS options somewhere?
Title: Re: Maximum number of supported directories at one level
Post by: mwillems on December 10, 2018, 05:47:22 pm
Is it possible this is a linux/ubuntu nfs artifact?

I'm not sure.  I don't have much experience with NFS; I can say I've never seen any similar problems using samba/cifs FWIW.  It might be worth testing with either a direct connection or an alternate network protocol to rule out NFS.
Title: Re: Maximum number of supported directories at one level
Post by: bob on December 13, 2018, 04:13:31 pm
I'm not sure.  I don't have much experience with NFS; I can say I've never seen any similar problems using samba/cifs FWIW.  It might be worth testing with either a direct connection or an alternate network protocol to rule out NFS.
I'd like to think that NFS would work better because there should be less filesystem attribute matching going on but there are a lot of people trying to make cifs work well with linux.
Title: Re: Maximum number of supported directories at one level
Post by: Manfred on December 13, 2018, 04:36:21 pm
If think that I had something similar in the past - I had one directory path with a file too long filename inside. Win10 had problems with that, it does't show the correct size of all folders. I used then a shorter filename.
Title: Re: Maximum number of supported directories at one level
Post by: tlenthe on January 25, 2019, 09:14:27 am
I just wanted to close this out...  Whatever was happening resolved itself after rebooting the nfs server.  So, bottom line, MC24 wasn't the issue.

Ted
Title: Re: Maximum number of supported directories at one level
Post by: bob on January 25, 2019, 04:15:04 pm
I just wanted to close this out...  Whatever was happening resolved itself after rebooting the nfs server.  So, bottom line, MC24 wasn't the issue.

Ted
Thanks for reporting back.