Asking for help from an experienced user

[dakoot]

Hello, I switched from Winamp 5.7 to WACUM yesterday and I'm having two problems that I cannot find the solutions for.

  The first is that the player isn't interested in sorting songs by their ID tag track number, but instead always sorts them alphabetically no matter how I change the AFP formatting. All my audio files are sorted into folders as albums or EPs and properly tagged.

  The second problem is that no matter if I enable or disable the always on top feature, it is always on if the player is maximized (not allowing me to access the taskbar). Sometimes a thin row of white pixels appears on the bottom of the screen when maximized.

Thanks in advance for any help!

[dro]

1) What part of wacup are you interacting with - main playlist, library view or library playlist or something else ? As I need a bit of clarification on where & how I'm meant to try replicating the issue

2) What skin are you using? Though none of the skins should be covering the taskbar unless what the skin is determining as the area isn't correct.

-dro

[dakoot]

1) What part of wacup are you interacting with - main playlist, library view or library playlist or something else ? As I need a bit of clarification on where & how I'm meant to try replicating the issue

2) What skin are you using? Though none of the skins should be covering the taskbar unless what the skin is determining as the area isn't correct.

-dro

Hi, I think I've solved the first issue I was having. The library playlist was set on sorting things alphabetically, I did not know that it will sort albums that way as well. I should've looked for more ways to solve this issue myself, sorry.

I'm using cPro 2 Aluminium. The issue was already present before switching from OG Winamp to WACUP. I'm including a cropped screenshot of the bottom of my screen. I put some purple around it so that the row of white pixels would be more visible.

[Aminifu]

I use the Windows feature that hides the taskbar until the mouse is pointed at the edge of the screen where the taskbar is docked. If I set the taskbar to remain visible, some of the modern SUI skins I use cover the whole screen and some leave the taskbar visible when I maximize them. When I maximize the modern SUI skins I use with WACUP, I want all of them to cover my whole screen. So the behavior dakoot is talking about is not a bug as far as I'm concerned and I've never seen a row of white pixels on the bottom of my screen when these skins are maximized. I sometimes use cPro 2 Aluminium II by Victhor and it only covers the whole screen when the taskbar is set to hide.

I start apps that I may want to use while a skin is maximized before I maximize it. Then I can use the Alt-Tab keys to switch among these apps and WACUP. If I still need to use the taskbar, I return the skin to normal size while I do so.

[dro]

If the taskbar is set to auto-hide then the full window space excluding any appbars (docked windows) is what the skin is meant to use so the taskbar will then just pop-up over it when needed.

If the taskbar is set to be always visible then the skin isn't meant to cover that & should be fitting within the area. If it's overlapping the taskbar then that is the skin doing things wrong unless it's been intentionally coded to use the monitor size instead of the screen workspace.

However I've now had a look & it seems that the specific skin for some reason is using 1 pixel less than the area it's meant to be using when set to maximised. Depending on what is set as the desktop image & other windows running will affect how obvious this might be. Not sure if that's a per-skin or a cpro framework issue & is something that can hopefully be looked into later on.


@dakoot: The library playlist views only sort by the single column & there's no associative / contextual sorting as the view currently is intended to be similar in behaviour to the main playlist editor. A more local library view like experience (multiple / custom columns & associative sorting (so album is taken into account for an artist) are on the slightly later down the road todo list).

Winamp also never had such support as library playlists basically just have a pre-formatted title string & duration to show unlike a library view which has access to the pre-cached metadata but it's something that keeps cropping up & needs to be done to make things more flexible.

-dro

[Aminifu]

If the taskbar is set to auto-hide then the full window space excluding any appbars (docked windows) is what the skin is meant to use so the taskbar will then just pop-up over it when needed.

...

-dro

It appears to depend on the skin. Some of the modern skins in my collection (or panels within them) cover the whole screen when the taskbar is set to auto-hide and the taskbar doesn't pop-up then pointing to the bottom edge of the screen (where the taskbar is docked). Sometimes, depending on the skin panel that is maximized, a few pixels across the bottom of the screen are not covered. In these cases, pointing to this area does cause the taskbar to pop-up over the skin.

For example, the Komodo X Touchscreen v1.0 by Victhor has 7 panels that can each be maximized. The media library and video panels leave the pixels at the bottom of the screen uncovered when they are maximized. The other 5 panels cover the whole screen and thus prevent being able to make the taskbar pop-up.

As I stated in my earlier post, this behavior is not an issue for me. I like having a maximized skin cover as much of my screen as possible.

I usually return a maximized skin to normal size before switching to another skin. Two days ago (Aug 5th) I managed to make WACUP crash when switching from a maximized modern skin to another modern skin. Today I did virtually the same thing and WACUP didn't crash. I think the crash report was sent. If not and you want to see it, I can PM it to you.

[dro]

The never ending consistency from the constant inconsistency in the different skins let alone what they do within themselves.

I've not got any outstanding crash reports to look over but generally anything that's obviously gen_ff related gets skipped as the issues are beyond my binary patching skills currently.

-dro

[Aminifu]

The report states "Exception raised by the recover callback handler". But as you say, it's obviously related to gen_ff weirdness.

[dro]

The error description is more for my benefit to quickly see what might have triggered the crash so it varies by the mode & means of the error being caught / reported. That description currently (as I've tweaked what I collect & output with time to try to get a better idea) is the generic catchall which usually means something went awry & the OS has gotten involved (typically a hung / unresponsive state which you as the user then tried to interact with something & then the OS force closes things).

-dro