Rockbox

Thanks to lostlogic - better mp3entry handling

   scrobbler.patch (6.1 KiB)

The ‘S’ vs. ‘L’ detection seems a bit hokey at this point. Also, can this be done as a TSR plugin, and write to disk less often to prevent extra spinups?

I gave this a try and it seems to work ok. The header needs hashes and timezone info to meet spec, but I know it’s a work-in-progress.

there is similar work here
http://www.rockbox.org/tracker/task/2564

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.

   scrobbler.patch (8.9 KiB)

yeah… you cannot upload tracks with timestamp less than your previous tracks :(
but i doubt this will be changed … but will hope to :)

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.

Proper S vs L detection.
Untested on HWCODEC platforms - it compiles cleanly, but is too big for flash - no idea if it actually works on Archos.
Working here on SWCODEC (5g)

   scrobbler.patch (11.6 KiB)

Sync to current CVS:

   scrobbler.patch (11.6 KiB)

Made some tests on X5 (hardware):

First of all: It works like a charm (with latest build)! :)

I listend to the following tracks:
Boards Of Canada - Geogaddi - Track 1 - 0:59 - listened to until end
Boards Of Canada - Geogaddi - Track 2 - 5:21 - listened to until end
Boards Of Canada - Geogaddi - Track 3 - 0:37 - listened to until end
Boards Of Canada - Geogaddi - Track 4 - 3:35 - skipped at 1:20
Boards Of Canada - Geogaddi - Track 5 - 1:15 - skipped at 1:01
Boards Of Canada - Geogaddi - Track 6 - 6:12 - listened to until end
Boards Of Canada - Geogaddi - Track 7 - 1:22 - shutoff at 1:02

The logfile:
#AUDIOSCROBBLER/1.0
#TZ/UNKNOWN
#CLIENT/Rockbox x5 1.0
Biosphere Substrata Poa Alpina 2 250 S 1147537029
Boards Of Canada Geogaddi Music Is Math 2 321 L 1147538190
Boards Of Canada Geogaddi Beware The Friendly Stranger 3 37 L 1147538511
Boards Of Canada Geogaddi Gyroscope 4 215 S 1147538549
Boards Of Canada Geogaddi Dandelion 75 L 1147538632
Boards Of Canada Geogaddi Sunshine Recorder 6 372 L 1147538694
Boards Of Canada Geogaddi In The Annexe 7 82 L 1147539067

Before I’ve listened to Boards Of Canada I’ve listened to the first two tracks of Biosphere/Substrata.

So everything went fine except the first tracks were not logged.

Nevertheless: Great work! Can’t wait for the next revision of the Audioscrobbler software to test the logfile.

Yup, I’ve run into this issue also - did you stop playback between the two albums, or did it follow on in a playlist?

I think it’s an problem with the audio_set_track_changed_event() - but I need to put some test code together to confirm that.

I stopped playback after the first album and switched off the player.

I toggled playback of both albums by selecting the first track in the file system (I use file browsing instead of tag database).

Okay, that matches up with what I’ve experienced. From testing here it looks like the audio_set_track_changed_event() isn’t called for the first track in a playlist.

Add a Playback menu setting to enable logging (will need a reboot to take effect)
Few other minor clean-ups

   scrobbler.patch (17 KiB)

First of all, thanks for the patch. I’m using it since 3 days and love to be finally able to submit my songs from the H300.

Because I couldn’t wait for the official software I wrote a perl script to submit the logs automatically, the misticriver thread is this:
http://www.misticriver.net/showthread.php?t=33245&page=5

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.

Yes, looks like I misread the spec - attached is an updated version that handles blank fields properly.

Great work on the uploader - I was looking to do this myself. Any chance you could post it here for those not signed-up to Misticriver?

   scrobbler.patch (16.9 KiB)

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 :)

   rockscrobbler.zip (5.1 KiB)

Fantastic work, guys. How’s the support for non-RTC targets going? I’ve got a very dirty workaround for the time being, looking forward to a better way round it though.

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…

Link to the latest experimental H300 build, now open for everyone:
http://www.misticriver.net/photos/displayimage.php?album=lastup&cat=22288&pos=0

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?

Yup, that is evilnicks dirty workaround :)

-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.

   scrobbler.patch (17.4 KiB)

Just changed a bit the perl script that noleti did, in order to make it work with non-RTC.
Never did any perl before, but this seems to work, so I hope it can be helpful !

   rockscrobbler-noRTC.pl (2.7 KiB)

I couldn’t get the timestamp to work (WinXP) using the rockscrobble-noRTC perl script - still resorting to using formulas within Excel!

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 :)

   rockscrobbler.pl (4.5 KiB)

