Notice: A non well formed numeric value encountered in /sites/ on line 96 Notice: A non well formed numeric value encountered in /sites/ on line 96 Notice: A non well formed numeric value encountered in /sites/ on line 96 Deprecated: Function create_function() is deprecated in /sites/ on line 104 Deprecated: The each() function is deprecated. This message will be suppressed on further calls in /sites/ on line 845 Deprecated: Function create_function() is deprecated in /sites/ on line 111 FS#5166 : Audioscrobbler / log



FS#5166 - Audioscrobbler / log

Attached to Project: Rockbox
Opened by Robert Keevil (obo) - Monday, 17 April 2006, 20:10 GMT
Task Type Patches
Category Music playback
Status Closed
Assigned To No-one
Operating System All players
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


Patch to implement spec at

check for valid metadata before adding
check on platforms without RTC
This task depends upon

Closed by  Linus Nielsen Feltzing (linusnielsen)
Thursday, 19 October 2006, 09:43 GMT
Reason for closing:  Accepted
Additional comments about closing:  Thanks, Robert!
Comment by Robert Keevil (obo) - Tuesday, 18 April 2006, 00:02 GMT
Thanks to lostlogic - better mp3entry handling
Comment by Brandon Low (lostlogic) - Tuesday, 18 April 2006, 16:13 GMT
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?
Comment by James Lee (MrStaticVoid) - Thursday, 20 April 2006, 06:25 GMT
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.
Comment by Anton Romanov (theli) - Thursday, 20 April 2006, 13:09 GMT Comment by Robert Keevil (obo) - Monday, 24 April 2006, 22:48 GMT
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.
Comment by Anton Romanov (theli) - Tuesday, 25 April 2006, 07:32 GMT
yeah... you cannot upload tracks with timestamp less than your previous tracks :(
but i doubt this will be changed ... but will hope to :)
Comment by Robert Keevil (obo) - Tuesday, 25 April 2006, 09:48 GMT
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.
Comment by Robert Keevil (obo) - Tuesday, 25 April 2006, 22:41 GMT
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)
Comment by James Lee (MrStaticVoid) - Saturday, 13 May 2006, 00:45 GMT
Sync to current CVS:
Comment by Marcus Dermann (sunjammer) - Saturday, 13 May 2006, 15:17 GMT
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:
#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.
Comment by Robert Keevil (obo) - Saturday, 13 May 2006, 16:17 GMT
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.
Comment by Marcus Dermann (sunjammer) - Saturday, 13 May 2006, 20:21 GMT
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).
Comment by Robert Keevil (obo) - Saturday, 13 May 2006, 23:45 GMT
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.
Comment by Robert Keevil (obo) - Tuesday, 23 May 2006, 23:07 GMT
Add a Playback menu setting to enable logging (will need a reboot to take effect)
Few other minor clean-ups
Comment by Nils Ole Tippenhauer (noleti) - Saturday, 03 June 2006, 08:41 GMT
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:

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.
Comment by Robert Keevil (obo) - Saturday, 03 June 2006, 10:51 GMT
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?
Comment by Nils Ole Tippenhauer (noleti) - Saturday, 03 June 2006, 13:31 GMT
Here comes the Perl script: 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 :)
Comment by Nick Sant (evilnick) - Sunday, 04 June 2006, 04:07 GMT
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.
Comment by Nils Ole Tippenhauer (noleti) - Sunday, 04 June 2006, 15:16 GMT
A cross-link to the other audioscrobbler patch online here:
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:
Comment by Robert Keevil (obo) - Sunday, 04 June 2006, 17:44 GMT
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 ).
Comment by Nils Ole Tippenhauer (noleti) - Sunday, 04 June 2006, 21:19 GMT
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?
Comment by Robert Keevil (obo) - Sunday, 04 June 2006, 23:06 GMT
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.
Comment by Nils Ole Tippenhauer (noleti) - Monday, 05 June 2006, 10:04 GMT
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
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 :)
Comment by Robert Keevil (obo) - Monday, 05 June 2006, 22:56 GMT
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 - 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 submission system is going down for a 3 day upgrade.
Comment by Hadrien (Hajoben) - Tuesday, 06 June 2006, 01:12 GMT
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 !
Comment by Nick Sant (evilnick) - Tuesday, 06 June 2006, 11:04 GMT
I couldn't get the timestamp to work (WinXP) using the rockscrobble-noRTC perl script - still resorting to using formulas within Excel!
Comment by Nils Ole Tippenhauer (noleti) - Wednesday, 07 June 2006, 00:42 GMT
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, 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 :)
Comment by piha (piha) - Wednesday, 07 June 2006, 18:33 GMT
i have problems with perl at my office PC, so i made simple web service to upload .scrobbler.log to You can use it too. Here it is
Comment by Nils Ole Tippenhauer (noleti) - Thursday, 08 June 2006, 20:27 GMT
cross link my thread at misticriver for the H100 nonRTC rockboxes:
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 ;)

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

