Messages

1501

Preview Build Discussion / Re: [BUG] MP3Pro plugin (in_mp3PRO.dll) doesn't load in WACUP 1.0.8.4334

« on: October 14, 2019, 01:50:15 AM »

It's most likely the native unicode changes that appeared in 5.3 that started to cause issues but 5.8 beta working is just weird as that's got other changes which the older plug-in isn't going to know about & might just be more luck that it works than anything as plug-ins interacting with other plug-ins is always messy at the best of times.

I've had a go with changes related to finding the appropriate input plug-in to use that I'd made without realising the crash reports were likely from you (it wasn't obvious they related to mp3pro playback) & I'm no longer seeing adding those files into the main playlist crashing instantly as was happening & they do play. I assume they're playing correctly as I see it's own ID3 metadata editor instead of what in_mp3 uses.

However I'm still seeing some issues like looking at it's file edit dialog which is crashing when closing it without making any changes & I've had the odd on closing error occur. Trying to have it use the normal (since 5.5) common file info / metadata editor support would probably be better than leaving it using it's own & the issues it's having (it's then just what happens if you try to edit the metadata when it's playing which isn't a good idea but people will do crazy things like that).

So the new build it will have the changes in it that appear to allow it to work ok for me (still need to do the portable mode test) & if that helps fix the crashing for you then I'll look into using via in_mp3's common file info / metadata editor support.

-dro

1502

Preview Build Discussion / Re: [BUG] MP3Pro plugin (in_mp3PRO.dll) doesn't load in WACUP 1.0.8.4334

« on: October 14, 2019, 12:26:15 AM »

Can you provide me an example file please though it working in normal mode is odd as I intentionally have my dev install using a non-standard folder to try to catch cases were plug-ins are looking in default/hardcoded folder paths.

I'll have to try a portable install but I've got a feeling the plug-in is doing something weird if it's trying to take over all mp3 handling so there might be an issue with it handing off to in_mp3 due to the age of the plug-in vs input plug-in api changes that have been made since 2005).

-dro

1503

Wishlist / Feature Requests / Re: Twitter post track count

« on: October 13, 2019, 05:08:43 PM »

Preferences -> Playback -> Twitter -> 'Rate Limits' tab & you can then change it from the 3 plays default.

-dro

1504

Preview Build Discussion / Re: [BUG] MP3Pro plugin (in_mp3PRO.dll) doesn't load in WACUP 1.0.8.4334

« on: October 12, 2019, 11:49:14 PM »

Erm, I'm not sure why it's not loading for you but I've just copy+pasted the attached plug-in into both my dev & playback installs & started WACUP & it loaded ok (Win10 x64 1903 & recent updates applied). I'll have to try out Win7 later on depending on your reply.

There's nothing according to Dependency Walker that shows it using anything funky with OS api defines so that's a bit confusing as to why it's giving the not loaded status unless something else is going on (A/V maybe?) that's preventing the dll from being loaded.

-dro

1505

General Discussion / Re: Is this an open source project or a hack

« on: October 12, 2019, 11:34:49 PM »

Sent .

I've just replied to the pm.

From what I've concluded, it's using inline patching (loader, RAM patch) as a deployment method. Is this correct?

The loader injects the wacup core dll into the winamp.original process when it's started as a suspended process with detours used since a few builds back to re-write the IAT to have that dll be the first one loaded so it can hook into things a lot earlier once it's allowed to run.

There's then my age old favourite of apihijack used for some aspects, RAM patch of some aspects (not much at all unless I've no choice) & subclassing (in combination with some of the apihijack handling) to override the window messages as needed (mainly for ensuring replacement API handling via WACUP is used vs the original winamp code).

It's not a permanent thing but just a means to keep things going whilst changing the engine as we're still driving. As I go along the aim is that there will be no winamp.original usage eventually nor the need for the loader & it'll then be back to a single exe (probably with the core maintained in a dll) & it'll be it's own thing separate of winamp but as winamp-compatible as I can make it (somewhat less of an issue when most plug-ins barely got beyond the 2.x api or any of the early 2.9x/5.x api additions).

Yeah, I thought it might be a bit far fetched to try and make the native Windows closed source plugins work with "native" Winamp Linux binaries (if they were released, some day) . Still, a nice idea IMO . WINE does a perfectly good job so far, and yeah, I'm not using anything else than the default Winamp 2.x skin, so things are fine the way they are now IMO .

WINE is fine & seems to have come on well & from some of the others who are using WACUP on WINE, it does a bit better than Winamp itself which wasn't always intentionally done but always nice to find out. Ideally there would be a way to do like is proposed but the design of the platforms just prevent that & other than some manner of proxying things such as from a mini WINE encapsulated handling to a native solution just rules it out.

