Messages

1486

Resolved Issues / Re: Persisting Last Opened Directory (Add Folder) /Better Handling of Excluded Files

« on: January 06, 2020, 03:45:15 PM »

#1 is a bug as it's meant to do that but doesn't do it correctly as part of the transitionry work.

#2 is already meant to be checked for & prevented against but will look into what's going on.

-dro

1487

Wishlist / Feature Requests / Re: New Milkdrop defaults

« on: January 06, 2020, 03:37:49 PM »

However, I would like see some improvments in MilkDrop in the future, if that falls in the scope of WACUP.

What sort of improvements?

-dro

1488

Preview Build Discussion / Re: CD Ripping?

« on: January 06, 2020, 03:36:32 PM »

The plug-in that handled it was replaced under WACUP but is only capable of doing CD playback at the moment.

Ripping will get re-implemented (since it's just playback with file conversion) however burning support is something I'm not sure about trying to re-implement.

For burning I have wondered about doing enough to create the file(s) needed to then be passed onto a dedicated burning program.

-dro

1489

General Discussion / Re: plugin development ressources

« on: January 06, 2020, 03:23:48 PM »

Apologies for the delay in replying.

I never found that aspect of the wiki all that helpful. Depending on the type of plug-in you're looking to make it's often much better to have a look at an existing plug-in to get a better idea otherwise some of the older Winamp SDK's included a selection of simpler examples that might also help.

You can ask on here or drop me an email or get on the discord & that might be quicker to help with programming related questions.

-dro

1490

Resolved Issues / Re: Playlist does not show queued items

« on: December 22, 2019, 12:06:36 AM »

Alas it's a known issue with the current build (it goes back 2 builds from what I remember) where it fails to work in some installs.

It's already fixed for the next build, just it hasn't been released yet - is likely the next preview build will be available early January.

-dro

1491

Wishlist / Feature Requests / Re: Podcast art cache

« on: December 17, 2019, 04:51:08 AM »

Well I thought I'd do my Sunday night R&D session today & have a quick look into this & that's all I've spent the day doing *shrugs*

The next beta build will have an initial implementation that will create & use folder.<image_type> for the feed artwork - there will be no options, no handling for feed items doing their own thing & it's purely to see if all of the changes that have been needed to get it working do actually work. If they do then it can be refined later on but I've spent more time on this then I should have done so something will be better than nothing for the time being.

-dro

1492

Skins / Re: Classic Skin Color Variants

« on: December 16, 2019, 09:56:01 PM »

It is possible if the author of the classic skin has gone to the effort of providing colour variants & you've got them available. A few would include the additional versions within the skin zip & you then have to manually extract / install them as needed to be able to make use of them.

However there's nothing in place that will do it like the modern skin colour themes support.

-dro

1493

Wishlist / Feature Requests / Re: Podcast art cache

« on: December 12, 2019, 11:04:19 PM »

The podcast view is not like the local library views - I just pass a simple HTML blob to the IE based browser & it's left to get & render things as needed & this is one more reason why I really would prefer not having any browser aspect as part of WACUP as I can't cleanly display things but am at the mercy of how whatever engine being used wants to work. There are means to pass the image data (if present via the existing artwork service) in as part of the HTML blob but it wasn't implemented from the start as the artwork handling support coming from Winamp's core & associated input plug-in had issues (and still does for MP3 based files until that's completely replaced).

My suggestion to disable the display is purely there as a temporary workaround to alleviate the issue being seen until a solution is implemented as unless it's part of the downloaded episode file (as the local library view uses) then it's a web request without any knowledge of the local file info.

That is why I was saying about doing things akin to local files & how artwork is managed for that but due to the dynamic nature of feeds, it needs to account for external changes as that is what will happen & people will get annoyed if it then shows the wrong artwork. But like I also noted, I don't know without actually looking into it what sort of cache life information I'm going to get back from the feed to help manage keeping things current which is for the overall image & not the per-episode aspect since that would have to be tagged (which is another issue as that doesn't work correctly).


tl;dr - temporarily disable artwork, something will be sorted that tries to use local copies depending on how the embedded IE wants to work & embedded browsers are an evil I really could do without (or people formatting information for feeds consistently which ain't going to happen...).

-dro

1494

General Discussion / Re: Portables, Syncing, Metadata

« on: December 12, 2019, 10:51:02 PM »

I don't really have much to suggest as I've not directly touched the portables support so the only thing I can assume is that there's something else indirectly changed which is causing the issue.

Portables support is something that needs to be planned out as to how to best replace it but in all honesty, it's not something this high up on my priority list & I'll have to allocate some time now over the first few months of next year to see if there's anything obvious I can try to fix with the information the handful of plug-ins involved might be trying to use (this is one of those cases where source code would be helpful but is also why a replacement plug-in of some form is needed).

-dro

1495

General Discussion / Re: Bluetooth Headset & Auto Pause

« on: December 12, 2019, 10:45:50 PM »

What output plug-in are you using under WACUP? As it's not something I'm aware of being directly coded into WACUP (especially if out_ds is the plug-in being used which hasn't been altered from what 5.666 uses) & it might be more down to the output plug-in &/or how the interaction with the OS/audio driver works.

Alternatively it might require selecting the specific device in the output plug-in config but I'm not sure what else is going on as I've no bluetooth devices to even try to replicate the issue.

-dro

1496

General Discussion / Re: Playback speed faster than in Winamp or any other audio/video player

« on: December 12, 2019, 10:40:24 PM »

I'm not sure what to really suggest other than first confirming the issue doesn't happen without any additional dsp plug-ins & if it doesn't then trying to work out which plug-in is causing the issue.

-dro

1497

General Discussion / Re: MTP Issue

« on: December 12, 2019, 10:38:18 PM »

That's useful to know that MTP is still funky & i'll need to think about this when I proactively look at replacing the existing portables support - it won't be like for like (android/mtp/usb is probably the main things it'll be aimed to support).

As my first experience with MTP was with the nexus4 & trying to get Winamp's support at the time to work with it without crashing which helped resolve some issues but not all.

-dro

1498

General Discussion / Re: Duplicating Smart Views

« on: December 07, 2019, 12:30:46 PM »

Those don't exist yet (will be worked on early next year/month) as the replacement plug-in isn't feature complete.

Its being included as a means to test the base plug-in to ensure it can work (i.e. views not crashing like ml_local can) without the additional features.

-dro

1499

General Discussion / Re: Duplicating Smart Views

« on: December 05, 2019, 12:17:07 AM »

Oh ok, that's one less thing for me to fix

-dro

1500

Wishlist / Feature Requests / Re: Podcast art cache

« on: December 05, 2019, 12:16:15 AM »

Am sure I said I'd get around to looking into this on discord. Though the display of the artwork in the info shouldn't be stalling the UI (sounds like that from the later part of your post) unless I'm missing something from my testing. The alternative option is to check the option on the Podcasts preference page to not have it show the artwork


The key things that I'm not sure about & is why it's not been actively looked into doing this yet is how to detect when the artwork has changed (stale artwork is bad) & where its best to keep the cached artwork copy (with commonly having per-episode artwork, a cache folder could grow quite large).

For the first aspect I'd need to see if there's anything hinted at in the web response when first getting the image to know how long it's deemed as valid before re-requesting it. Otherwise I don't know if it makes sense to just update it when updating the feed in general.

For the second aspect other than trying to leverage the artwork from the downloaded episode file (if that's happened yet), it'd have to mirror the main feed image handling (assuming any of that is viable for the request) & just dump it into a cache folder until/if it's then embedded in the downloaded episode file subject to support to do that.

-dro