Skip to main content
Topic: Component management. (Read 548 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Component management.

In the 3rd party plugins section, I've posted about a problem I'm experiencing after a component update that I'm being told could be due to having too many of them. Due to the way that happened, I'm not entirely sold on the idea, but the potential need to do away with some of the components I have installed has brought new relevance to some concerns I've been having for a long time about the whole process of component management within foobar2000.

I was going to just put this in the same thread, but I think it probably should be put in a new one here:


Apart from components from the official repository, I also have a handful of others from a number of places. Like the SoX-based resampler found in this board, one or two exotic (videogame) inputs from another place, and possibly something else... Keeping these updated requires manual work and I don't expect foobar to provide automatic checks for them, but, maybe, at some point, it could be possible to give foobar a list of local folders (and URLs?) to check when updating (maybe a separate button or a checkbox for "external sources" or whatever), and have it install whatever components it finds in those places. That would certainly make the process a lot smoother.

Also, once installed, it's very easy to forget which components are on the repo and receive updates automatically and which are not and require manual checking and/or downloading. If foobar could mark or highlight them in some way, it would be really helpful as a reminder.

In addition, if this problem of loading failures is indeed caused by an excess of components, couldn't something be done about it other than just having to sacrifice some?
The most convenient way for the user would be, of course, if foobar could dynamically manage the loading and unloading of those components depending on whether they are being used. Yeah, I realize this is easier said than done, and I don't want to come across as a captain obvious. Maybe you are already working on something to that effect. I have no idea.
The next best thing would be if the user could selectively put some components in a "low priority" or "don't load" list, so that he doesn't have to actually remove them and loose track of them (maybe keep receiving updates for them, even if currently unused?), so that, if he eventually needs them, he can just check another component/s off and enable that one.
As an addition to this, it's not vital, but, it would be very convenient if that loading limit could be worked into this so that you already get a warning when you try to apply a list with too many components enabled, or not enough disabled, depending on how you look at it.

Re: Component management.

Reply #1
In addition, if this problem of loading failures is indeed caused by an excess of components, couldn't something be done about it other than just having to sacrifice some?
Something has been done. foobar2000 v1.4 bundles the required C runtime libraries allowing third party components to use it dynamically. Components compiled that way don't waste FLS slots.

The most convenient way for the user would be, of course, if foobar could dynamically manage the loading and unloading of those components depending on whether they are being used.
Can't be done without changing the component system into something simpler. The components live and can do their work before user even sees UI or the core has loaded configuration.

Re: Component management.

Reply #2
Pointing foobar to auto-download from some unknown URL sounds like a nice way to get malware.

As far as I remember you can already drag and drop multiple files to the components page to install/update the components in foobar accordingly. Just put all your "external" sources in a folder and drag them in once a month or whatever. What components change so often that you absolutely must have the newest version at all times and they aren't on the official repo?

You can put a list.txt in said folder or use your browser bookmarks to keep track of non-repo files/sources. You have to check these manually anyway, so what difference does it make whether foobar itself offers you a glorified notepad experience? You could even use download managers pointed at the URLs which will update the contents of the aforementioned folder if that's what you want.

How many components do you actually use? I mean really use. As I remember you can install possibly hundreds of components before hitting the limits, I very much doubt you actually use most of them. What's the point of hoarding them?

Similarly, what's the point of putting components on a magical "I don't actually want this, but I want this on my PC" list? How is it beneficial to update these in the background if they won't be used? What stops you from simply getting the newest version once when you actually want to use it?

If you are (presumably) testing components so regularly, wouldn't it make more sense to use a portable install and use it as a scratchbook for testing random stuff one at a time?

While I don't think the suggestions are inherently bad (e.g supporting more is "better" than supporting less), it seems to me that you want the program to work around what is essentially a people problem. Let's say total possible components is raised from 100 to 200. Won't you just start hoarding up to 200 and run into the exact same problem again?

Re: Component management.

Reply #3
@Case  Thanks for the techical bits.

@Daeron OK, I don't agree with what you've said, mostly your angle of doubting the usefulness or how unappropriate a solution this is to a problem you see very differently, nor how you'd go about solving it (basically thing's I've already considered and tried and, as predicted, don't really go well with how I keep things organized in my storage, or how I'd prefer to, anyway).

But, before discussing anything else, give me your opinion on this:
Keeping everything else as it is now, what do you think about a feature, already mentioned by me, but not commented on by you, to have foobar somehow let the user know what components of those installed are available on the repository and, thus, will be automatically updateable and which aren't and won't? Sounds like something that wouldn't be too hard, and I'm saying it humbly and not disregarding the effort that would go into it, and it would make a night and day difference for me.

I don't think that explaining how I keep things organized in my HDDs would be of much use here. Suffice to say that I like to keep local backups of many things, well organized and categorized, in ways that I've never seen anyone else do. Ideally, many things would work in very different ways in, but, since that's at best, decades away, IF it will ever come even close to be, I settle for simpler things and try to come up with simpler ways and methods to bridge the gap between my way of doing things and how the world generally does things. The folders/URLs list for updates seems like a simple way to do it in foobar's case. What you propose me to do doesn't help me at all and the way you've put it sounds like you are talking down to me and that I don't know what I'm saying, which is not very nice. I won't comment on every point youve made, because you are attributing to me things that have nothing to do with what I said.

I do have a tendency to explain things in too much detail and even comment on possible tweaks and additions to the principal idea. I feel compelled to do that out of the experience of too frequently having people not get what I'm talking about, getting it all wrong, and/or failing to see these potentialities. I think I take care to make it clear that these are not the main point, though. One of these would be the "updating of disabled components" point. Pay attention to how I worded it, with a "maybe", a question mark, and even putting it inside parenthesis: "(maybe keep receiving updates for them, even if currently unused?)". You seem to have taken particular exception to that, mocking it as "magical" too, and I don't think there was need to, to say the least.

Also, your assumption about me "hoarding" components is rather misguided and a tad presumptuous. For starters, the things I "hoard" are on the functional side of things: Decoders, unpackers, some DSPs, some metadata related components... stuff like that. I don't even have any visualization or gui customization stuff, so it's hard for me to come up with stuff to remove. I'm not opposed to it, and I do intend to sit down and review everything I have, and will probably do away with some of them. I'm sure there are some "leftovers", so to speak, but as far as that being THE method to ultimately solve this, I find it rather unsatisfactory.
Yes, I do have things I rarely use, but even that is hard to keep track of in an orderly way. In practive, once you remove one, it kind of disappears in the mist and you'll never see it again. Text files, bookmarks (browser or on disk), and such methods don't really scale up well nor adapt to what I'm trying to do. I tried.

Now, let me rant a little: As a general comment, not specifically about foobar2000 (and you can certainly ignore this, particularly if it offends you), the truth is that I find the current paradigms of software management for desktop systems rather lacking and needing redesign. Also file/content management in general, to be honest, which, one being designed on top of the other, helps lead to this stituation. In a way, they are the main factor factor that can lead to this "hoarding" issue. Since they don't really scale up well, nor do they provide the tools to properly manage large "collections" (and I'm not talking about "big-data"), it forces the user into two fields with a very complicated middle ground: Either you just keep kind of minimalistic installations (programs, extensions to programs, files and collections of them) where you basically know everything by heart, or you try to keep large organizations with very inadecuate tools, with the most advanced ones imposing a very narrow vision and a superficial and inflexible paradigm of organization, or you lose your mind and end up an actual hoarder.
I admit, though, that there's a very fine line between hoarding and what I'm trying to do, which, at this point, seems as if it will never materialize in my lifetime.