i have problems with perl at my office PC, so i made simple web service to upload .scrobbler.log to last.fm. You can use it too. Here it is http://rockscrob.hostvit.ru/cgi-bin/rock2.pl

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.

hm.. last.fm is accepting only first submitted by scrobbler.pl song … for example
log from scrobbler.pl:
– Log by Rockbox ipodmini2g ver. 1.0 – – taking provided UTC offset +2 –

L: Artist: Diary Of Dreams| Album: PaniK Manifesto EP| Track: The Scream| Lenght.: 265|UTC Playtime: Fri Jun 23 07:35:35 2006|local Playtime: Fri Jun 23 09:35:35 2006|faked playtimeFri Jun 23 10:50:02 2006| submitted Fri Jun 23 07:35:35 2006
L: Artist: Diary Of Dreams| Album: PaniK Manifesto EP| Track: Monsters and Demons| Lenght.: 284|UTC Playtime: Fri Jun 23 07:40:01 2006|local Playtime: Fri Jun 23 09:40:01 2006|faked playtimeFri Jun 23 10:54:46 2006| submitted Fri Jun 23 07:40:01 2006
L: Artist: Diary of Dreams| Album: One of 18 Angels| Track: Rumours of angels| Lenght.: 500|UTC Playtime: Fri Jun 23 07:44:45 2006|local Playtime: Fri Jun 23 09:44:45 2006|faked playtimeFri Jun 23 11:03:06 2006| submitted Fri Jun 23 07:44:45 2006
L: Artist: Diary of Dreams| Album: One of 18 Angels| Track: Butterfly:dance!| Lenght.: 408|UTC Playtime: Fri Jun 23 07:53:05 2006|local Playtime: Fri Jun 23 09:53:05 2006|faked playtimeFri Jun 23 11:09:54 2006| submitted Fri Jun 23 07:53:05 2006
L: Artist: Diary of Dreams| Album: One of 18 Angels| Track: Mankind| Lenght.: 380|UTC Playtime: Fri Jun 23 07:59:54 2006|local Playtime: Fri Jun 23 09:59:54 2006|faked playtimeFri Jun 23 11:16:14 2006| submitted Fri Jun 23 07:59:54 2006

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)

oh… no.. it somehow thinks that track is played in future o_O
<pubDate>Fri, 23 Jun 2006 08:31:47 +0000</pubDate>

    <lastBuildDate>Fri, 23 Jun 2006 08:31:47 +0000</lastBuildDate>

<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>

this is not only in rss it shows that everywhere

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 :)

Check for empty strings properly - this should fix the problem with corrupt entries for songs with blank artist, track or album info.

Let me know if these still happen.

   scrobbler.patch (17.6 KiB)

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)

Done. I haven’t had a chance to test this on a real device, so let me know if there are any problems.

   scrobbler.patch (17.7 KiB)

Many Thanks! :D
The last versions did work an a X5 (except the first-track-problem, see above).

Always use the full amount of cache before writing on devices with flash memory

   scrobbler.patch (18 KiB)

Use buffer_alloc() and increase cache to hold upto 32 entries (value can now be increased further if needed).

   scrobbler.patch (18 KiB)

So what is the status? Is this going to be included in Rockbox any time soon? What is keeping it from being included? Anything I could do to help?

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.

   scrobbler.patch (17.2 KiB)

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?

Also removed some debug code.

   scrobbler.patch (17.5 KiB)

Minor Update to work with latest build

   scrobbler.patch (17.9 KiB)

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().

I’d love to hear if anyone else is having this problem.

   settings.patch (1.6 KiB)

I did the same thing yesterday

And have exactly the same problem
My workaround is to move the bool audioscrobbler variable
up in the “user_settings” struct. Then the value is correct

I suspect either some memory overwrite or an toolchain
problem because it depends also where the scrobbler.c file is
located in the SOURCES file.

It also dont depend on the scrobbler patch.
It can be reproduced with other settings to

I will try to create a testcase to reproduce it
and if possible file a bug report for it

I updated scrobbler.patch to apply to the latest CVS. I verified that the patch builds for all targets. I had to disable last.fm support for HWCODEC targets to make that work.

I also updated the settings.patch mentioned previously. (Everything builds with that patch applied, too.)

   scrobbler.patch (15.4 KiB)
   settings.patch (1.5 KiB)

The issue with the settings has been fixed in CVS. settings.patch is no longer required.

Hmm. In my build I have now only the scrobbler patch and it doesn’t log anything (although activated). You are sure that this is fixed?

Bye Norbert

Ok, forget the last comment. It is working, although I don’t understand why it didn’t in the first place, probably because I had a playlist in shuffle mode?
Anyway, now I see the log file.
Thanks.

It shouldn’t have anything to do with the playlist mode. The file is created during startup if logging is enabled. So, you have to restart the DAP after enabling logging.

