[Bloat Request] Local recommendation system based on weights?

[xplshn]

After skimming through articles about the details on how recommendation systems are implemented, it seems feasible even for small projects ; Without going too far we could make kew save the number of times a user's played a song, based on that, at runtime you would read the cache and recommend songs with a similar play time based on Artist and Album they belong to. A very simple approach., could be like a shuffle mode but instead the shuffling is done based on the user's preference. This might however be out of scope for a TUI music player, but its a feature I use when I want background music instead of a hands-on listening experience.

For example, the Ipod had a "shuffle" mode that, wasn't really shuffling at all, it wasn't random: https://github.com/LxEmily/iPod-Music-Shuffle

It can be done using the same idea, and the documentation contains the details on how it was implemented. If you deem this is feasible and, somehow in the scope of this project, there are various ways to adopt/adapt the work already done by others. I'd like to hear your thoughts if you like the idea of a simple recommendation system like this, or maybe not a recommendation system, but a "queue shuffler/generator".

[xplshn]

Also found these person's class assignment which implements a sorting algorithm which "Creates a playlist and shuffles the tracks in the playlist using the Knuth Fisher-Yates shuffle algorithm to create a random playlist where the same songs cannot appear until 5 other different ones have": https://github.com/bryansng/ipod-playlist-sort-n-shuffle

I also found this one file containing a similar approach, but there isn't much info about it: https://github.com/debo-7/A-Shuffling-Algorithm/blob/master/test3.c

[ravachol]

I think something like that could be interesting. Instead of shuffle it could be '>kew fav'. It would play the songs you listen to the most. There could be a key for this as well, Enqueue favorites.

[ravachol]

Or just Play favorites.

[xplshn]

Yup, the files I linked could be put in a single .c src file with which you may or may not compile the project., like a plugin of sorts/optional functionality. Given that kew already has a struct for song data, taking the Album & Artist data and grouping songs like that should be straightforward, and yeah, a :heart: character (B&W: ♥) could be used to mark songs as favorite/"Show me more of this". Also, what about a "stats" page? Putting all the misc functionality into a file called stats.c?

[ravachol]

I have some thoughts on this. I really appreciate the privacy aspect of kew. It's a valuable feature, that's rare in general. Adding a play favorites feature would create a database or a list of your listening preferences. It would be local, but could still be abused to snoop on people. I'm thinking not the free world here and all the potential things one could be listening to that are not government approved. Plus there would be more uncertainty: "is kew really private, or..? It's collecting all this data. Where does it go next?". One of the amazing benefits of OSS is that we have the choice to ignore the powerful commercial forces that drive tech companies to collect all this user data, or do other things that users don't really want but are needed for businesses to make a profit.

I think that maybe we should stick to total privacy, but I'm kind of torn as it is a good suggestion and nice feature. :)

[xplshn]

If a file which contains the liked songs of a user can be considered data collection then a m3u playlist that has indexed all the user's music can too...

Personally I don't hate any company or anything like that., I just use what works and what benefits me.

This proposition I make does not really have to use any API. And if it did, disabling could be as easy as compiling without libcurl or some other library you'd like to use for such a thing., personally I think the "stats" page is the most feasible implementation, where you simply have counters for how many times a song's been played and based on that you also determine the Albums and Artists that have been the most played by the user. Also that "cache" or "stats file" can be used for shuffling in a more deterministic way, same as an Ipod does (The original Classic series).

No need to sacrifice anything by using APIs., you can leave music metadata tagging up to the user. After all, kew's a music player, not a music library organizer, tagger or anything other than a SIMPLE music player.

[ravachol]

It seems to complicate things a bit. One aspect of it is that favorites evolve over time and by just counting plays, you could end up with a feature that's tilted to playing old songs that are no longer favorites. Ideally you'd need a timestamp on each play and a real database. And I think that's beyond the scope of this app. I want something that's really simple.

I don't think I will be implementing this, but you could give it a try if you want. There is now going to be an opt-in library cache that's TAB delimited and contains all the songs and folders in the library. A 'playcount' variable could be added there.

[xplshn]

No need for timestamps, if the file is over 50 lines long, or a line on the file corresponds to a song which no longer exists it can be deleted. You could even make a simple plugin "API" and have this be a pure SH script, that way Kew would remain very simple in nature, just need a socket that kew'd listen on for commands (play, stop, next, etc), also, I think if you go that route, the keyboard capture part could simply send orders to the socket file too and simplify things further, making "plugins" in reality just wrappers (in SH or other scripting languages which can execute external programs in the background). I believe this approach would make Kew even simpler, because you could point people that ask for further functionality to a simple "How to write my first plugin" page and just concentrate on making Kew a good music player and not a "do it all" program.

[xplshn]

I vouch for the simpler socket method. But it is your project and keeping tabs on the codebase is also really important.

[ravachol]

At this point, i'm really mostly interested in not growing the scope of kew and of improving the current functionality by fixing bugs and adding polish to little details here and there. The code will grow regardless because issues will crop up that need to be fixed, and yes some features will be added, but I'm trying to keep it at a minimum. Gonna close this as not planned.