Audacious - OLD, PLEASE USE GITHUB DISCUSSIONS/ISSUES

If it would be useful to you, and you'd like to work on it, then by all means go ahead. Please submit a pull request once you feel the code is in good shape to do so.

Hi again,

It's been some time, but I've been working on it. Making a change so that album artist information is sent to last.fm is the easy part (I have a working version I've been testing since August). But some work is still needed before I can make a PR, and I'm not sure how to proceed.

During normal operation the plugin first writes the details of scrobbled track to the queue file (scrobbler.log). This is read from the queue on submission attempt, and once it's successfully submitted to last.fm the track data is removed from the queue. So in order to submit album artist information to last.fm, it must be written to the queue file.

Currently used format of queue file is some deep legacy stuff [1] (the URL referenced in the source code no longer works, but fortunately Wayback Machine saved it). The plugin doesn't fully follow this format anyway, and adding one more field to the file would mean further deviation.

When looking at this I am wondering if we could simplify the format. The "L" in the 6th field seems useless (the plugin never uses "S"), as is the track number (it's an optional parameter to last.fm API [2], but I'm not sure if the website actually uses it, and how). The really relevant fields are:

• Unix timestamp (mandatory)
• Track title (mandatory)
• Artist (mandatory)
• Album title (optional - might not be available)
• Album artist (optional - might not be available)
• Track length (optional, but should always be available)

So how about simplifying the format to remove the non-essential fields? e.g.:

1606948503    Cowboys    Portishead    Roseland NYC Live    Portishead    302

The format can be changed, and all is fine and good until one considers the possibility that the user has some data in their scrobbler.log file in the old format, and then updates the plugin. In that case the existing scrobbler.log file must be migrated to the new format (whatever it will be), otherwise strange things will happen. This is the point I'm currently stuck in, I'm not sure if I'm going in the right direction.

I imagine I'd have to modify Scrobbler::init() so that it checks whether scrobbler.log exists, and if it is in the old format. If it is, I'd have to set a variable so that a queue migration routine is called in the beginning of scrobbling_thread() (similar to the way config is migrated). And then implement the queue migration routine using some GLib file handling APIs. The old scrobbler.log would probably have to be backed up, and maybe some message should appear after queue migration (again, similar to config migration). But there's also some concurrency stuff involved, which I must admit I don't fully understand yet (how many scrobbling_thread()s can be spawned? What kind of race conditions are we trying to avoid?)

I'd appreciate some guidance here. :)

[1] https://web.archive.org/web/20180111003216/http://www.audioscrobbler.net/wiki/Portable_Player_Logging
[2] https://www.last.fm/api/show/track.scrobble

I took a brief look at the plugin code tonight. It's kind of a mess. If I were in your place, I would avoid getting any deeper into it than necessary.

Simply adding the album artist as an 8th field to newly-written log lines, sounds like a sensible option to me. Leave existing lines as-is, and update the parsing code (i.e. scrobble_cached_queue()) to be able to read either 7 or 8 fields. Then you can avoid doing a one-time rewrite of the log file.

That's just my two cents though. If you feel confident making bigger changes to the code and would like to refactor/clean it up a bit, that's fine too. What I'd like to avoid is adding further complexity without improving any of what's already there.

That's a very pragmatic approach. Adding a dedicated migration routine for something that will likely only be run once (and most probably never) sounds like overkill. I'll try to code something according to your advice in the coming days.

At this time I don't feel comfortable to make any non-trivial changes - as you probably saw from my question, I don't fully understand the code. In the future - who knows, maybe once I get to know the code better.

Hi John, thanks for merging my changes. There are some more things I'd like to work on in scrobbler2 plugin:

1. In your last post you mentioned doing some code cleanup - so how about removing the config file migration stuff? It's for compatibility with pre-3.4 versions, do we still want to support that?
2. The plugin doesn't use proxy settings from the main program - but I think that shouldn't be too hard to implement.

Would you like to discuss these here first, or do you prefer to have the discussion in GitHub pull request?

Those both sound like good things to work on! If you have specific questions feel free to ask here, otherwise go ahead and create pull requests when you're ready.