WACUP
Preview Build Discussion => Preview Build Discussion => Topic started by: wbpayne on April 19, 2024, 09:20:16 PM
-
I've installed the newest preview build today, build 1.99.11.18916. I'm seeing an issue when switching skins. If I switch from a modern skin to a classic skin, and then try to switch back to a modern skin again without restarting WACUP nothing happens. WACUP will remain using the classic skin until I restart it and then I can switch to a modern skin without issue.
This didn't occur with the previous preview build. I'm more than happy to test any fixes that you may come up with to see if they solve this issue and am more than happy to provide any diagnostics you ask for.
Thanks,
Wilhelm Payne
-
I've had another user report this earlier today despite it not having been mentioned with any of the betas from the prior few month's so I'm not sure why it'd now be messing up other than it's somewhat the nature of trying to re-use the modern skin plug-in gen_ff dll from 5.666 & something yet unknown to me isn't working right.
Compared to the old preview they are for the most part 2 different implementations now & gen_ff was never really meat to be able to work outside of a native winamp implementation as WACUP is now doing.
All I can suggest for now is to try running wacup using wacup.exe /procdump to see if there might be a weird crash happening (something that gen_ff can randomly do) & it could be that's happening & measures to try to avoid a full crash are actually working at the expense of a weird non-skin changing experience.
-dro
-
I did some messing around and in my case if I start with a modern (like Bento) or classic skin (Nucleo_NLog_v102_.wsz) and switch to the Built-in classic skin then it doesn't want to switch to either a modern or another classic skin afterwards unless I restart. Going between various other classic or modern skins doesn't seem to be an issue.
I don't change skins much so not something I would have caught before. I'll try the Procdump process.
Edit: Sent a procdump in email. Hopefully shows something related to this.
-
Have now replicated the issue & am looking into what might be going on.
-dro
-
There'll be a fixed build in the day or so. The problem has existed for a couple of years in my code & despite it not having been changed for the new build (haven't gone back & checked other recent beta builds) it seems to be manifesting in a more consistent manner if going to the base skin is involved as part of the chain of switching attempts.
-dro
-
Thank you for looking into this. Thanks MarkRH for sending dro the procdump so quickly. I'm glad to know that this will be fixed soon.
-
There'll be a fixed build in the day or so. The problem has existed for a couple of years in my code & despite it not having been changed for the new build (haven't gone back & checked other recent beta builds) it seems to be manifesting in a more consistent manner if going to the base skin is involved as part of the chain of switching attempts.
-dro
Hello, fisrt of all thanks for your great work.
Related to the skin problem i'm suffering something similar (i guess :-\), in my case it only happen with Bento skin, if i change to any skin and try to go back to Bento using the skin list from right click menu it just switch to classic skin, the only way to go to bento again is opening preferences window and select bento on the skin section.
Another thing that i noticed is that i can't change the skin directory, the "Set skins directory..." button doesn't do anything, is not grayed out, it just do nothing when is pressed, tried runing wacup as admin just in case but the problem persist.
Thanks again for all your work, have a nice day
-
Sorry Darkhell, I'm not able to replicate your Bento skin switching issue. I can confirm that clicking the "Set skins directory..." button does nothing.
I can also confirm that the initial issue reported by wbpayne and MarkRH (which was also happening for me in the previous beta builds when switching to the base skin) is fixed in beta build #18980.
-
I can confirm that clicking the "Set skins directory..." button does nothing.
Have added it to the todo list though I've not checked why it's not reacting like it should.
As for darkhell's reply, I'd need confirmation whether it's happening with 18980 or not as I can't get that failure to occur & only can with the older 18916 build which was the one out when this thread was started.
-dro
-
Have added it to the todo list though I've not checked why it's not reacting like it should.
...
-dro
As far as I'm concerned, take your time. I have no need or desire to change the default skins folder.
I also should stop posting in preview build threads, since I don't use it. It's just that I look at all posts and sometimes what is reported for a preview also happens with a beta.
-
When the beta & the preview are the same build then it's fine.
As for the prefs issue, I had a todo note in the code since it wasn't something I'd yet implemented when dropping legacy mode & should've had the button be disabled. As that prefs page used to heavily manipulate what the winamp core was providing & when all of that got dropped I'd just not gotten around to implementing it since I'd not had to when the winamp core was able to handle the action for me. Is now sorted for the next build.
-dro
-
... when all of that got dropped I'd just not gotten around to implementing it since I'd not had to when the winamp core was able to handle the action for me. Is now sorted for the next build.
-dro
With all you do by yourself, it is quite understandable when some things fall thru the cracks. :)
I'm still wondering why anyone would want to change the default skins folder. Although, at some point, someone will try to use any option that looks like it may be used.
-
I can confirm that clicking the "Set skins directory..." button does nothing.
Have added it to the todo list though I've not checked why it's not reacting like it should.
As for darkhell's reply, I'd need confirmation whether it's happening with 18980 or not as I can't get that failure to occur & only can with the older 18916 build which was the one out when this thread was started.
-dro
Hi, after a lot of trial and error i've found how to trigger the problem respect to the skin that doesn't load , how it triggers is really weird tbh :o, for some reason (idk how to describe exactly), if there is a folder or a file in the root of the skin folder with names that start with "a" or "b", depending on the following 2 or 3 letters that accompany them, it affects the load of Bento and/or Big Bento, iv'e recorded a little example, in the video u can see how it changes the .ini file too:
https://www.youtube.com/watch?v=LWssrfy0T28 (https://www.youtube.com/watch?v=LWssrfy0T28)
Respect to the ability to change the skin folder, well, is useful if u have a skin collection and don't want to move to the installation folder to be able to use them
-
... if there is a folder or a file in the root of the skin folder with names that start with "a" or "b", depending on the following 2 or 3 letters that accompany them, it affects the load of Bento and/or Big Bento, ...
I'm using the x86 beta build v1.99.12.18980.
I'm currently using 16 modern skins and 10 classic ones (excluding the default built in one). I have 5 folders and 1 file in my skins folder with names that start with "A" or "B". The folders contain the files for various modern skins (such as the Bento skins). The file is an archive file for a classic skin (Bento_Classified.wsz). What are the following 2 or 3 letters that trigger your issue? I would like to try to replicate this.
It is not clear to me which .ini file is changed and what the changes are. The winamp.ini is updated with the name of the skin being used when a session is shutdown, so that the next session is started with the same skin. The studio.xnf file is similarly updated if the skin is a modern one.
I have no problems switching among all the skins I'm using, using any and all of the methods currently provided.
-
It's likely how I'm mapping the skin file / folder to a menu item index & based on the video it seems to be counting the empty folder which depending on how the drive returns the order of files (normally alphabetically with ntfs) would then place an a / b named folder before the bento skin items which if it's what I'm thinking would cause it to act as is shown (i.e. it's selecting the 'hidden' empty skin & reverts to the default skin instead of skipping that folder & using what was set for the menu string).
-dro
-
I'm using v1.99.12.18980 x86 too, currently for troubleshoot purposes i've renamed the WACUP folder that is created in "C:\Users\***\AppData\Roaming" su when open wacup again a new WACUP folder is created there with all default settings, so no custom skin path, just the default one with the skins that comes with wacup; respect to the file/folder name, the next letters that work (behavior is a little different depending on if is a folder or a file) are, for 2nd letter a,b,c,d,e,f,g,h (i, j, k, etc appear to not trigger the problem) ;for 3rd one i'm not really sure (maybe 3rd, 4th,.. letters are not really relevant), but for example:
If i put a file "bet.txt" then can't load big bento, if rename the file to "bat.txt" then big bento works and now bento doesn't load.
If i put 2 files at the same time, "bat" and "bet", then can't load bento neither big bento
Respect to the .ini file i mean the "winamp.ini" on "C:\Users\***\AppData\Roaming\WACUP", the line "skin=" points to the applied skin, if bento is selected then the ini shows "Skin=Bento", if i trigger the problem with file "bat.txt" then wacup writes the value of skin as trigger file/folder name, in this case bat.txt so in ini it looks as "skin=bat.txt"; as far as i've observed studio.xnf data is irrelevant for this bug
i attach my ini file; just in case, i'm on win11 23H2 build 22631.327 with latest .NET Framework 3.5 y 4.8.1 para Windows 11, version 23H2 para x64 (KB5036620)
-
Hi dro,
Interesting info. My Windows Explorer file manager lists all folders and files in alphabetical order, but the OS doesn't usually return them to WACUP in that order.
In the preferences Skins - Manager Settings - Skins Menu section, I have only selected the "Alphabetically sort the menu entries", "Ignore the information WACUP provides ..." and "Do not show empty / invalid skins ..." options. I've also selected the "Big Bento Modern" choice in the "Prefer" drop down box. However I get consistant, but unexpected results, that I have gotten used to. The classic skins are not listed in alphabetical order. The modern skins are listed in two groops. 7 of the skins I use that come with the installation package are listed at the top in non-alphabetical order. The other 9 are 3rd party and are listed in alphabetical order (below the 1st group).
I have also disabled the "Use the orginal skin selection ..." option in the Skin Browser section. I couldn't select skins in the main Skins tab's skin browser until I disabled that option. All 26 of the additional classic and modern skins I use, are listed in alphabetical order in the skin browser, with the default built-in classic skin at the top. Thank you for adding the folder icon next to names for skins that are in folders. Since I put all my modern skins in folders, it makes it easy for me to tell modern from classic skins.
-
...
If i put a file "bet.txt" then can't load big bento, if rename the file to "bat.txt" then big bento works and now bento doesn't load.
...
I've tried this. Putting (non-zero) text files with those name in my skins folder (which has the default name and location) after a shutdown. After a restart it made no difference, I'm still able to select and switch among all 27 (including the default built in classic) of my skins.
It seems to be something about the way you have installed and/or are using WACUP that is the problem, instead of WACUP itself. I'm probably wrong and you have found a needle in a haystack. I do that a lot. :)
-
It's likely how I'm mapping the skin file / folder to a menu item index
It was that but not quite as I first thought. The problem is that it's adding invalid items (e.g. empty folders or non-skin files) into the internal list which shouldn't have been happening & when there's mostly no other skins than the default skins it ends up using the wrong entry due to it finding them before the default skins when the a/b naming aspect is involved.
The alphabetical order is somewhat involved but the default skins per the skin manager prefs page also note those are excluded from the default alphabetical sorting & with the invalid item in that list it skews the mappings & so the wrong skin gets used.
tl;dr: needed to move 1 line of code to after some skin validation checks were done.
-dro
-
So it is a real bug in the code. I assume selecting one or both of the "Ignore the information WACUP provides ..." and "Do not show empty / invalid skins ..." options protects me from the error.
-
It is & those options won't help as the issue arises before any of that is run. The number & names of the skins found is also what made it more obvious with a default install & no other skins being the reliable way to replicate it against what was shown in the video of the issue.
-dro
-
Hi Darkhell,
JFI, I'm using the same OS files as you except my OS Build is 22631.3447. Anyway the OS has nothing to do with the bug. Dro has explained why I didn't replicate the issue. I'm glad you found that needle in the haystack. :)
Observations like yours are making WACUP more and more robust.
-
Thanks to both for taking the time to look into this, best wishes for both, have a good day