Added a cache system - might need a bit of tweaking.
Removed support for targets without a RTC (since this has been removed from the spec - it might be added later)
S vs L is still guesswork - need to add a function to the playback engine to return the mp3entry.elapsed value for the last track - at the moment this /could/ be added to Archos Recorders (if the code isn't too big?) - so would need to add this to both HW and SW engines

I didn't see the other patch - I tried doing something similar to that before (writing a custom log format, and with a C++ CLI app to upload the results) but the current scrobbler spam system tended to eat the results when a desktop PC was also being used.

From what I understand - the Portable Player spec is going to relax some of the existing protocol 1.1 rules - timestamps for one, also the player doesn't need to detect if the track has been seeked, unlike the desktop player plugins.
I think it's going to be at least a month before the support is added to the new AS beta client.

One thing I believe is handled wrong in the patch is the issue of missing Track numbers. At the moment this is replaced by another \\t, resulting in \\t\\t\\t with separators. I understand the spec like this: Track number is set to blank, resulting to \\t\\t with separators. This would make the parsing easier and makes imho more sense.

Here comes the Perl script: rockscrobbler.pl and the modified Audio::Scrobbler Cpan module. for username settings have a look at the provided .bat fle which will hopefully also work in windows.
I also build the latest misticriver experimental build for the H300 with this patch - get it in my gallery there.

The script should already address the issue with the \\t\\t\\t by replacing them with \\t\\t :)

A cross-link to the other audioscrobbler patch online here:
http://www.rockbox.org/tracker/task/2564
This one does everything in the playback.c, but is imho a bit shorter. This is kindof important for combining the patch with others as long we have a feature freeze (we do have one,eh?). I guess its due to the rtc detection done in your code.

Probably the problem with the missing first song is avoided by using swap_codec to call the logging function instead of audio_set_track_changed_event - maybe thats an alternative for your code as well? I'm trying to find a decent editor for linux now, maybe I'll write some own modifications afterwards. Anyways, having two teams develop the same stuff is probably a bit too much...

The non-RTC targets are a bit of a problem - the Audioscrobbler Portable spec requires timestamps (If your device does not have a clock, you will not be able to supply a timestamp and cannot use this service), as does the current v1.1 protocol. There was some talk that support for devices without a RTC could be added later on to the spec, but nothing definite. What does your workaround do?

Most of this patch is in the scrobbler.c and .h files - these will patch cleanly since they're new files being added to the source. It's mostly the menu and lang strings that are likely to date the fastest and cause rejections - I don't think there is a lot that can be done about those (since the logging needs to be optional). It's easy enough to manually fix those anyway.

I've just checked out the source from before the playback changes - this doesn't have any problems with the audio_set_track_changed_event(), so I've created a new bug report (FS#5495).

So if we can't measure the playtimes why not fake them in the client?
like only storing the played songs including duration, the compute the playtime "backwards" from the current time. This way all can be submitted. Its cheating and messing up statistics, but I don't really care if there is no other choice.

Some comments about the current patch:
- The "ipod comment" has to be replaced with a proper one (just search for ipod)
- The change in the Makefile is not clear to me, what does it do?
- why is prev_track_elapsed set in playback.c _and_ mpeg.c?

-Ipod comment - oops - I was copy/pasting from an different patch I wrote - I'll correct that.
-The Makefile change allows me to use the ARCHOS variable set by the configure script - this is a text string describing the target, ie ipodvideo/h120/recorderv2 etc. After speaking to Russ and RJ from Audioscrobbler I added the third header line to the spec - this will allow them to pin down any problem clients.
-This is down to HWCODEC vs SWCODEC in Rockbox - Archos devices use a hardware chip to decode MP3s, the rest use the SWCODEC engine in playback.c Both share audio.h The code in mpeg.c is AFAIK untested.

I'll (hopefully) post a version of the patch for non-RTC targets tomorrow.

Thanks for the explanation, I'm not familiar with the rockbox code
You are in contact with Russ&RJ? I didn't get a response so far, thats why my testing script still uses the tst id. I'm just implementing the handling of the header so any mobile player generating these logs can use the script. How is the Client ID and # going to be submitted? So far its not in the protocol, probably another line of handshaking...

Another small difference between your implementation and the protocol:
[quote log definition]
- unix timestamp when song started playing
[/quote]
as far as I understood the code the timestamp is saved after the track was played... I don't think this is really important though :)

Attached is a version that includes support for non-RTC targets. Instead of .scrobbler.log it writes to .scrobbler-timeless.log - this file will need post-processing before it can be submitted to last.fm - although it writes data for the timestamp this is not valid information.

