Re: How can I speed up autoplaylists initialization?
Reply #9 – 2018-05-19 12:56:11
I'm curious about the level of complexity you have in your Autoplaylist properties: do you mind to share a couple of the "complicated" ones? I neves used Autoplaylists because, at the time, it was quite hard, or even not possible to change their definitions/properties after they were created. (GENRE IS garage punk OR %genre_family% IS punk OR GENRE IS punk blues OR GENRE IS noise rock OR GENRE IS post-punk OR GENRE IS gothic rock OR GENRE IS dream pop OR GENRE IS shoegaze OR ARTIST IS velvet underground OR ARTIST IS lou reed OR ARTIST IS pere ubu) AND (%date% PRESENT) AND NOT FAVOURITE IS 1 AND %added% DURING LAST 6 WEEKS SORT DESCENDING BY %added% Would I know how to create such a selection on the fly, using library search tools or library selectors, filter panels, facets or whatever? Of course I would, and I actually do most of the times, but writing it down as an autoplaylist format means taking notes and being able to pick up the work from where I left. As you correctly pointed out, the ability to edit the autoplaylist format after it is created, is crucial. Library selections are very handy, but they are lost once you change selection or you shut down foobar2000. For example the above autoplaylist was created at first because I wanted to compare some genres, but as I listened to it, I removed some of the genres and added others, because I realized it made more sense for my thesis. Then I realized it might have been useful adding some artists regardless of the genre tag. Then I decided I wanted to listen to the playlist in chronological order, therefore the date tag was mandatory, etc... This edits did not happen all at once, but over time as I listened to it. Saving the query as an autoplaylist also means keeping track of the listening progress. Most of these playlists last several weeks and even months, but foobar2000 will resume the reproduction from where I stopped, whenever I will reactivate the playlist. Of course this level of complexity is ridiculous compared to SQL queries you can find in a proper DBMS, but it is actually more complex than it looks, because the %genere_family% field is a customdb field, therefore the query is based on a sort of join clause. Needless to say, most of my autoplaylists are based on genre classification, where customdb is highly involved. For the record, the above playlist is initialized in 43 seconds.I was a fan of Playlist Tree (as buggy and slow as it were) because I could create very powerful queries that would let me easily have many different views of the content of my library (20k tracks, with an average of 15 tags each, many of them multivalue). It took two or three minutes to get FB started but that on an Atom 330 @ 1.6GHz; 1.5GB Ram; W7 32bit SP1. I wouldn't blame it all on the atom. If I remove all my autoplaylists, start-up time is only 16 seconds, including the initialization of a dozen jscript panels. But that's my point, and I'd really appreciate a developers' hint here: how helpful would a faster processor be? Would I be better off trading some MHz for more cores or viceversa? Should I save money on the CPU and rather invest in memory? memory bandwidth? memory size? Should I look at disc speed instead? All in all I don't think there's anything wrong with this behavior, foobar2000 works great, it is a lightweight and fast player. Actually foobar2000 can run queries and initialize autoplaylists faster than any other player I tested (most of which can't even handle autoplaylists, let alone tag customization options, which can make autoplaylists really powerful). Fact is I abuse of autoplaylists, I'm aware of it, and I'm looking forward to understand what hardware I need to support at best my bad habits.