-
Notifications
You must be signed in to change notification settings - Fork 291
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Files/folders are not recognized in library scan #315
Comments
Is LMS running on Windows? Is the data stored on local media or attached/mounted drives or shares? What filesystem are you using on that disk? Please run a scan with the scanning logging group enabled (Settings/Advanced/Logging), then provide a copy of your scanner.log.zip file. |
Thank you for the hint about the filesystem, indeed that seems to be the issue: I am running a Windows Server 2012 R2 with a Software-JBOD-solution called DriveBender (which combines several physical drives into one drive letter and does some file-mirroring-stuff). I tried to move one of the not-recognized albums to the internal drive C of the Windows Server (this drive is not touched by DriveBender) and voilà, the album is recognized by the scan. So it definitely seems to be a DriveBender-issue. What I wonder about is, why I can access the files normally with any file manager. I can copy, rename, delete, edit, etc. with these files. I can open them in e.g. MP3Tag, play them etc. So I am curious about if and how (i.e. with which name/size/etc.) the LMS-filescanner recognizes these files at all (this information would also give me more details to address the DriveBender-developers). Do you have an idea how I could reproduce the scanner's file-identification-logic? I figured out the method Slim::Utils::Scanner::Local->find() in slimserver/Local.pm, but ... yah ... Perl 🙄. I am thinking of some perl-commands which list the directory's files and their attributes, helping me to understand how the filescanner sees these files... |
I'd start with a log file. As I said enable scanner logging in Settings/Advanced/Logging, run a scan, and see what it reports for those files. LMS and charsets on file systems have a difficult relationship. |
Okay, here we go: I copied those albums to a new folder, added this one as a new source and did an incremental scan (scanner.log.zip). Seems that non-1252-characters are read by the scanner-module as question marks only:
Strangely the filename-encoding seems to be correct later in the readTags-module: But I still wonder why it works when adding the files to the native file system. |
Are both filesystems NTFS? Or what are they? |
They are supposed to be NTFS, yes. The native file system is definitely NTFS and the ServerFolders-drive is the mentioned JBOD-system provided by DriveBender, which Windows also recognizes as NTFS. To be honest, it's not a super-big issue at all, I can name the files with codepage-1252-characters and that's it. I just found it strange, I never experienced any encoding-issues with that DriveBender-solution before, no matter if accessing the ServerFolders with Linux, Android or Windows-clients. Long story short: I don't want to steal your time in this minor issue, but if you like we could inspect this further. Do you have an idea, why the filenames appear with question marks in the Scanner-log, but with correct HTML-entities later in the ReadTags-log? |
Maybe that's interesting for you: I moved the albums onto the native (i.e. physical) drive and scanned again. Here the filenames are cut off in old 8.3-style on the "unknown" characters:
|
Could it be your main filesystem does not support legacy file formats any more? That's indeed a mechanism we're using to work around some limitations. Maybe https://support.microsoft.com/en-us/help/121007/how-to-disable-8-3-file-name-creation-on-ntfs-partitions is of any help? |
Okay, I tried several settings for 8dot3-filenames now, but I can't get it to work as it seems there is a general limitation for 8dot3-fallback in the DriveBender-software. For clarification: 8dot3-fallback does work on the system drive - the scanner finds files with non-codepage-1252-characters there by reading them as 8dot3-filenames. But the "virtual" pool-drive provided by DriveBender seems to not allow this 8dot3-fallback (no matter what is set in fsutil), so the scanner always recognizes these files with question marks for any non-codepage-1252-character, which then leads to the file being ignored on import. Anyway, I think I just have to take care that filenames are in codepage-1252 only. Thank you for your support! |
I have some mp3-files and folders my music library constantly refuses to scan/import. These files/folders all share a rather "exotic" name, with Turkish or Greece or Russian Characters instead of standard-codepage-1252-characters. See the following screenshots comparing media library and file-/folder-structure:
Am I correct supposing that all files/folders containing non-codepage-1252-characters are ignored while scanning? And if the answer is not codepage-1252, what are the "allowed" characters? Are these restrictions necessary/useful, thinking of middle-east/asian users of the software?
The text was updated successfully, but these errors were encountered: