[gpodder-devel] Using Audioscrobbler Log Files To Mark Shows As Played

  • From: me at nikosapi.org (nikosapi)
  • Date: Sat, 29 Mar 2008 11:30:11 -0500

On March 29, 2008 11:24:32 Thomas Perl wrote:
> Hello, Nick!
> On Fri, 2008-03-28 at 11:11 -0500, nikosapi wrote:
> > Thank you for looking over and improving my code :)
> >
> > I added one small thing, if find_mount_point() returns '/' then to
> > prevent find_scrobbler_log() from os.walk()'ing your whole root
> > filesystem we simply set mp3_player_mount_point to the the directory
> > that we're syncing to. Appart from that I think the patch is ready.
> Thanks, I've applied your patch as-is to SVN trunk :)
> > Ideally the .scrobbler.log file should be cleaned by scrobbler
> > software that submits tracks to last.fm. I wrote a small python module
> > that can scrobble tracks but I don't really think that it belongs in
> > gPodder. (Unless you really think otherwise...)
> Yes, I also think that the clean-up has to be taken care by the last.fm
> client, that's what the spec also says. I just wondered if rockbox had
> any kind of intelligence built-in that would make sure the file didn't
> grow endlessly if the file is never deleted by a last.fm client (as is
> the case when one enables this feature for the sole purpose of getting
> played state synchronization to work with gPodder, without ever using
> last.fm).
> Thomas

Looking at apps/scrobbler.c in the Rockbox source shows no indication that it 
will attempt to truncate the logfile in the event that it gets too large. 
That being said, my logfile has 3000 entries in it and there isn't any 
noticeable performance impact when syncing.

Worst case, the user would just have to delete their .scrobbler.log every few 
months if loading the logfile begins to take too long. We can always just add 
a notification to alert the user that the logfile is getting too large...


Other related posts: