[RESOLVED - NETWORKING QUIRKS] Waveform Preview No Rendering in new build

[xy0]

The Waveform Seeker reports:
[Waveform Unavailable - Cannot Be Processed]

Tested with multiple types of tracks and different settings within the widget like legacy rendering.

Win10

[dro]

Are the files on a NAS by any chance?

[xy0]

Sort of! I just realized that it generates fine for local files, but not for the ones on a mounted network drive.

[xy0]

What I've tested:

mp3 on my mounted "User" drive, U:/  Waveform works
mp3 on my mounted "Media" drive, M:/ Does not work

So I tried matching permissions, full control, owner, re-mounting a new network drive, network share, different letters, putting it in the root of the drive, still does not work.

I find this odd, and I know it's low-priority and i don't know if anyone else has this issue. But it's such a cool, useful plugin. If you want to pursue it I can dump logs.

[dro]

Indeed that is odd especially if the permissions appear to be ok. Only thing would be for me to try to report back what a potential error code from the attempt might be otherwise it should be down to the OS to prompt if needed to get the permission needed to access things if there's a problem afaict (at least that's what I vaguely remember it trying to do with accessing some network shares).

[xy0]

Reporting in to say that this and other playlist oddities were fixed via this investigative process:
in cmd, running "net use" and noticing that the drives that didn't work were mapped to ad\share_name (using my home active directory namespace)
and the ones that worked were mapped to fileServer\share_name
so I changed the mapping my my "media" drive to match fileServer\media_folder

and things work brilliantly. Also the indexing speed is amazing now, so kudos! <3

[dro]

That's good to know that you manged to get things working. Am also wondering if some of the network path handling changes made in the builds from this year could've helped where it was incorrectly failing on trying to access such paths where the status wasn't certain which caused it to generically fail any access attempt when it should've made an attempt (as it now does). That path handling also got an option to allow for it to be disabled via the second options page of the advanced prefs page.