The non-RTC code (and also the HWCODEC platforms) is untested - feedback is welcome :)

Just as a heads up the last.fm submission system is going down for a 3 day upgrade.

I did some reworking of the Perl script to have everything in one file. The growing amount of configuration options forced me to switch to typical unix style arguments like -v -D etc. But now the order is not important any more. A directory can be provided which will be searched for both .scrobbler.log and .scrobbler-timeless.log
BUT: at the moment you must tell the script to ignore the timestamps from the log by appending the -n option.

Sounds confusing? It hopefully isn't. For a full listing of options just call the script without any option. I gave two examples which should cover it all. And once the .bat is set up you never have to look at it again, until the next update :)

BTW: Sticked to Hajobens changes, but perlified in some way :)

Does writing a wrong user password give an error for you? It should be catched in Scrobbler.pm, but isn't displayed for some strange reason

This is most likely still buggy code - but I just submitted my daily dose of songs on the first try :)

cross link my thread at misticriver for the H100 nonRTC rockboxes:
http://www.misticriver.net/showthread.php?p=457370#post457370
There is a build for H100 and the updated script zip in my gallery over at that site. Sorry for using this lazy way, but I'm pretty busy right now. The above linked script is working fine for me here, need a changed .bat though (but you'll figure out ;)

@piha:
nice work, but honestly I would be too scared about my precious last.fm password :)
But I guess not everyone cares as much as I do, so thanks for writing the webapp.

UTC Playtime is correct.
and last.fm shows that first song played at the time of submission and doesn't accepts other tracks .. here is part of rss with last played tracks:
<item>
<title>Diary of Dreams - The Scream</title>
<link>http://www.last.fm/music/Diary+of+Dreams/_/The+Scream</link>
<pubDate>Fri, 23 Jun 2006 11:16:19 +0000</pubDate>
<guid>http://www.last.fm/user/theli_ua/#1151061379</guid>
<description>http://www.last.fm/music/Diary+of+Dreams</description>
</item>
this is the only item here (rss keeps 10 recent/last played tracks)

I see that the UTC offset is manually set to +2, is it written in the log like that by the rockbox patch? I actually never tested that because on my device no info about the timezone is in the logs. I'm off for the weekend now, but I'll look into that on monday. It looks like the right UTC playtime was submitted to me...

Could you please paste the header in the .scrobbler.log here or mail it to me, address is in the console output :)

Linus embedded the new USB-OTG-off.patch (X5) to the CVS. That's a most wanted feature for all X5-Rockbox fans (like me). Thanks! :)
I tried to compile a new build with the scrobbler.patch. But unfortunatly I'm not a skilled programmer, so I failed...
*cough* Could someone of you wonderful guys make a sync to the newest build? Please?
(Shame on me)

I don't know... it needs a dev to look at the code, and then I guess someone needs to make a decision to include it if they think it's worth the increse in code size. I've asked a few times on IRC but haven't had any response - maybe I just don't make enough noise?

Removed the playtime guess used by scrobbler_shutdown and renamed a function and variable.

After talking to Linus on IRC:
-renamed the menu entry from "Audioscrobbler Log" to "Last.fm Log"
-moved mktime() to timefuncs.c - this is currently defined for all targets, I don't know if it should be wrapped up in a "#ifdef CONFIG_RTC" or not?

I'm having some problems with this patch and the current CVS on an iriver H140. I can't get audioscrobbler enabled. I tried a CVS HEAD with just scrobbler.patch enabled. I reset my settings, enabled audioscrobbler, and rebooted. But the scrobbler file is still not created.

I did some debugging and discovered that while global_settings.audioscrobbler is set to true when the settings are loaded, it is false by the time scrobbler_init() is called. I have no idea why this is happening. I was able to work around it with the attached patch, which sets a bool in scrobbler.c from settings_apply(). So, global_settings.audioscrobbler is somehow getting cleared between settings_apply() and scrobbler_init().

Excuse me, I don't have iPOD or others expensive players, but soon I'll have. But I have one question - does last.fm patch work well on iPod and others players? Are there any bugz or that? And what about Russian (Germans, etc) tags? Are they submited properly? Thanks!

@Alex:
I have a X5 powered with Rockbox and the scrobbler patch. Well, this patch does work on the X5 perfectly. At the moment there is just one fault: The first track of a selection of tracks doesn't get logged. But this doesn't seem to be a problem of the patch. This seems to be a (small) bug of the Rockbox firmware.
I don't have any russian tagged tracks, but I have german (Kraftwerk) and icelandic (Sigur Rós). They are logged, submitted and scrobbled correctly! ;)

