Closed GoogleCodeExporter closed 9 years ago
Hello,
It is not possible to get the name of the album of the track that is being
played
through the API that Mobbler is using, so therefore it can't be submitted for
Music
Player tracks.
In the case of tracks played from the radio we do know the name of the album,
but we
don't submit it anyway. Perhaps this should be fixed.
Michael
Original comment by eartle@gmail.com
on 22 Oct 2008 at 8:04
Last.fm says:
==
b=<album>
The album title, or an empty string if not known.
==
So it's not optional if it's known. And in some cases we do know it. So I would
call
this is a bug.
Original comment by hugovk@gmail.com
on 22 Oct 2008 at 9:44
Well, there is a function to get the album from the music player at the same
time we
get the artist and track. I'm just working on it now (for music player and
Last.fm
radio).
Is there a way to verify on the Last.fm website whether it is actually
submitting
the album?
Original comment by hugovk@gmail.com
on 22 Oct 2008 at 12:27
There is no way to fetch the name of the album through the music player remote
control api. Mobbler's music app observer interface allows for the album name
so
that if it observes music players where the album name can be found it can then
use it.
The album name is known for radio tracks though so the only changed that needs
to be
made should be in DoSubmitL and DoNowPlayingL of CMobblerLastFMConnection such
as below
-form->AddFieldL(_L8("b"), KNullDesC8);
+form->AddFieldL(_L8("b"), iCurrentTrack->Album().String8());
Original comment by eartle@gmail.com
on 22 Oct 2008 at 1:12
Yep, got the AddFieldL() stuff.
So is there any point adding this to CMobblerMusicAppListener::NowPlayingL()?
trackTitle.Copy(iMobblerMusicApps[musicAppIndex]->Title());
trackAlbum.Copy(iMobblerMusicApps[musicAppIndex]->Album());
...
HBufC8* title = CnvUtfConverter::ConvertFromUnicodeToUtf8L
(trackTitle);
CleanupStack::PushL(title);
HBufC8* album = CnvUtfConverter::ConvertFromUnicodeToUtf8L
(trackAlbum);
CleanupStack::PushL(album);
...
iCurrentTrack = CMobblerTrack::NewL(*artist, *title,
*album, KNullDesC8, KNullDesC8, trackLength, KNullDesC8);
CleanupStack::PopAndDestroy(3, artist);
Original comment by hugovk@gmail.com
on 22 Oct 2008 at 1:47
Committed the fix for Last.fm "now playing" and actual scrobble submission in
r52 in
the hugovk branch. How can this best be verified?
Should the CMobblerMusicAppListener::NowPlayingL() stuff above also go in?
Original comment by hugovk@gmail.com
on 22 Oct 2008 at 4:06
Just a question from a guy who doesn't understand C++ at all:
would it be possible to fetch the album name with
"MMPlayerRemoteControl::GetCurrentPlaybackCategoryL"
Get information about the Music Library category that is currently open for
playback.
Parameters:
aCategory Category type. EMPlayerRCtrlBrowseNone if not playing a
category.
aPrimaryValue Category value (e.g. artist name if aCategory is
EMPlayerRCtrlBrowseArtist). Maximum length for the descriptor is
KMPlayerRCtrlCategoryLen.
aSecondaryValue Secondary category value. Used only for album name
for EMPlayerRCtrlBrowseArtistAlbum category. Maximum length for the descriptor
is
KMPlayerRCtrlCategoryLen.
aPlaylistId In case of an user playlist, this is the playlist ID.
aTrackId ID of the track which is currently playing.
If I understand this thing correct, if I play some song from Artist->U2->War,
this
function (or whatever is called) will return aCategory = Artist, aPrimaryValue
= U2,
aSecondaryValue = War and etc...
Original comment by spassov
on 23 Oct 2008 at 7:10
I think the primary and secondary values depend on what the category is. I
think the
category depends upon how the user got through the menus to the track they are
currently listening to. So yes, in some cases the primary or secondary value
would
be the album name, but not in all.
I think this is the best chance we have at getting the album name so we should
probably call this API, do a switch on the category value, and then either get
the
album name from the correct primary/secondary value, or get nothing.
Original comment by eartle@gmail.com
on 24 Oct 2008 at 9:22
Is it worth?
Personally, album info is something I hardly use. The charts I find useful are
the
ones by artist and track, not album name. And as it doesn't seem easy to do...
What do you think, guys?
Original comment by tonilounavarro
on 24 Oct 2008 at 12:13
tonilounavarro, this is about sending the album name from Mobbler->Last.fm, not
about getting any info from Last.fm->Mobbler.
I've had a go with GetCurrentPlaybackCategoryL, and unless I've done something
wrong
(which is possible), I always get aCategory = EMPlayerRCtrlBrowseNone ("main
view"
according to the header file) no matter how I choose navigate to choose the
track.
I've committed the stuff I mentioned in comment 5 above, but that probably
won't
help too much... (In r82 of the hugovk branch)
Original comment by hugovk@gmail.com
on 28 Oct 2008 at 3:57
I know it is about sending the album name from Mobbler to Last.fm.
And I think that if it is so hard to do as eartle suggets it is not really
worth for
me, as I don't use the album statistics from Last.fm
Original comment by tonilounavarro
on 28 Oct 2008 at 6:13
Where are the album statistics on
Last.fm?
Original comment by hugovk@gmail.com
on 29 Oct 2008 at 5:06
http://www.last.fm/user/{username}/charts?subtype=albums
Original comment by spassov
on 29 Oct 2008 at 5:42
Thanks spassov. I've verified that albums for the Last.fm radio are being
scrobbled
(the fix from comment 4 above).
That leaves the albums for music player still open. Like tonilounavarro, I
don't use
the albums statistics (partly because I didn't know they were there!), but it
would
still be nice for them to be scrobbled if possible.
Original comment by hugovk@gmail.com
on 29 Oct 2008 at 6:44
I've got a prototype fix for finding the Music Player album name, it's in r84
in the
hugovk branch.
The CMetaDataUtility API can read mp3 metadata, we just need to know the
filename.
Don't know that? Well, we know the artist and track name, so we've got a very
good
chance of finding it!
First, search for files matching the track name. Those with the artist in the
path
are more likely to be correct so prefer those (because some artists might share
track names, or for partial matches). Finally, if a match shares the same
artist and
track metadata, then grab the album metadata!
This prototype fix only searches for mp3 files under E:\music, and it finds the
album almost immediately. It's not perfect, but is working quite well for
properly
named files. I expect there may be a false match if you have two versions of
the
same song by the same artist but in two different albums, but hopefully that'll
be
rare and sometimes the title will be slightly different (e.g. for live versions
or
remixes). It could be made more robust by confirming some other metadata we
know,
like duration.
One of the benefits of submitting the album is the album artwork is shown
instead of
the artist on under "Recently Listened Tracks". It's also good to see my artist
chart finally filling up now, and not just scattergun albums from Last.fm radio
(e.g. http://www.last.fm/user/{USERNAME}/charts?rangetype=week&subtype=albums ).
We could also grab the track number, which Last.fm would also like submitting.
And
even better, now we have a good idea of the path/filename, we could attempt to
read
the album art from the ID3, or look for folder.jpg (or maybe even any image) in
the
same folder and show that in Mobbler.
Original comment by hugovk@gmail.com
on 31 Oct 2008 at 1:51
I really don't like the idea of searching through the file system for this kind
of data.
I was just looking at the API found in the developer library here;
S60 3rd Edition SDK for Symbian OS, Feature Pack 2 > C++ API Documentation >
S60 API
Reference Guide > C++ API Reference > S60 Platform Services > Multimedia
Services >
Content Listing Framework API
With this API (3.1 onwards) you should be able to list all audio files and find
the
one with that Mobbler knows the track name and artist name for and then get the
album
name from it.
You seem to be able to modify meta data through this API as well. Maybe this
could
be used for the image tagging we were talking about.
Original comment by eartle@gmail.com
on 31 Oct 2008 at 2:17
Yeah, that approach was a bit heavy. The Content Listing Framework looks just
the
ticket, and I've got a fix that's working well. I'll check it and test it more,
then
when I submit it it could do with a good code review.
(Using this API we should also be able grab the track number, something else
Last.fm
would like submitting, and also the path and filename if we ever need it.)
Original comment by hugovk@gmail.com
on 11 Nov 2008 at 2:41
Fixed in r101 of the hugovk branch to find the album name for Music Player
tracks,
using the Content Listing Framework.
When we start playing a track, and don't have the album, try and find it from
the
CLF model. If the model isn't ready, refresh it. This is quick but
asynchronous.
When it calls back, check for a matching artist and title, if it has an album,
update the CMobblerTrack.
There's a limitation to using the CLF: if you modify any artist/title details
in the
Music Player, it updates the metadata in the Music Player's database but not
the ID3
tags. So when we compare the CLF tags with the Music Player metadata, we won't
always get a match. Hopefully these cases will be rare, and at least it's no
worse
than we were before the fix.
Now, there's a chance that there may be two songs by the same artist but in
different albums, and we may get a mismatch. But the artist and title
comparisons
are case sensitive, and I've found in testing that often the little words
("the",
"in", "and", "of" etc) may be capitalised for some albums and not for the
others, so
that reduces the chance for a mismatch. And in testing there weren't many
duplicate
tracks by the same artist to begin with.
Anyway, even if we do have a mismatch, at least that artist does actually have
that
song, and you do have both on your phone, so it's not the end of the world.
Original comment by hugovk@gmail.com
on 12 Nov 2008 at 11:28
MobblerClfObserver.h: No such file or
directory[/Symbian/Carbide/workspace/mobbler-
hugovk/src/mobblermusiclistener.cpp:25]
Original comment by spassov
on 12 Nov 2008 at 11:04
Oh yes, it'd help if I added the new files! Now added in r102.
Original comment by hugovk@gmail.com
on 13 Nov 2008 at 7:31
thanks, now it compiles and album name is submitted correctly.
Original comment by spassov
on 13 Nov 2008 at 8:14
do you have any idea why mobbler send now playing notification twice for every
track
?
Original comment by spassov
on 13 Nov 2008 at 1:21
Back to open status, the CLF stuff needs to be put in an Ecom plugin so 3.0
phones
that don't have the required libs can still run.
Original comment by hugovk@gmail.com
on 6 Jan 2009 at 12:37
CLF stuff put in an ECom plugin in r356 of hugovk branch. Ready for code review.
Original comment by hugovk@gmail.com
on 20 Jan 2009 at 4:10
Oh, and the new files in r357.
Original comment by hugovk@gmail.com
on 20 Jan 2009 at 4:48
Oh, and another new file in r362.
Original comment by hugovk@gmail.com
on 23 Jan 2009 at 9:18
Merged to the trunk in r375.
Original comment by hugovk@gmail.com
on 3 Feb 2009 at 1:53
Original comment by hugovk@gmail.com
on 11 Mar 2009 at 3:12
Original issue reported on code.google.com by
spassov
on 21 Oct 2008 at 9:32