But why not go fully open source? I mean... I can understand in places where there are licenses attached to binaries, but why not go fully open source if every module in Winamp gets replaced with adequate code and does everything that Winamp 5.x did (and much more in some cases)?

I have personal issues with open source as for the most part I see doing it as giving up on a project & some others have badly tainted my overall view of OSS as a negative experience. Then there's so much changing & being in flux at times I just don't think there's any benefit to me by going open source on the core or a number of the replacement plug-ins & everyone re-writes any released code so going for what works for my style isn't necessarily conducive for anyone else to help out with it being annoying for both sides. I know these sort of things can be resolved with time, setting down rules & all that but I'd also prefer to just get on with coding than the potential of managing things.

Additionally I don't want Winamp's owners getting their hands on things. Its unlikely they'd use anything but you never know with them & it's probably petty but that's the legacy they've helped cause & not wanting the snake to bite again.

Also when the likes of webamp have much more traction & barely receives patches / contributions, its reasonable that there will be even less interest in working on a win32 program as it's just not "cool" nor where interest is for others from what I've determined.

I have not ruled it out as something that can be considered later on but that would most likely happen when I loose interest &/or can no longer work on WACUP full-time which with the likes of patreon & other donations & being frugal in how I live to start with not being something I need to think about for a few more years.

And one other question. I read on the official Winamp forum that you're a former Winamp dev. Is this correct?

Guilty as charged. I was a 3rd party plug-in developer from late 2003 (used Winamp from 1999) & had the JTFE plug-in included in the early 5.x builds in 2004 (non-paid addition which is why it was allowed to have a donation button on its preferences).

Did a load more plug-ins & was then contracted to work on Winamp directly a few months prior to the v5.5 release (localisation implementation & some on-going support which meant I provided some bug fixes outside of the remit of my work because I was foolish unlike some of the others who just did they're contracted work & no more).

Then was I contracted on a rolling basis from 2010 until September 2015 when Radionomy ended things, with a split between SHOUTcast & Winamp over that time. It was more so on SHOUTcast but during the Winamp Cloud phase (late 2012 to mid 2013) & potential closing process in the second half of 2013, Winamp then was the focus (along with a bit of time after things were sold until it was officially halted mid-2014).

I was then convinced by some to do something around the start of 2016 after pretty much not having used Winamp since the September before & what was starting out as an update for the deprecated Winamp Essentials Pack has grown into WACUP & an attempt to provide a Winamp compatible replacement for Windows that is still supported (unlike the mess that is the 5.8 beta & its state as "not an on-going project").

-dro

1506

General Discussion / Re: Adding WACUP to the Default Programs list

« on: October 12, 2019, 10:46:53 PM »

My bad, I only saw the Wow6432Node related entries when I was having a quick skim through things at the time (had been a long day).

-dro

1507

Preview Build Discussion / Re: [BUG] MP3Pro plugin (in_mp3PRO.dll) doesn't load in WACUP 1.0.8.4334

« on: October 11, 2019, 11:47:47 PM »

Can you point me to the download for the copy of the plug-in you're trying to use please.

It's not something that is intentionally being blocked but as a less commonly used plug-in (same for mp3hd) it's not something I've actively tried out so either I've managed to break compatibility vs what 5.666 does (I refuse to install the 5.8 beta due to reasons) or it's just a quirky plug-in (also likely).

-dro

1508

General Discussion / Re: Is this an open source project or a hack

« on: October 11, 2019, 10:12:09 PM »

You'll need to PM me some details re: the failed user account as I don't appear to have any obvious non-activated accounts.

WACUP is a mismatch of new plug-ins, old plug-ins, some closed source, some open source, live code patches, hard-coded code patches, original compiled code & other aspects in-between that. You could say hack for some parts but then most software & original handling within Winamp is deemed a hack

I don't have plans to go 100% open source & in all honestly a solution for Linux is much better done directly than trying to re-work Windows specific code as Winamp / WACUP & related plug-ins have been coded. For the most part, most Linux solutions can do the classic 2.x style skins & that's alright for most. Plug-ins however aren't platform agnostic so you couldn't do things like running existing Winamp plug-ins within a native Linux / other platform as they're different designs of being run (sure some of the compiled code can probably do it but it's the equivalent of putting diesel into a petrol engine - both are fuel but it's not a good idea to mix & match).

-dro

1509

General Discussion / Re: Adding WACUP to the Default Programs list

« on: October 11, 2019, 10:03:31 PM »

A caveat is that what's provided (thanks!) is for a 64-bit version of the OS.

If only using WACUP then it's fine though the WACUP solution is going to change some of those values so it's simpler to run Winamp & WACUP side by side (primarily for testing purposes).

-dro

1510

Resolved Issues / Re: NTDLL.DLL crash on load (the other computer).

« on: October 09, 2019, 09:17:18 PM »

The feed url can be the same & that will keep working fine but it's the cotents within that can & will change with time. Ideally a feed should offer HTTP urls if it's from a HTTP feed & HTTPS from a HTTPS feed url but there's a general shift to just providing HTTPS urls irrespective as most clients support it.

Playing the feed entries as a stream is going to always fail with HTTPS urls as the solution that in_mp3 (the MP3 decoder & stream handling plug-in) uses doesn't cope correctly with HTTPS & so it'll fail. Nothing you're doing wrong, just the age of that (annoyingly) important plug-in means it's less compatible with the modern age than would be liked.

Anyhoo, I've added the HTTPS -> HTTP change to the todo list as it shouldn't be too much of an issue to get it done.

-dro

1511

Resolved Issues / Re: NTDLL.DLL crash on load (the other computer).

« on: October 09, 2019, 07:42:01 PM »

Oh, are you're trying to play the entries as a stream rather than downloading locally & then playing it ?

As the downloading locally is fine whether it's HTTPS or HTTP from a quick test of the feed. It's only if trying to play the stream url that you'll hit the issues with the MP3 decoder which is on the hit list to resolve but hasn't yet been done.

I guess I can try to force any HTTPS url to HTTP if in_mp3 is going to play it as an interim workaround until in_mp3 is eventually replaced (it's a bit of a pain as it's relied upon quite a few things especially streaming) & the worst case is you still don't have a working stream url to play.

-dro

1512

Preview Build Discussion / Re: Playlist Drag/Drop ordering in ML.. (this must be must me..)

« on: October 09, 2019, 06:15:52 PM »

Ok, maybe a pinned / favourite type setting would be better as a quick idea that's just popped in the ol' grey cell.

Whatever else might be done, allowing manual re-ordering still makes sense to get implemented in the root view.

-dro

1513

Resolved Issues / Re: 3 problems discovered in 4 days(read inside)

« on: October 09, 2019, 06:13:10 PM »

1 & 2) The url doesn't appear to be valid. You can attach things to posts or send an email over to contact@getwacup.com & mention this thread.

