Plans / Roadmap

[krateng]

3.0

• Move to a proper database (SQLite, ZODB?)
• Move imagecache to DB

3.1

• Scrobble deletion / metadata fixing from web interface
• Better API consistency, documentation and feedback information
• arm64 docker build

3.2

• Use linuxserver/docker-baseimage-alpine
• non-root user in docker
• Albums
• Separate threads for incoming image web requests and third party fetches
• Visual indicator for associated artists' scrobbles in scrobble bars

Planned

• Restructuring of the package for cleaner imports
• Fully customizable regex rules
• globalconf should eventually read directory settings normally (respecting default)
• Jinja: refactoring imports and includes
• Smarter RAM caching for DB
• Fix threading and proper process exit
• Artist aliases

Consideration

• Javascript-free version
• Import directly from Last.fm (and others) instead of having to download a file
• Import/export and scrobble forwarding between Maloja servers
• Genres

[FoxxMD]

For scrobble forwarding -- not exactly a solution for maloja per se but I could easily implement forwarding for multi-scrobbler. I already have this implemented for last.fm (last.fm -> maloja) so it would be trivial to reverse it or allow forwarding to multiple/arbitrary other maloja servers.

For import from last.fm -- I also have this "partially" implemented in that I already do the last 20 scrobbles from last.fm -> maloja. It would be pretty easy to extend this to fetching all prior scrobbles from last.fm and sending to maloja. It's been on the to-do list for awhile I just haven't gotten around to it.

[northys]

arm64 docker build

docker supports building xplatform images by default using qemu and it is ridiculously slow. it looks like your Containerfile is already buildable on arm platform. i tried to build it on my raspberry and it succeeded (it's actually still running but i see no reason why it should fail).

if you want i may try to take care of it. i'm curious how to do that. also, that would be my first time doing something with github actions and i want learn something new :)

[krateng]

I'd be very grateful!

[mariolopjr]

@krateng taking a look at the roadmap, it would be nice to have album support. Data-wise, it looks like albums are (temporarily?) stored in the extra column of each scrobble. In planning this work, I was thinking of first opening a PR to write a migration to extract the album from the extra and dump them into a new album table, with a pivot table of trackalbum (and clean up the old data).

Do you prefer small PRs that build functionality or open a PR with the first step and keep that PR open until the entire feature is complete?

EDIT: @krateng looking at the code, just to confirm my conclusion: artists, trackartists pivot is inserted 'on-the-fly' when accessed if it does not already exist (I may be misunderstanding the code)?

[krateng]

I appreciate the enthusiasm, but I'd like to implement core database changes myself since it would be more work to thoroughly review a PR than write the code. If you'd like to build the overview page, you could first build it with the data available - additional parts can always be added later.

[mariolopjr]

@krateng sounds good no worries! I'll take a look at expanding the current web, as well as working on at #97 as well. :)

[timkicker]

i think albums should be a priority. but i guess that'd mean an enormous restructure of the application?

[darknesswithsorrowtears]

I believe that albums are necessary for complete listening statistics, it would be great to see their support

[krateng]

Alright, I have implemented some very experimental album support.

Feedback please in #207

If anyone wants to try it and give some feedback how well it works with real world data, check out the branch https://github.com/krateng/maloja/tree/feature-albums. Make sure to backup your data first!

Right now, maloja accepts album information from new scrobbles; and you can try to parse old scrobbles with the command maloja parsealbums - this data will be available e.g. if you've imported from lastfm fairly recently. You can also do the usual web interface stuff like merging and renaming. Remember that css is often aggressively cached, so refresh that if the web pages look weird.

Also note that the parsing of old scrobble data will currently not find albums for e.g. navidrome scrobbles, but I will fix that. The parsing can always be redone later, so there is no damage in doing it now and redoing it later when more scrobbles are supported. (Now fixed)

[FoxxMD]

@krateng

Tested by building branch into docker image. 95k scrobbles. with maloja parsealbums i now have 14.4k albums and 17.7k album artists. took less than 2 minutes to parse everything! Thanks for putting the hard work into making albums happen.

Also digging the new UI on artist pages :)

A few points of feedback:

Top Albums?

You might already have this planned...I can access /charts_albums but its not available from the landing page. Are you planning on adding a Top Albums sections to the landing page? (please do)

Duplicate Albums for "Various Artists"

It looks like when an album has multiple artists attributed maloja creates a separate album for each artist combination scrobbled? I image this can be fixed by correctly scrobbling with the albumartists property (has albumartists always been available)? Or by manually merging albums (which works great!)

In my experience though, album names are unique enough that I would rather separate incorrectly merged albums than have to manually merge every album with various artists in my history. This also seems like it will always be the case for any scrobble client that doesn't support album artists in the scrobble payload.

Would it be possible to make that behavior configurable using a setting? Or maybe just a cli command that can automate merging albums with the same name.

Move this to a PR?

Not feedback on maloja per se :) To keep this issue from being derailed it might be better to open a PR feature-albums -> master and then ask for the feedback on the PR instead of here.

[krateng]

Thank you for testing!

As for the startpage, I was thinking of reworking that significantly which would then also make space for album charts, but I'm probably gonna do that after album support is fully tested and merged.

With the duplicate albums, I've encountered the same problem, but was a bit anxious about just picking the first album that has the right name per default - I can certainly look into making this possible if explicitly specified though.

And will open a PR, good call!

[duckfromdiscord]

I see genres under "Considered". Perhaps genres could be done thru something like everynoise and/or the Spotify API powering it?

[duckfromdiscord]

A "Now Playing" feature could be considered too. I'm sure multi-scrobbler can do that, Web Scrobbler possibly could also (I'm also probably going to do a pull request there to send cover art with a newscrobble if #248 happens, and I know that's possible since I asked the dev). The Audioscrobbler API supports track.updateNowPlaying, which I could even help in implementing.

The thing about multi-scrobbler, at least on Spotify, is that it knows the length of the track, so at least for that, we could have a timeout in Maloja after which the track is removed if the scrobbler forgets to remove it.

I'm working on a Discord bot for maloja users that acts similar to the Last.FM bot, but allows you to pair your maloja server to your Discord account and show off your stats. When it's further along, it will have very granular settings that will allow you to select what you want to keep private and what you want to show off. A "now playing" command would be absolutely awesome for my bot. I monologue about developing it in my server. I need to host it somewhere reliable, but once that's done it'll be great. Everything done in Rust as of now.