Feature #284
Scrobbler 2.0 doesn't scrobble all the tracks of an audio stream
0%
Description
I just had a short look at the source of 3.4 beta 1 and it seemed to me that the plugin does not have a proper treatment of audio streams.
The problem is, that a stream is one item in the playlist. But it anyway may consist of different tracks that are provided by the stream. This can usually be noticed by the changed title information as soon as a new song starts.
It looks to me, that the current code scrobbles a stream exactly once. So only one of the tracks in a stream is transmitted, which is likely not, what one would like to have.
John Lindgren added last summer a patch that solved this issue by also taking the appropriate actions in case that a change of the meta data was detected.
Furthermore, this is also related to the "Listening Now" feature requested in #261. Last.fm only displays the listening now information at most as long as the title lasts according to the information transmitted to server for listening now. The problem with tracks in streams is that you do not know, how long they will still last from the moment that you started listening to them. But in order to display the track in any case as long as you listen to it, you would have to initially assume a huge length for all stream tracks, but there might always be tracks even longer. In the end, the old scrobbler plugin just assumed a short length for stream tracks initially for "Listening now" and after that period had retransmitted another "Listening now" request with an increased length for the track.
Those aspects were discussed in feature request #109.
To sum it up, I'm quite happy that somebody provided a clean implementation of the scrobbler plugin. But anyway, I would be more happy to also find a decent treatment of audio streams in the new scrobbler plugin. Maybe we can use this as a starting point for further discussion.
History
#1
Updated by Luís Picciochi over 11 years ago
Updated by This is a known regression, as stated in #189.
When you mention "streams", I suppose you're referring to typical Internet audio streams. Can you provide an URL for such a stream where you see this problem occurring?
I haven't really studied this issue as I'm not an usual stream-listener myself, but I can try to fix this when I have the time and if there's people interested.
#2
Updated by John Lindgren over 11 years ago
Updated by http://community.loudcity.com/stations/adagio-fm/files/show/MP3-hi.pls is one example of a stream with changing titles. (It may be problematic for scrobbling since it combines composer, performer, album, and title all in one string. Probably we should handle splitting the string in the MP3 plugin to close #205 as well.)
#3
Updated by John Lindgren over 11 years ago
Also -- I didn't mention this in the release announcement, because it's not really supported -- you can still use the scrobbler plugin from 3.3.4, if you rename it to scrobbler1.so so it doesn't conflict with the new one.
#4
Updated by Michael Jacobs over 11 years ago
Updated by I agree with John, that the correct splitting of title and artist from the transmitted Stream is another problem.
But it seems to me like a different task. To me, it seems (as you also stated in #205) that it is more a convention, that the servers always transmit [artist - title] in the title field than a reliable rule. After all, for other stream formats (e.g. ogg), this might be different. To solve that issue, I would rather think of allowing the user to locally define meta-data rewrite patterns that can be applied to specific streams. In that sense, one could think of a default rewrite pattern for MP3 streams that always treats it like [artist - title]. I have not yet thought about that for too long.
I see that I can reuse the old scrobbler plug-in for the time being as soon as 3.4 will show up in my distro's repository. I agree that this feature is for sure not the most urgent. Here the point is again, as already for feature #109, I am not too sure, if there is anybody else besides me who really cares about this too much. If this turns out to be the case, then maybe I can provide a proposal for the needed extensions if I find the time to. Then we could use it as a starting point in order to arrive at an extension fitting to the quality standards of the new plugin at some point.
#5
Updated by Michael Jacobs over 11 years ago
John Lindgren wrote:
Also -- I didn't mention this in the release announcement, because it's not really supported -- you can still use the scrobbler plugin from 3.3.4, if you rename it to scrobbler1.so so it doesn't conflict with the new one.
Is it somehow possible to keep the old scrobbler plugin only in some defined location in my home directory instead of having to mess around with the folder created by the package management system?
#6
Updated by Michał Lipski over 11 years ago
Updated by Sure, you can keep it at ~/.local/share/audacious/Plugins/
#7
Updated by John Lindgren almost 8 years ago
- Assignee deleted (
Luís Picciochi)
#8
Updated by John Lindgren over 4 years ago
- Status changed from New to Rejected
Closing feature requests that have not seen activity in over 3 years
