GNOME Bugzilla – Bug 508895
audio scrobbler fails to load play time
Last modified: 2008-04-04 11:47:19 UTC
Please describe the problem: rb_audioscrobbler_load_entry_from_string() uses mktime() to load play time. Saved play time is represented as GMT time but mktime() treated passed struct tm is represented as local time. On my environment (JST), loaded play time is 9 hours ago. Steps to reproduce: 1. Start Rhythmbox on off-line environment. 2. Play (and sing) a song to queue the song. 3. Exit Rhythmbox. 4. Start Rhythmbox on on-line environment. 5. Wait a moment untile queued songs are sent. Actual results: Wrong time stamp request is sent to the audio scrobbler server. And my last.fm page says like that "your request has older time stamp rather than the previous request". Expected results: Correct time stamp request is sent. Does this happen every time? Yes, if you don't live in GMT area. Other information:
Created attachment 102645 [details] [review] adjusts time zone.
From time to time I see this problem, at least once in a 24-hour period rhythmbox somehow loses contact with the last.fm server (even if I'm otherwise online) and starts to accumulate in the queue. Once contact is restored, then some tracks are added in reverse chronological order to my last.fm profile, but after about 5-6 tracks I get "spam notification" messages. I never used to see this before. I'll test this patch to see if solves the problem.
To avoid having to do tricky things altogether, I think it'd be better to store the timestamp in the queue file as UTC seconds since epoch, rather than formatting and parsing it.
Created attachment 107799 [details] [review] store time_t instead, add a test for this also splits the code for dealing with AudioscrobblerEntry structures out to a separate file and adds a test for it.
I didn't run the patch but it seems good for me.
Committed to svn.