Waveform Seeker not working on network drives

[kikendo]

This was working fine but suddenly not anymore.
Whenever I try to load a file from a network drive, I get a "Waveform Unavailable - Cannot Be Processed" error.

Local files still work fine.

[edit] more info, realized that this only happens when you have any network drive mapped as a drive letter. It then affects reading waveforms from all network mountpoints. If you remove this network mapped drive, it works again.

[jungletek]

[...]
[edit] more info, realized that this only happens when you have any network drive mapped as a drive letter. It then affects reading waveforms from all network mountpoints. If you remove this network mapped drive, it works again.

I wasn't seeing this, and I have my main music folder on an NTFS-formatted drive in an Ubuntu box, shared as an SMB share from there, and mapped to a drive letter on my Windows machine.

Then I started playing with the entries in the right-click context popup when you right click on the seek/waveform area, and can trigger similar behavior, though I don't need to remove the share to get it to work again (interestingly enough), and I don't get any "failure message" like you do. I just need to go to the next or prev track, or toggle the state of the "show waveform for selected playlist item", although the latter doesn't quite work properly, and I think this is likely where the bug lies, or should at least help track it down:

What I've noticed so far is that there seems to be some sort of inconsistency in the state of the "show waveform" feature, so there may be logic issues there when changing/setting/tracking/checking the state variable (presumably a bool?).

Why do I say this? If I disable it just now, for the first time on a playing track, it redraws the waveform (although the waveform looks slightly different than the initial displayed waveform) and otherwise behaves as though the "show waveform" toggle is still enabled, rather than giving me the plain seeker widget (which is the expected behavior, I think?). The waveform in this state still updates, and can be clicked on to navigate as normal. However, the right-click context menu shows NO checkmark next to the "show waveform" option.

If I click the context menu again to enable it (as far as the context menu UI is concerned, the check mark shows again) again, THAT'S when it seems to break the waveform display portion, as the colored portion representing the already played portion of the waveform disappears (the "shadow" of the waveform is shown, and there are no updates made).

If I toggle it yet again, the context menu show's it's supposed to be off, but the waveform display returns again, and works as expected.

When I skip to a new track, the state of the waveform display reverts to "on", effectively, regardless of the setting of the context menu toggle. (i.e. I can consistently trigger the funky out of sync state of it, but it reverts to a default of "on" at next track playback, ignoring the setting of the context menu).

Did I confuse you? I can provide screenshots or video, even. Let me know. Also, as this may or may not be 2 different bugs, or expression of the same base bug in 2 different ways, (admin/mods) let me know if you want me to make a separate thread for the behavior I've seen/documented.

P.S. You duped this thread: https://getwacup.com/community/index.php?topic=2423.0 , if not others (of which that one may be a dupe too). It's common courtesy and practice to search to see if there's an existing thread for the issue, so issues don't get duplicated and clutter the board and cause more work

[dro]

The checks to see if a network drive is valid aren't coming back in any consistent form from the OS apis trying to be used (which is done to try to avoid the main ui thread locking up for some of the actions that will otherwise block if trying to access a disconnected network share). Everytime I think I've found a solution that'll give me what I need it seems that it doesn't actually work (e.g. mapped drives set to be remembered by the OS are always being reported as being there even when the likes of 'net use' show them as being disconnected & I can't find an OS api that will act like the 'net use' command does). As for everything else in the other post, if it's being messed with too often the processing queue for requests can break or it's stuck waiting to complete on other things which will cause it to enter a weird visual state to avoid causing the rest of the program to fail). It's all just shit coding on my part once again.

[jungletek]

It's all just shit coding on my part once again.

Brutal and probably a bit hyperbolic. Be easy on yourself, it sounds like it's Microsoft's fault anyway with the way they document (or don't) their API(s).

Any way I can help get you data on this?

[dro]

Wherever the issue lays, the buck stops with me when I'm the one doing the coding.

For the network share vs mapped drive detection the code is now only looking for what's reported as 'connected' & then trying to do a quick(ish) check to see if it's able to be accessed (am seeing around 3-5 seconds delay if it doesn't for which I'm not going to start changing registry keys to try to lower it since it's a global settings). There's also a 'remembered' state which for what I was seeing from testing will also appear as connected even when it's not (the bit that 'net use' is distinguishing which I can't seemingly do as just an api call) which made the prior code act like there were no network shares using a mapped drive letter since it was afaict meant to imply a disconnected device but that doesn't seem to be the case.

I've also changed a number of the internal file existence checks to avoid using the one that's causing the above problems & is still needed for some aspects in wanting to try to quickly bail out of accessing offline network shares / mapped drives & moved a few things around to not block the main ui thread. Doing all of that I'm no longer seeing the 3-5second wait for my x64 dev build to appear when loading & the last main playlist item is on an offline network share.

For the other waveform seeker issue with not seeing anything when messing with the playlist selection, I've made a small change that appears to better ensure on those selection changes that it'll make the window painting re-check if it needs to do a proper refresh or not. That for what I was seeing when changing from the current playlist item & going back to it resolves a blank window.