3) I'm still not following & have to assume it's what I'd tried to explain above. Can you give me some exact steps or screenshots or even a quick video to show the issue please.

4) This is a known issue & is something I've still to work out why it keeps happening nor why it doesn't happen in a consistent manner (i.e. it only happens for some but not all & not me sadly which makes it harder to work out what's going wrong).

-dro

1514

Resolved Issues / Re: NTDLL.DLL crash on load (the other computer).

« on: October 09, 2019, 06:00:48 PM »

Rob: If you can let me know the podcast url that's failing then I can look into it & I'd suspect there's something about it (format or even access issues) rather than SSL support not working as 90% of the podcasts I've got in my WACUP installs are HTTPS related.

The options in the preferences are to do with proxy support & the podcast downloading can make use of them but it's primarily down to I take the url, pass it off to libcurl & that then does the majority of the work & mostly succeeds (unlike Winamp's implementation).

quartzdoll: That's not necessarily going to help (especially as the loading issue is resolved) as WACUP ships with the supporting runtime files it already needs to save having to install it globally & to make it much easier to generate a contained portable install. Also the loading failure was an issue with an OS api being used & the only time that installing the runtimes is for 3rd party plug-ins where the developer has not accounted for it which will just prevent the dll from loading rather than causing the process to crash

-dro

1515

Resolved Issues / Re: NTDLL.DLL crash on load (the other computer).

« on: October 09, 2019, 02:01:40 AM »

The wonders of Windows programming never stops amazing & bemusing me but that's good to know it's been able to start ok in a normal location (i'll have to find & update the other thread where it was reported to see if that's also the case for them).

The vis window in the playlist editor is a known issue as I've not yet worked out what is causing that as part of the transition between winamp's code doing things & my code instead doing it (with the vis drawing still being something I've not tackled yet). It is a beta / preview after all

On first run of a new install, there should be a skin selection dialog that allows for selecting between the range of 5 skins that are included by default. the dialog is setup to actually try to force the user to make a choice instead of imposing a default unless using the likes of tabbing navigation at which point it will pre-select the classic skin as that tends to fair better from an accessibility view point.

As for classic skin scaling, that's a whole can of worms as the handling at the moment is still shy of being able to do double-size windows / frames on everything. WACUP does much better than Winamp in that respect as I've added support for the main playlist editor & the generically skinned windows (e.g. the media library window) with the video window the last on that needs to be replaced. Winamp proper just does the main & eq windows. When more of the handling is one by WACUP then I will be looking for classic skins to have some other scaling values as I don't have access to a 4k or a 1440p screen at the moment but I appreciate there is a desire from those using such screens for something that can play better with them.

-dro