Ok, maybe I didn’t turn off and back on the unit. I didn’t know this. Thanks for the explanation.

Ciao
Norb

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!

Sorry for my English,
Alexander

@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’ve got Rockbox running on my h340 and patched my build last night, updated my DAP, and turns on scrobbling.

Nothing was logged.

Didn’t patch the settings file, so I just did that, and I’m rebuilding right now.

The separate settings patch should no longer be required. However, you do need to reboot your DAP after enabling scrobbling.

A REALLY stuoid question. I’m not a newbie to Rockbox, but I’m not a developer at all - so how do I apply this C++-looking patch on my Rockbox? Is there any FAQ on that? I didn’t find.

Thanx.

http://www.rockbox.org/twiki/bin/view/Main/SimpleGuideToCompiling

You did a bad job looking.

;( My bad

Going to point out that times are sometimes off.

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.

Updated for the latest CVS.

   scrobbler.patch (15.4 KiB)

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’ll release a much better version soon with source.

   LogScrobbler.zip (21.7 KiB)

Oops forgot to remove the debug popups
here is is again

   LogScrobbler.zip (22.1 KiB)

Sync to CVS.

   scrobbler.patch (17.8 KiB)

Fix compile error for Archos sims.

   scrobbler.patch (18 KiB)

Looks good. A few comments:

1) You should perhaps declare some globals and functions static, unless they need to be exported.

2) I think you should open the file with O_WRONLY and not O_RDWR in write_cache().

This looks like CVS material to me.

Thanks for the feedback Linus. Patch has been changed as suggested, and re-tested (build-wise for a range of targets and physically on a 5g).

   scrobbler.patch (18.1 KiB)

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.

I am using an iRiver H10 20G,

The last few times it seems to be working OK, weird

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.

How do I build it with logf? is that the (D)ev build

At boot the log file is created (if it doesn’t exist - in scrobbler_init()), and immediatly closed. It is then opened and closed each time the cache is written.

Yup, logf is a dev build option. When it’s running you’ll have 2 extra options under the Info→Debug menu - you can either view the log onscreen, or write it to a file.

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.”

or is the only way to submit tracks via a manual submission method?

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).

I’d like to set up a log submission service on rockbox.org.

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.

Cheers
Tim G.

   LogScrobbler_0.3.zip (24.1 KiB)

Sync to CVS.
Tim - how did you get on with the testing?

   scrobbler.patch (17.9 KiB)

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.

Thanks again,

Tim G

No problem - glad it’s behaving as it should now.

I just released LogScrobbler 0.5 for those that use it

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

http://www.yourfilehost.com/media.php?cat=other&file=LogScrobbler_0.5.zip

This version also uses UTC time for posting files(since it was supposed to to begin with), and maybe a few other fixes

   LogScrobbler-0.5.zip (25.2 KiB)

Here is LogScrobbler 0.6 «Requires .NET 2.0 » (http://logscrobbler.googlecode.com/svn/trunk/%20logscrobbler/bin/Release/LogScrobbler-0.6.zip)

• I think this fixes some issue with safely removing usb device.
• added setting for exit after processing complete
• added progress bar.

Tim G.

   LogScrobbler-0.6.zip (26.7 KiB)

i just tried the latest patch with the latest cvs and it seemed to be marking tracks i listened to completely with S

i have the iriver h140
rockbox-daily-20061009

#AUDIOSCROBBLER/1.0
#TZ/UNKNOWN
#CLIENT/Rockbox h120 1.0 Timeless
Crazy Town The Gift Of Game Toxic 2 168 S 0
Linkin Park Hybrid Theory A Place For My Head 9 184 S 0
Finch What It Is To Burn Perfection Through Silence 5 189 S 0
Nothingface Skeletons Here Come The Butchers 8 178 L 0

the last track i stopped near the end of the song

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

actually i think this was my error.. so ignore what i said for now… i’ll repost if it truely wasnt my error

Hmm, does anyone else here got a problem with the current CVS build ?

LogScrobbler 0.7 here
http://logscrobbler.googlecode.com/svn/trunk/%20logscrobbler/bin/Release/LogScrobbler-Latest.zip Added Shift Time(In case you listen to some tracks on your PC before syncing your log)
Show last posts to Last.FM
Bug Fixes

   LogScrobbler-Latest.zip (29.4 KiB)

There was an update to playback.c yesterday, which requires a one line change to the patch. I haven’t yet had a chance to test this on-target.

   scrobbler.patch (17.7 KiB)

New version, synched to CVS. This one flushes the log to disk when entering USB mode.

   scrobbler.patch (19 KiB)

Move the log file creation from init to write_cache.

Haven’t yet tested on target.

   scrobbler.patch (18.8 KiB)