I'm GMT-5 and changed the log to reflect this, however, when I start listening to music around 6am when I'm getting ready for school, then continuing to listen to music until 4 - 4:30pm when I get home and submit, the hour is off by a few hours, but only during this time.

If I keep my DAP plugged in and playing during the night, the track times will be correct when I submit the log in the morning.

Hope it's ok to post here,I just made a little gui app that runs in the systray on XP(but requires .NET 2.0) for uploading .scrobbler.log file to last.fm from this patch.
this first test version is available at http://www.yourfilehost.com/media.php?cat=other&file=LogScrobbler.zip as well
I still have to make it clear the old file out, but it seems to work good. I will be making it detect the MP3 player when it is plugged in and ask if you want to upload your .scrobbler.log to last.fm

right now you have to add your username/password/and browse for the .scrobbler.log file and click Go!

I applied the latest patch to the latest cvs and it seems to work only if I skip tracks it will create a line with an "S" but if I listen to a whole track it does not always write a line in the file :-( well it did this with the last build/patch for me as well.

I can think of a couple of things that might stop tracks being logged:

-The last track isn't logged. (It should be caught if it's resumed...)
-If auto-resume is enabled, the first resumed song won't be logged. (I think it's a bug in playback.c - FS#5495)
-If the track doesn't have enough tag information - it must have at least artist and track name.
-The log info is held in memory, currently upto 32 tracks, before being written to disc. It will write this cache earlier on non-flash devices IF the drive is spinning while the track changes - so if you're doing a lot of skipping you're probably flush the cache. If you don't shutdown cleanly, or your player crashes/locks up, you'll loose whatever hasn't been written.
-If the length of the log line produced is more than 512 characters (ie very long artist, track name etc).

I tested it for several hours yesterday (a good mix of L and S) and didn't have any problems.

What kind of player do you have? Can you go through a playlist of tracks (with known good meta info), note down what you skip and see how this compares to the log? The patch does use logf in places, so it might be worth trying a logf enabled build.

Here is what I thought was happening to me.
When I delete the .scrobbler.log via USB connection, then restart the player it creates a new .scrobbler.log file, but does not seem to populate the file unless I reset the device one more time.
That lead me to think that when the file is created a pointer is left open on the file so it cannot be written to by another thread, but when I look at the latest patch(which is the one I applied -- Monday, 02 October 2006, 11:26PM --) it looks like where the file is created, it is created with O_RDWR and is also closed at the end of the _init

I am going to run through a few more scenarios with a single known good playlist(good tags, that have shown up in the .scrobbler.log before ok),I'll post what I find.

quick question, is the Last.FM client supposed to grab the .scrobbler.log and submit it automatically?
as stated in the audioscrobbler.com wiki page:
"The audioscrobbler software will check for .scrobbler.log in the root of any connected usb devices. It will parse the file and submit the songs to the audioscrobbler server. The audioscrobbler software will then delete the file from the device."

No - at the moment the official client doesn't deal with the log files. As far as I know there aren't any other DAPs that produce this log (yet?). I don't think that the client side part will be written unless there is a solution in place - it's a bit catch 22.
At the moment the only method is via various forms of manual submission (perl script, web site and windows app).

Here is the latest version of LogScrobbler that I made for windows XP, a little app to sync your logs
http://www.yourfilehost.com/media.php?cat=other&file=LogScrobbler_0.3.zip
Hope it helps some that don't want to enter their data into a .ru site, or know how to get the perl version working, the perl version works great from my experience but I just didn't want to set it up on each PC I might sync from, so I thought I needed an app that just ran in systray.

I have to admit I had an issue after I first put that last patch on, and it really seemed to be acting like the description I had posted previously, but now I cannot get it to break now, it writes a new file every time as expected and logs everything as expected as well, so I am not quite sure what the deal was, (it may have had something to do with me being impatient and listening to one song and stopping, it may not have logged because of a couple reasons you posted before) I apologize if you spent any time trying to debug an issue like I previously described. Things are working great, I never even got around to installing the logf version that I compiled because I was no longer able to recreate the issue. (gonna try the latest build tonight) Thanks for this kick ass patch, I have wanted to scrobble my H10 for over a year, and just found this a week or so ago.

this new version is kinda cool, say you let your girlfriend borrows your portable device, and she listens to Britney Spears all day but you didn't sync your log before hand. This version will let you choose which songs it will sync, cause it would suck if all of your friends visited your last.fm and saw what you really listen to ;-)

im assuming S stands for skipped because when i run that perl script to submit the tracks it skips right over the songs with the S

also is last.fm ever going to allow submissions out of order? because its lame how it doesnt take tracks that were played before your last entry... i personally dont bring my player home every day after work to submit the tracks played