Comment by Anton Romanov (theli) - Friday, 23 June 2006, 08:28 GMT
hm.. is accepting only first submitted by song ...
for example
log from
-- 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 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:
<title>Diary of Dreams - The Scream</title>
<pubDate>Fri, 23 Jun 2006 11:16:19 +0000</pubDate>
this is the only item here (rss keeps 10 recent/last played tracks)
Comment by Anton Romanov (theli) - Friday, 23 June 2006, 08:35 GMT
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>
<pubDate>Fri, 23 Jun 2006 11:16:19 +0000</pubDate>

this is not only in rss it shows that everywhere
Comment by Nils Ole Tippenhauer (noleti) - Friday, 23 June 2006, 14:53 GMT
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 :)
Comment by Robert Keevil (obo) - Wednesday, 28 June 2006, 21:38 GMT
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.
Comment by Marcus Dermann (sunjammer) - Friday, 14 July 2006, 13:00 GMT
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)
Comment by Robert Keevil (obo) - Friday, 14 July 2006, 13:14 GMT
Done. I haven't had a chance to test this on a real device, so let me know if there are any problems.
Comment by Marcus Dermann (sunjammer) - Friday, 14 July 2006, 17:01 GMT
Many Thanks! :D
The last versions did work an a X5 (except the first-track-problem, see above).
Comment by Robert Keevil (obo) - Friday, 21 July 2006, 12:42 GMT
Always use the full amount of cache before writing on devices with flash memory
Comment by Robert Keevil (obo) - Sunday, 23 July 2006, 18:56 GMT
Use buffer_alloc() and increase cache to hold upto 32 entries (value can now be increased further if needed).
Comment by Nils Ole Tippenhauer (noleti) - Saturday, 29 July 2006, 20:04 GMT
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?
Comment by Robert Keevil (obo) - Sunday, 30 July 2006, 15:30 GMT
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.
Comment by Robert Keevil (obo) - Sunday, 30 July 2006, 21:06 GMT
After talking to Linus on IRC:
-renamed the menu entry from "Audioscrobbler Log" to " 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.
Comment by Keith Barnett (captain_cornflake) - Monday, 14 August 2006, 19:34 GMT
Minor Update to work with latest build
Comment by David Rothenberger (drothenberger) - Tuesday, 15 August 2006, 04:37 GMT
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.
Comment by Max Weninger (maxwen) - Tuesday, 15 August 2006, 09:43 GMT
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
Comment by Max Weninger (maxwen) - Tuesday, 15 August 2006, 10:09 GMT
I will try to create a testcase to reproduce it
and if possible file a bug report for it
Comment by David Rothenberger (drothenberger) - Friday, 01 September 2006, 20:08 GMT
I updated scrobbler.patch to apply to the latest CVS. I verified that the patch builds for all targets. I had to disable support for HWCODEC targets to make that work.

I also updated the settings.patch mentioned previously. (Everything builds with that patch applied, too.)
Comment by David Rothenberger (drothenberger) - Saturday, 02 September 2006, 20:07 GMT
The issue with the settings has been fixed in CVS. settings.patch is no longer required.
Comment by Norbert Preining (norbusan) - Monday, 04 September 2006, 16:05 GMT
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
Comment by Norbert Preining (norbusan) - Monday, 04 September 2006, 16:37 GMT
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.
Comment by David Rothenberger (drothenberger) - Tuesday, 05 September 2006, 02:41 GMT
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.
Comment by Norbert Preining (norbusan) - Tuesday, 05 September 2006, 09:46 GMT
Ok, maybe I didn't turn off and back on the unit. I didn't know this. Thanks for the explanation.

Comment by Alex (SonOfTheNorth) - Wednesday, 06 September 2006, 15:18 GMT
Excuse me, I don't have iPOD or others expensive players, but soon I'll have. But I have one question - does 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,
Comment by Marcus Dermann (sunjammer) - Sunday, 10 September 2006, 15:03 GMT
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! ;)
Comment by Chris Olin (Landus) - Monday, 18 September 2006, 08:50 GMT
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.
Comment by David Rothenberger (drothenberger) - Monday, 18 September 2006, 15:33 GMT
The separate settings patch should no longer be required. However, you do need to reboot your DAP after enabling scrobbling.
Comment by Max (GolerGkA) - Tuesday, 19 September 2006, 09:50 GMT
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.