Re: Component management.

Reply #4
Adding a "Does this component receive updates from the central foobar repository?" column to the components page sounds like a reasonable and perhaps not too complicated to implement suggestion to me.

My questions were not meant to be derogatory. I don't think the word hoarding comes with any negative connotation either, at least I don't read any into it.

I'm simply trying to get an insight into what specific use case would warrant to basically industrialize the distribution of components so much in what is essentially a "simple" desktop music player with a handful of optional components. One that has been around for quite a while and the rate at which new components or updates are coming are not at breakneck speeds either.

(This is a simple observation from the perspective of a user and not a stab at the developers obviously. Arguably the fact that the forums aren't constantly filled with feature requests/complaints means what's already there is mostly very solid and covers a wide range of use cases.)

It's not that parts shouldn't be improved (or that there's nothing to improve), it's just the reality of making major changes like that would take significant amount of time and effort, so it needs a very good reason to consider doing it in the first place, as opposed to working on something else.

And I'm not sure how many users are in the same boat as you on the having too many components front, to make this a high effort/high (positive) impact change as opposed to high effort/low impact. Of course I only have my empirical evidence from using foobar myself and how I imagine others are using it. Which is keeping a handful of components you like and getting rid of everything else.

Re: Component management.

Reply #5
I'll chime in on the component-junkie front, I personally ran into the limit twice before. It wasn't terribly hard to get rid of a few components that I didn't *really* need but it still didn't feel great to be taking away functionality from a piece of software I use religiously. Perhaps a good example of perspective is that I want fb2k to be as versatile with format support as it can be, so I have just about every format extension there is. I like feeling like I could throw almost anything at a program and have it work (which foobar does really well for my retro game OST archive).

Re: Component management.

Reply #6
All my updates going forward will not be eating into the FLS slots, as they'll all be dynamic builds. They'll still work in 1.3, for now, but they're only guaranteed to work in 1.4, as 1.3 doesn't bundle the Universal CRT.

SimplePortal 1.0.0 RC1 © 2008-2019