WACUP
General => Wishlist / Feature Requests => Topic started by: akilleas on December 31, 2020, 11:51:58 AM
-
With the latest 2 versions I've tried, when you press Ctrl-Alt-N and you open a new instance of Wacup it doesn't keep the same playlist you've already made.
With older versions of Winamp the new instance opens with the same song in playlist.
Thanks in advance and a Happy New Year.
-
This is more down to a decision I made with WACUP & that mode where attempting to run another instance should have prompted to make a duplicate copy of the settings folder for the new instance to use after which that's what will be used going forward.
As generically running multiple instances on the same settings folder can & will corrupt the settings which I didn't want to get complaints about, hence the change in behaviour for a safer solution where each multiple instance ends up with its own settings folder.
I'll look into adding a compatibility mode so the winamp way can be used but it's really not something I recommend & will not be responsible for any data loss that occurs as part of opting in to that mode once it's added in a newer build. Though as I think about it, maybe I could have it maintain the settings copy but have it duplicate the current instances main playlist into the spawned one so there's less risk of data corruption.
-dro
-
Happy New Year to all the people around the globe. May the WACUM continues updating!!!!!
Thank you so much for your answer.
I understand what you mean and I appreciate you effort to look into it, whatever your decision is.
In my opinion, I would prefer multiple instances to keep the same settings and the last instance I will close to write the final settings I've made at that instance's settings file. Isn't that possible?
Thanks in advance
-
The "new" confirmation dialog is screencapped below.
Dialog Title: Open a new WACUP instance - are you sure?
Dialog Text: Are you sure you want to open a new WACUP instance?
This is not recommended as it can lead to data corruption (e.g. losing local library play counts & ratings) due to the multiple instances trying to update the same settings files.
You can choose 'Yes' to automatically create a copy of your current settings folder to then use. (Note: Any changes made will not be copied back to the original settings folder).
You can choose 'No' to use the un-safe behaviour & will need to remember to close the open instances last to first to help reduce some of the potential data corruption issues.
Dialog Buttons: Yes, No, Cancel
The Cancel button closes the dialog and ignores the keystroke.
The Yes button begins copying the settings folder. After the copy is complete, the new instance opens. (The copied folder is beside the original folder in %APPDATA%.)
I can't say what the No button does because I didn't try it.
Funny thing: If you do Ctl+Alt+N on the new instance, then the dialog pops up again. Choosing Yes makes a second copy of the first copy of the settings folder, and opens another new instance. The same naming convention is applied, so we get folder names like:
C:\Users\UsrNam\AppData\Roaming\WacUp
C:\Users\UsrNam\AppData\Roaming\WacUp_m
C:\Users\UsrNam\AppData\Roaming\WacUp_m_m
(screencap below)
-
'No' on that dialog is equivalent of Winamp's behaviour of just start another instance & not bother about maintaining data integrity. It creating a copy of the copy is expected as I have no reasonable way to know if that's the first / only instance to exist on the machine or if it's a copy from somewhere else that's being used & is why it's just simpler to offer to duplicate & minimise the conflicts that can & will occur by running things against the same configuration folder.
Multiple instances are honestly something I wish I didn't need to support going forward but I get that there's cases where it makes sense albeit at the inconvenience of data loss or having to manage dual instances which some are ok with.
In my opinion, I would prefer multiple instances to keep the same settings and the last instance I will close to write the final settings I've made at that instance's settings file. Isn't that possible?
There's no way to guarantee what settings from an instance will be saved first or last nor is there any tracking of things between the instances to try to marshal what's going on which is why it's a lucky dip on what happens. Additionally my approach with WACUP is to save settings when they change instead of waiting until a successful close & the problems that can occur if that doesn't complete cleanly (i.e. crash on close) & more things get lost.
More for my reference, I've still to actively look into this request with having it copy over the existing main playlist (if set to do so) when spawning the new instance.
-dro
-
wish I didn't need to support
Agree. Considering the complexity, if it were me, I would put in some architecture to disallow more than one instance from looking at the same Settings folder at the same time. A folder-level usage-lock, if you will. Various apps implement exclusion-locking in various ways, partly because OSes don't offer good support for this common use case, let alone there existing a cross-platform / portable solution for it.
-
Hello.
I’m facing a problem or rather a specificity.
I have a large playlist that I mostly listen and pressing the CTR+ALT+N button it opens a completely new instance (wacup_m) as I chose on the confirmation dialog discussed above.
So I pause the 1st instance and I when hitting enter button I want that song to be played with the 2nd instance. Sometimes it’s OK but sometimes it is loaded in the 1st. How can I solve this?
Keep up the good work!
Thanks in advance!
-
Are you doing the enter action in Explorer? If so then I don't know of a way to control the action without there being some form of ui interaction to pick what instance is used. Possibly the last interacted WACUP instance is the one that the OS / Explorer might try to send the action which might help to fiddle things around but that doesn't seem like it'd be helpful nor is it something I can see as being 100% the case.
-dro
-
Mostly I use XYPLORER and Windows Explorer.
I haven't thought about the last instance that I've loaded a track by enter key.
I'll do some more tests and report back!
Thanks for the quick reply!
-
OK. So I've finally figured it out.
I firstly open the 1st instance and must load a track with enter key via any file explorer.
Then I open the 2nd player that my favorite playlist is already loaded and everything it's ok now.
I've recently learned that I can set a global hotkey so I can copy the title of a song.
So here's another ''problem''.
It seems that I cannot set the same global hotkey to both of the instances.
Is there a way to do it, or I just have to change it for the 2nd instance?
Thanks in advance!
-
It seems that I cannot set the same global hotkey to both of the instances.
Is there a way to do it, or I just have to change it for the 2nd instance?
The nature of the OS global hotkey api is that only one action can be assigned to a key combination so you'd need to set a different one in the second instance which as you're using different settings folders for each instance will then allow that to be maintained correctly for those instances.
-dro
-
I thought of it.
Thank you for your reply!
-
Hello again.
The last months I can't open the second instance when pressing CTRL+ALT+N.
It does nothing.
Can you please help me?
Thanks in advance!
-
If it's been broken for months why only report it now? I can see that there's something not behaving during the new process spawning which'll need to be looked into so hopefully I'll have it resolved as part of the next build due out later this month.
-
Yes, you're right about being late reporting it.
You know I don't use that feature much, but last week I had to play music to an event and I finally couldn't use WACUP for this.
Is there a way that I can launch the 2nd instant manually before the new update?
Thanks for your effort!
Much appreciated!
-
You'd have to go back to a build that doesn't have the problem (I don't know what that'd be as fixing the issue instead of trawling back through old code commits was a better use of my limited time at the weekend). The spawning a new process shortcut from the current instance or using the /new command-line action when also relying on the use of another provided settings folder copy for it to use is what's triggering the problem to occur so for that I don't have any nice workaround unless you make another unrelated install & then mess around with trying to copy the existing second instance's settings folder into that or just doing it all from scratch with 2 different installs.