Comment by Chris Olin (Landus) - Tuesday, 19 September 2006, 10:23 GMT Comment by Max (GolerGkA) - Tuesday, 19 September 2006, 18:33 GMT
;( My bad
Comment by Chris Olin (Landus) - Saturday, 23 September 2006, 18:39 GMT
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.
Comment by David Rothenberger (drothenberger) - Wednesday, 27 September 2006, 18:26 GMT
Updated for the latest CVS.
Comment by Tim G (kernelsandirs) - Friday, 29 September 2006, 23:49 GMT
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 from this patch.
this first test version is available at 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

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.
Comment by Tim G (kernelsandirs) - Saturday, 30 September 2006, 03:39 GMT
Oops forgot to remove the debug popups
here is is again
Comment by Robert Keevil (obo) - Monday, 02 October 2006, 10:02 GMT
Sync to CVS.
Comment by Robert Keevil (obo) - Monday, 02 October 2006, 11:12 GMT
Fix compile error for Archos sims.
Comment by Linus Nielsen Feltzing (linusnielsen) - Monday, 02 October 2006, 13:47 GMT
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.
Comment by Robert Keevil (obo) - Monday, 02 October 2006, 21:26 GMT
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).
Comment by Tim G (kernelsandirs) - Tuesday, 03 October 2006, 16:52 GMT
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.
Comment by Robert Keevil (obo) - Tuesday, 03 October 2006, 17:17 GMT
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.
Comment by Tim G (kernelsandirs) - Tuesday, 03 October 2006, 20:30 GMT
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
Comment by Robert Keevil (obo) - Tuesday, 03 October 2006, 21:16 GMT
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.
Comment by mrinferno (mrinferno) - Thursday, 05 October 2006, 02:10 GMT
quick question, is the Last.FM client supposed to grab the .scrobbler.log and submit it automatically?
as stated in the 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?

Comment by Robert Keevil (obo) - Thursday, 05 October 2006, 08:27 GMT
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).
Comment by Linus Nielsen Feltzing (linusnielsen) - Thursday, 05 October 2006, 08:34 GMT
I'd like to set up a log submission service on
Comment by Tim G (kernelsandirs) - Thursday, 05 October 2006, 16:37 GMT
Here is the latest version of LogScrobbler that I made for windows XP, a little app to sync your logs
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.

Tim G.
Comment by Robert Keevil (obo) - Thursday, 05 October 2006, 18:24 GMT
Sync to CVS.
Tim - how did you get on with the testing?
Comment by Tim G (kernelsandirs) - Thursday, 05 October 2006, 21:28 GMT
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
Comment by Robert Keevil (obo) - Thursday, 05 October 2006, 22:31 GMT
No problem - glad it's behaving as it should now.
Comment by Tim G (kernelsandirs) - Saturday, 07 October 2006, 01:53 GMT
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 and saw what you really listen to ;-)

This version also uses UTC time for posting files(since it was supposed to to begin with), and maybe a few other fixes
Comment by Tim G (kernelsandirs) - Sunday, 08 October 2006, 16:09 GMT
Here is LogScrobbler 0.6 <<Requires .NET 2.0 >>

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

Tim G.
Comment by Kyle H (gonemad) - Tuesday, 10 October 2006, 05:01 GMT
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

#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 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
Comment by Kyle H (gonemad) - Tuesday, 10 October 2006, 14:46 GMT
actually i think this was my error.. so ignore what i said for now... i'll repost if it truely wasnt my error
Comment by Sacha (Angyman) - Friday, 13 October 2006, 00:03 GMT
Hmm, does anyone else here got a problem with the current CVS build ;-) ?
Comment by Tim G (kernelsandirs) - Friday, 13 October 2006, 06:55 GMT
LogScrobbler 0.7 here
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
Comment by Robert Keevil (obo) - Friday, 13 October 2006, 08:35 GMT
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.
Comment by Linus Nielsen Feltzing (linusnielsen) - Wednesday, 18 October 2006, 09:06 GMT
New version, synched to CVS. This one flushes the log to disk when entering USB mode.
Comment by Robert Keevil (obo) - Wednesday, 18 October 2006, 12:13 GMT
Move the log file creation from init to write_cache.

Haven't yet tested on target.