2.80/Wine on El Capitan: doesn't read full subdirs anymore

Hi mp3'ists!

working flawlessly and to my greatest joy until now, I note a strange misbehaviour.

Organizing a rather large library (100k+ tracks), I forced myself to subdivide into a dozen genre-directories which makes the huge beast better manageable on players.

The data is all mp3, ID3/covers embedded with a %artist% - %album% (%year%) scheme, living on a reasonably fast, NTFS-formatted external 3TB HDD.

Now here comes the catch:
until the last Wine-version, everything went as expected and even large directories were processed correctly, displaying up to 12k tracks.

Yet now, mp3tag only reads a smallish portion of each directory, namely 80 tracks out of e.g. 964 folders (!) which should add up to approx. 10k tracks … so <1% off existing tracks are displayed.

Even if the folders are made smaller with ca. 100 subdirectories … nothing changes: still a only partial recognition.

What am I doing wrong?

Could you check the statusbar and see if really only such a small amount of files is loaded?

If the figure of the loaded files is much bigger than the number of displayed files then I suspect that you have applied (unvolountarily) a filter. Press F3 to toggle the filter and see if that does something for you (except toggling the filter).

Hi Ohrenkino,

thanks for answering so quickly.

There's no filter set, positively. All blank below there.

I wonder how the phenomenon described relates - as this never happened before.
Can an NTSF formatted HDD be a reason?

Yes, this could be exactly it:
you have accidently entered a space character in the filter box - and now you see only those files with a space in it.
Press F3 to remove the filter altogether.

In respect to the NTFS I have nothing to add.

Hi again, Ohrenkino.

I double-checked: no space, no nothing in the filter line.

Meanwhile, the symptoms become more spooky:
I restarted Wine/mp3tag and voila: thousands of files present. Sacrificed a small mammal, sweared to donate you millions.

Ended the session, restarted to directory /++FIXTHIS (my workbench), again having displayed only 46 audio files in 7 directories while there are in fact 120 directories / 831 files (see screenshots attached).

(Reanimated the small mammal :wink:

This is the basic problem with remote diagnosis:
I cannot look over your shoulder.
What is different for those files that got loaded and those that have not.
As MP3tag does not even load them, it looks to me as though they do not get recognized as valid files.
Just a shot in the dark: could it be that some folders have a space character at the end? This would be illegal for windows file and folder names ...

These characters are other candidates for hickups: < > ? " : | \ / *

Hi remote Doc,

yeeeess, spaces at the end of the folder name could be a reason (as these are generated from Album names in my use case).

I'll investigate and report.

checked the ca. 2500 directories that are neatly clustered into 450 subdirs. No spaces and the end of the directory name. No anomalies.

As I am on OSX, using mp3tag in its Wine container: could there be a reason … just wild guessing.

Again: if a function sometimes works and sometimes it does not then there is most certainly a reason for that.
But all in all it looks like a very local problem that you have to investigate, esp. as both reaction occur on the same machine.

So the basic question remains unanswered: what is the difference between those that get read and those that are not even detected as valid files?

(the forum UI just gobbled up my reply - again)

Recap / forensics:

\\?\unix\Volumes\skbox-- SORTTHISOUT\ is the directory I keep all mp3s to rework.

If this is set as the starting dir of mp3tag/wine, then some files/directories are read yet not all.

Working through those loaded, using the 'remove'-command to remove the finished from the UI until it is empty works for me. After all are done, I reload the same dir and sometimes new files appear, sometimes not.

Result: I never know if all files are read in or only a portion. And if it's only a portion, I cannot tell the reason.

Comparing the UI-results with a straight ls-Pipe to a dir.txt shows the same — yet no structural difference, no anomalies. No forbidden characters, blanks whatsoever. All dirs/files seem to be named technically correct.

(edit) earning some credibility herewith:

attached, find two screenshots. The first <mp3tag_ui-view.png> shows the 466 files as displayed by mp3tag/Wine.
The second <mp3tag_present-missing.gif> shows the same directory viewed through a file manager (DC Commander alike File Explorer on Win).

As there are no visible differences or anomalities — the phenomenon should be described sufficiently by now. BTW: r/w rights, ownership is identical to all files. As the user logged in, I do have all rights to manipulate files, no locks or whatsoever.

<sigh — and kudos for answering so quickly>

Ha! Another, further indication comes up on my side:
As OSX natively isn't able to r/w NTFS, one needs to deploy FUSE, TUXERA or similar to enable NTFS as a filesystem.

As my Tuxera licence expired, out of a sudden, NTFS wasn't readable anymore and HICKUP: all files were readable in a single bunch, all appeared in mp3tag/Wine.

That might be a suspect then?

I do not understand: is no everything in order again?

For me these further programs are an indicator that you have an exotic setup that needs some attention. MP3tag is not the cause but the messenger.

… will check later today.

For the moment I understand the possibly wacky NTFS-read tool could be a suspect.
Reinstalling, optimizing the configuration, than reporting back here.

Answering your question: yes - thousands of files appeared, 30k+ …

All solved and de-bunked by now.

I formatted another HDD with exFAT, copied files there — no errors, all files readable.

The seemingly non-reliant TUXERA tool for OSX was the most likely cause.
Learned: exFAT is the format of choice if you're cross-platform, cross-device.

Thanks for your attention, this item may be closed now.