05-06-2019, 02:40 PM
(This post was last modified: 05-06-2019, 02:44 PM by TheOldPresbyope.
Edit Reason: minor touchup
)
@Onionhead reported an issue with his Synology NAS vs moOde r5.x in a series of posts in a thread relating to a moOde 5.0 update (his first post). Despite the lengthy discussion already there, I've created this new thread because the issue doesn't seem to relate to the update.
Caveat: the following describes an experiment done with liberal doses of "brute force and ignorance". I am not expert in the product or its use nor am I using the product for any purpose except testing its interaction with moOde. This is not a How To and I will never create one.
Summary: I couldn't reproduce the issue
I spent my spare time over the weekend doing my homework (e.g., using Internet search engines!).
I now have on my Linux laptop a virtual machine which is running DSM6.1-15047 (2017/02/23); in other words, a virtual machine which acts like a two-year old Synology NAS. Its hostname is DS3615xs, which is discoverable on my LAN. In configuring moOde I reference it by its IP address to avoid introducing any possible DNS issues.
I've poked around the DSM user interface and have brought up both SMB and NFS services publishing a shared folder "Music". I also enabled SSH service so I can log into the NAS host and rummage around the file system. This share corresponds to the system directory /volume1/Music, which already contains a @eaDir subdirectory. This directory seems to relate to the DSM's indexing service although I haven't found that documented.
From the command line, I loaded in a single album under /volume1/Music/Musical/Barbara Cook/Candide/<tracks>. No additional @eaDir subdirectories were created.
At this point, I installed the optional DSM AudioStation package because its description was intriguing. Then I loaded in another album under /volume1/Music/Jazz/Jason Moran/<tracks>. This time, an additional @eaDir subdirectory was created:
Looking at this subdirectory, we see subdirectories named identically to the track files, which I suspect were created by/for AudioStation but I haven't found any docs to prove it:
and looking at just one of these subdirectories, we see it contains an image file, which I presume is a thumbnail for AudioStation:
In other words I have created a directory and file structure which seems to approximate @Onionhead's. There are no .mpdignore files nor did I expect to find any.
If I examine the directories using an SMB client (on my Linux laptop or iPad) I see only the regular directories and files. I do not see anything related to the indexing structures (e.g., ../@eaDir and below). I'm not sure if this is because of protocol share-naming rules or because of the server configuration, although I found nothing of note in the usual samba config files. [I note that the NAS is not advertising the folder, so 'smbtree -b -N' will find the server but not the folder. Possibly there's a setting I missed.]
Not surprisingly, if I mount /volume1/Music on a Linux host using NFS, I see everything including all the indexing structures.
I thought, aha, maybe @Onionhead's issue arises from 1) him mounting his share using NFS and 2) moOde somehow objecting to the indexing niffnaff.
However I am able to mount this share in moOde r5.1 using either SMB (as 192.168.1.222/Music) or NFS (as 192.168.1.222/volume1/Music) services. Either way, moOde and MPD happily build their respective datastores with all the tracks and coverart on the NAS and let me do all the things I expect to do using the various moOde UI panels. I haven't traced network packets so I can't prove that MPD did or didn't look for .mpdignore files, but there's not "Input/output error" messages in the log like @Onionhead saw.
I've only scratched the surface here but what I've accomplished suggests to me that at least this version of DSM can be configured to work with moOde r5.x and vice versa. Unfortunately, I was unable to identify a specific reason for @Onionhead's problem. In particular, I remain flummoxed that his NAS is working with moOde r4.x and not with moOde r5.x.
Regards,
Kent
PS - I haven't discussed users/permissions here. I did all my DSM work as user DSadmin (in the administrators group). I set NFS to "squash" all users to admin (apparently newer DSM also offers the option to squash all users to guest). In moOde, I mount the SMB share as user DSadmin. Again, I don't know why, if there is a conflicting-permissions problem, it would manifest itself in one version of moOde and not another.
PPS - The DSM is a complex, fully flavored software product with many optional packages. It has undergone many revisions over the years. I have been testing with just one version and one optional package. There's always the possibility that testing with another version and/or collection of packages would reveal different behavior with moOde. I have not attempted to update my VM because of the way in which it was constructed.
Caveat: the following describes an experiment done with liberal doses of "brute force and ignorance". I am not expert in the product or its use nor am I using the product for any purpose except testing its interaction with moOde. This is not a How To and I will never create one.
Summary: I couldn't reproduce the issue
I spent my spare time over the weekend doing my homework (e.g., using Internet search engines!).
I now have on my Linux laptop a virtual machine which is running DSM6.1-15047 (2017/02/23); in other words, a virtual machine which acts like a two-year old Synology NAS. Its hostname is DS3615xs, which is discoverable on my LAN. In configuring moOde I reference it by its IP address to avoid introducing any possible DNS issues.
I've poked around the DSM user interface and have brought up both SMB and NFS services publishing a shared folder "Music". I also enabled SSH service so I can log into the NAS host and rummage around the file system. This share corresponds to the system directory /volume1/Music, which already contains a @eaDir subdirectory. This directory seems to relate to the DSM's indexing service although I haven't found that documented.
From the command line, I loaded in a single album under /volume1/Music/Musical/Barbara Cook/Candide/<tracks>. No additional @eaDir subdirectories were created.
At this point, I installed the optional DSM AudioStation package because its description was intriguing. Then I loaded in another album under /volume1/Music/Jazz/Jason Moran/<tracks>. This time, an additional @eaDir subdirectory was created:
Quote:DSadmin@DS3615xs:/volume1/Music/Jazz/Jason Moran$ ls -la
total 221156
drwxrwxrwx+ 1 DSadmin users 1164 Jul 24 2018 .
drwxrwxrwx+ 1 DSadmin users 22 May 5 21:57 ..
-rwxrwxrwx+ 1 DSadmin users 1253213 Jul 24 2018 cover.jpg
drwxrwxrwx+ 1 root root 2182 May 5 21:57 @eaDir
-rwxrwxrwx+ 1 DSadmin users 21663420 Jul 24 2018 JASON MORAN - Looks of a Lot - 01 Der Doppelgänger.flac
-rwxrwxrwx+ 1 DSadmin users 13040795 Jul 24 2018 JASON MORAN - Looks of a Lot - 02 Big News.flac
-rwxrwxrwx+ 1 DSadmin users 8430404 Jul 24 2018 JASON MORAN - Looks of a Lot - 03 Wabashin'.flac
-rwxrwxrwx+ 1 DSadmin users 25706158 Jul 24 2018 JASON MORAN - Looks of a Lot - 04 Wabash Stomp.flac
-rwxrwxrwx+ 1 DSadmin users 19405932 Jul 24 2018 JASON MORAN - Looks of a Lot - 05 Easy.flac
-rwxrwxrwx+ 1 DSadmin users 21916072 Jul 24 2018 JASON MORAN - Looks of a Lot - 06 South Side Digging.flac
-rwxrwxrwx+ 1 DSadmin users 21418035 Jul 24 2018 JASON MORAN - Looks of a Lot - 07 Make Noise.flac
-rwxrwxrwx+ 1 DSadmin users 25077314 Jul 24 2018 JASON MORAN - Looks of a Lot - 08 Face-Fade.flac
-rwxrwxrwx+ 1 DSadmin users 20981947 Jul 24 2018 JASON MORAN - Looks of a Lot - 09 Music Boxing More News.flac
-rwxrwxrwx+ 1 DSadmin users 17184112 Jul 24 2018 JASON MORAN - Looks of a Lot - 10 More News.flac
-rwxrwxrwx+ 1 DSadmin users 30366192 Jul 24 2018 JASON MORAN - Looks of a Lot - 11 Shoulder to Shoulder.flac
Looking at this subdirectory, we see subdirectories named identically to the track files, which I suspect were created by/for AudioStation but I haven't found any docs to prove it:
Quote:DSadmin@DS3615xs:/volume1/Music/Jazz/Jason Moran/@eaDir$ ls -la
total 992
drwxrwxrwx+ 1 root root 2182 May 5 21:57 .
drwxrwxrwx+ 1 DSadmin users 1164 Jul 24 2018 ..
drwxrwxrwx+ 1 root root 26 May 6 06:15 JASON MORAN - Looks of a Lot - 01 Der Doppelgänger.flac
drwxrwxrwx+ 1 root root 26 May 6 06:15 JASON MORAN - Looks of a Lot - 02 Big News.flac
-rwxrwxrwx+ 1 root root 123483 May 5 21:57 JASON MORAN - Looks of a Lot - 02 Big News.flac@SynoEAStream
drwxrwxrwx+ 1 root root 26 May 6 06:15 JASON MORAN - Looks of a Lot - 03 Wabashin'.flac
-rwxrwxrwx+ 1 root root 123483 May 5 21:57 JASON MORAN - Looks of a Lot - 03 Wabashin'.flac@SynoEAStream
drwxrwxrwx+ 1 root root 26 May 6 06:15 JASON MORAN - Looks of a Lot - 04 Wabash Stomp.flac
-rwxrwxrwx+ 1 root root 123483 May 5 21:57 JASON MORAN - Looks of a Lot - 04 Wabash Stomp.flac@SynoEAStream
drwxrwxrwx+ 1 root root 26 May 6 06:15 JASON MORAN - Looks of a Lot - 05 Easy.flac
drwxrwxrwx+ 1 root root 26 May 6 06:15 JASON MORAN - Looks of a Lot - 06 South Side Digging.flac
-rwxrwxrwx+ 1 root root 123483 May 5 21:57 JASON MORAN - Looks of a Lot - 06 South Side Digging.flac@SynoEAStream
drwxrwxrwx+ 1 root root 26 May 6 06:15 JASON MORAN - Looks of a Lot - 07 Make Noise.flac
-rwxrwxrwx+ 1 root root 123483 May 5 21:57 JASON MORAN - Looks of a Lot - 07 Make Noise.flac@SynoEAStream
drwxrwxrwx+ 1 root root 26 May 6 06:15 JASON MORAN - Looks of a Lot - 08 Face-Fade.flac
drwxrwxrwx+ 1 root root 26 May 6 06:15 JASON MORAN - Looks of a Lot - 09 Music Boxing More News.flac
-rwxrwxrwx+ 1 root root 123483 May 5 21:57 JASON MORAN - Looks of a Lot - 09 Music Boxing More News.flac@SynoEAStream
drwxrwxrwx+ 1 root root 26 May 6 06:15 JASON MORAN - Looks of a Lot - 10 More News.flac
-rwxrwxrwx+ 1 root root 123483 May 5 21:57 JASON MORAN - Looks of a Lot - 10 More News.flac@SynoEAStream
drwxrwxrwx+ 1 root root 26 May 6 06:15 JASON MORAN - Looks of a Lot - 11 Shoulder to Shoulder.flac
-rwxrwxrwx+ 1 root root 123483 May 5 21:57 JASON MORAN - Looks of a Lot - 11 Shoulder to Shoulder.flac@SynoEAStream
and looking at just one of these subdirectories, we see it contains an image file, which I presume is a thumbnail for AudioStation:
Quote:DSadmin@DS3615xs:/volume1/Music/Jazz/Jason Moran/@eaDir/JASON MORAN - Looks of a Lot - 01 Der Doppelgänger.flac$ ls -la
total 124
drwxrwxrwx+ 1 root root 26 May 6 06:15 .
drwxrwxrwx+ 1 root root 2182 May 5 21:57 ..
-rwxrwxrwx 1 DSadmin users 123335 May 6 06:15 01APIC_03.jpg
In other words I have created a directory and file structure which seems to approximate @Onionhead's. There are no .mpdignore files nor did I expect to find any.
If I examine the directories using an SMB client (on my Linux laptop or iPad) I see only the regular directories and files. I do not see anything related to the indexing structures (e.g., ../@eaDir and below). I'm not sure if this is because of protocol share-naming rules or because of the server configuration, although I found nothing of note in the usual samba config files. [I note that the NAS is not advertising the folder, so 'smbtree -b -N' will find the server but not the folder. Possibly there's a setting I missed.]
Not surprisingly, if I mount /volume1/Music on a Linux host using NFS, I see everything including all the indexing structures.
I thought, aha, maybe @Onionhead's issue arises from 1) him mounting his share using NFS and 2) moOde somehow objecting to the indexing niffnaff.
However I am able to mount this share in moOde r5.1 using either SMB (as 192.168.1.222/Music) or NFS (as 192.168.1.222/volume1/Music) services. Either way, moOde and MPD happily build their respective datastores with all the tracks and coverart on the NAS and let me do all the things I expect to do using the various moOde UI panels. I haven't traced network packets so I can't prove that MPD did or didn't look for .mpdignore files, but there's not "Input/output error" messages in the log like @Onionhead saw.
I've only scratched the surface here but what I've accomplished suggests to me that at least this version of DSM can be configured to work with moOde r5.x and vice versa. Unfortunately, I was unable to identify a specific reason for @Onionhead's problem. In particular, I remain flummoxed that his NAS is working with moOde r4.x and not with moOde r5.x.
Regards,
Kent
PS - I haven't discussed users/permissions here. I did all my DSM work as user DSadmin (in the administrators group). I set NFS to "squash" all users to admin (apparently newer DSM also offers the option to squash all users to guest). In moOde, I mount the SMB share as user DSadmin. Again, I don't know why, if there is a conflicting-permissions problem, it would manifest itself in one version of moOde and not another.
PPS - The DSM is a complex, fully flavored software product with many optional packages. It has undergone many revisions over the years. I have been testing with just one version and one optional package. There's always the possibility that testing with another version and/or collection of packages would reveal different behavior with moOde. I have not attempted to update my VM because of the way in which it was constructed.
