Version: 1.3-SVN 21/05/2003 (using KDE KDE 3.3.1) Installed from: Fedora RPMs Compiler: gcc 3.4.3 OS: Linux Tracks are not submitted to Audioscrobbler when played. The Audioscrobbler server is functioning correctly and tracks can be submitted from other applications (xmms/bmp). Markey suggested that there is an existing bug report about this, http://amarok.kde.org/component/option,com_simpleboard/Itemid,57/func,view/id,5675/catid,8/limit,6/limitstart,12/ but I couldn't find it.
In case it's relevant: I'm using gstreamer engine + alsa sink.
SVN UP, compile with debug, and see what error messages you get. Remember that if you seek the track shouldn't be submitted (AudioScrobbler rule). Anyway, it's a dup of bug #100278, add the information there from now on. :-) *** This bug has been marked as a duplicate of 100278 ***
> SVN UP, compile with debug, and see what error messages you get. Unfortunately I can't get debug messages! bug #106328 When I get some I will post them. > Remember that if you seek the track shouldn't be submitted (AudioScrobbler > rule). I'm not seeking. > Anyway, it's a dup of bug #100278, add the information there from now on. :-) I'm not sure that this is a duplicate of that bug. I've seen that report before and the symptoms are different. NO tracks are EVER submitted for me. I've even tried the suggested fix from that other report, but no joy. I won't reopen this yet in case I'm missing something.
I just updated my gstreamer engine using the rpms from their own repository, rather than the FC3 ones, and tracks are now getting submitted. I updated the engine because the track position slider wasn't moving (something I hadn't noticed before), but it has fixed most of my issues. Thanks for your help guys.
Is it possible that this happens on slower machines more frequently? When I'm only playing music and doing nothing else, all tracks seem to be submitted, but if my system load is high, more and more tracks are dropped. My guess is that the seek detection is the problem. From what I've read on another Audioscrobbler related bug report, I think that the detetion works by comparing the current playing time with the time of the last cycle. A consequence of such a mechanism would be a positive seek detection if the system load is too high. Unfortunately, I can't post any related debug message.
der Graph, it's supposed to be fixed, check bug #100278. Test 1.3-beta3 (not yet released, but it's probably going to be released soon) when possible. It seems your ideas were right though. :-)