Version: 1.2 (using KDE KDE 3.3.2) Installed from: Unlisted Binary Package Compiler: gcc 3.4.3 OS: Linux The first ever played song from an artist from which i haven't played any songs yet is not submitted to audioscrobbler. The second, third and so on are submitted as they should.
Perhaps it is submitted, but a bug in audioscrobbler does not record the submission. Can you watch ~/.kde/share/apps/amarok/submit.xml to see if it gets submitted at all.
I'd recommend checking the debug output that amaroK produces when you run it from console and see the lines starting with "[Scrobbler]" to see what happens to the first submission. I am sure that amaroK tries to submit it, there is no code that would make difference for the first play of the artist. Some possibilities, why the track would not get submitted: - you seek forward when you play - the track is less than 30 secs - the track does not contain good tags
>Some possibilities, why the track would not get submitted: >- you seek forward when you play >- the track is less than 30 secs >- the track does not contain good tags no, no and no If i play the track one more time it gets submitted submit.xml stays empty. Output from the console: amarok: BEGIN: UrlLoader amarok: BEGIN: UrlLoader::UrlLoader(const KURL::List&, QListViewItem*, bool) amarok: [KDE::ProgressBar::ProgressBar(QWidget*, QLabel*)] amarok: END__: UrlLoader::UrlLoader(const KURL::List&, QListViewItem*, bool) - Took 0s amarok: END__: virtual void Playlist::contentsDropEvent(QDropEvent*) - Took 0s amarok: [StatusBar] 1updateProgressAppearance() amarok: [ThreadWeaver] Job completed: UrlLoader. Jobs pending: 0 amarok: END__: UrlLoader - Took 0.03s amarok: [controller] Loading URL: file:/home/zmeyski/mp3/Alice%20Cooper/Brutal%20Planet/01%20Alice%20Cooper%20-%20Brutal%20Planet.mp3 amarok: BEGIN: void EngineSubject::stateChangedNotify(Engine::State) amarok: [virtual void amaroK::StatusBar::engineStateChanged(Engine::State)] Line: 121 amarok: END__: void EngineSubject::stateChangedNotify(Engine::State) - Took 0s amarok: BEGIN: void EngineSubject::newMetaDataNotify(const MetaBundle&, bool) amarok: [745x124] amarok: 5 amarok: 33 amarok: END__: void EngineSubject::newMetaDataNotify(const MetaBundle&, bool) - Took 0.12s amarok: [Scrobbler] Suggestions retrieved (29) amarok: [CollectionDB] Similar artists received amarok: [virtual KDE::ProgressBar::~ProgressBar()] amarok: [StatusBar] 1hideMainProgressBar() amarok: [ThreadWeaver] Job aborted: CollectionReader. Jobs pending: 0 amarok: [ThreadWeaver] Job aborted: CollectionReader. Jobs pending: 0 amarok: [ThreadWeaver] Job aborted: CollectionReader. Jobs pending: 0 amarok: [ThreadWeaver] Job aborted: CollectionReader. Jobs pending: 0 amarok: [ThreadWeaver] Threads in pool: 2 amarok: [ThreadWeaver] Job aborted: CollectionReader. Jobs pending: 0 amarok: BEGIN: void EngineSubject::stateChangedNotify(Engine::State) amarok: END__: void EngineSubject::stateChangedNotify(Engine::State) - Took 0.27s amarok: [377x82] amarok: 11 amarok: 51
I experience the same behaviour (and checked with amaroK CVS-20050224, KDE-3.2.2 and gcc-3.4.3), with no mention of submission on console output.
What sound engine are you using? It sounds like the engine is not sending the engineTrackPositionChanged notifications, which will trigger the submission.
I just tested with gstreamer, arts and xine engines and couldn't see any problems. When you play the track which fails to submit, does the song progress indicator update properly?
I tested this with both arts and xine engines. The progress indicator is updating
I just found out taht this only happens if amaroK is configured to retrieve similar artists from audioscrobbler. To reproduce enable retrieval of similar artists and play a song from a new artist.
I have always had retrieve similar artists enabled when I tested. I'll try to investigate why retrieving would disable submission.
I can confirm this. As far as i can tell, engineTrackPositionChanged isn't called when an artist doesn't have anything in its related_artists cache, and the similar artists are retrieved from the audioscrobbler webservice. The track isn't submitted, and similar tracks aren't appended if that option is enabled. The next time you play the artist it works fine. Any idea why this is?
OK, on further testing, i've found some exceptions to the above. If the song is by a new artist but audioscrobbler fails to receive any similar artists (too obscure to have generated a list there yet), then the song *will* submit OK. If appending similar is enabled it adds what appears to be a totally random track to the playlist (don't know if this is supposed to happen, but i like this behaviour). Also, if you save a new tag for a song by a new artist whilst playing it (before the 240sec/50% mark, obviously)*, even if the artist field is identical to what it was before, the song will submit and a new similar artist will be appended to the playlist (if enabled). Have spoken to some other users but no one else appears to be able to reproduce this bug. :( Gotta be a setting somewhere i guess... * only tried this via the "musicbrainz" button so far.
After inserting debug lines in here there and everywhere, i've found that the engineTrackPositionChanged *is* being called for new artists, only is failing on one of the following conditions: if ( m_prevPos != 0 ) { // TODO: It would be nice to have some more accurate method for // detecting user seek. Now use MAIN_TIMER events with 2 sec // tolerance. if ( posChange > 2000 + EngineController::MAIN_TIMER ) // Position has changed more than it would during normal // playback. m_validForSending = false; ...etc. After that it fails continuously on: if ( !m_validForSending ) as it has been set false. (By the way just because something isn't valid for submitting to audiscrobbler, why shouldn't a suggestion already retrieved be appended to the playlist?) Increasing 2000 to 10000 (probably overkill, but i'm sick of this!) does the trick, and artists are now submitting fine, and recommended tracks are appended to the playlist. Why this only happens on new artists i don't know, and for only some people. Maybe my pentium 4 3ghz takes too long to do a small INSERT into a database and somehow stalls the engine? *shrug* :) Good luck solving it, if you choose to. :)
*** Bug 106327 has been marked as a duplicate of this bug. ***
Can someone still reproduce this with 1.2.4/1.3-beta1?
I am having a similar problem with 1.3-SVN. The tracks aren't being submitted, there is no listing of the track in submit.xml and there is no mention in the console debug info about submission. The difference, however, is that it is not always a new artist, nor is it always an artist that has few recommendations from audioscrobbler.For example, the last track that failed to submit was by Slayer, a band that has no shortage of recommendations from 'scrobbler, and has been in my collection for over a month.
Agreed that this is hard to test/reproduce when the Audioscrobbler servers are a bit up and down, but I'm seeing this in both 1.2.4 and 1.3 beta1. It seems to be frustratingly unpredictable, but when Amarok is misbehaving it makes no visible attempt to submit at all, and adds nothing to submit.xml. I'd say on average right now it's submitting one song at random from 10 or more. Audioscrobbler servers are currently reliable, and Rhythmbox/Rbscrobbler are submitting consistently and successfully. There's definitely something broken in Amarok's submissions. Xine engine, and tested stuff suggested above: it's not related to it being a new artist for me, seemingly, and "retrieval of similar artists" makes no difference. I can't see any pattern.
SVN commit 429556 by aoliveira: Just adding some debug information to help on debugging Bug #100278. CCBUG: 100278 M +6 -1 scrobbler.cpp --- trunk/extragear/multimedia/amarok/src/scrobbler.cpp #429555:429556 @@ -211,6 +211,7 @@ // Tags were changed, update them if not yet submitted. // TODO: In this case submit could be enabled if the artist or title // tag was missing initially and disabled submit + debug() << "It's still the same track." << endl; if ( m_item != NULL ) { m_item->setArtist( bundle.artist() ); @@ -224,8 +225,10 @@ // Plugins must not submit tracks played from online radio stations, even // if they appear to be providing correct metadata. - if ( bundle.streamUrl() != NULL ) + if ( bundle.streamUrl() != NULL ) { + debug() << "Won't submit: It's a stream." << endl; m_validForSending = false; + } else { if ( m_item != NULL ) @@ -242,6 +245,7 @@ { m_item = NULL; m_validForSending = false; + debug() << "Won't submit: No artist, no title, or less than 30 seconds." << endl;; } } } @@ -267,6 +271,7 @@ // Position has changed more than it would during normal // playback. m_validForSending = false; + debug() << "Won't submit: Seek of " << posChange << "ms detected." << endl; return; } }
Well, I can't reproduce this, so I've added some more debugging information. The idea is that it should tell you the reason it didn't submit. Remember, these are AudioScrobbler rules: - Each song should be posted to the server when it is 50% or 240 seconds complete, whichever comes first. - If a user seeks (i.e. manually changes position) within a song before the song is due to be submitted, submission should be cancelled. - Songs with a duration of less than 30 seconds should not be submitted. Please, if you can test svn, tell me what it outputs when it "silently fails".
Don't have SVN just now, so can't provide debugging yet. But just to confirm that I'm aware of the Audioscrobbler rules, and yes, the tracks I see that don't submit or go into submit.xml (almost all of them) do comply with the submission rules (and I don't seek within tracks). Sorry, I just can't see a pattern.
Same behaviour confirmed in 1.3beta2. Tracks seemingly submitted at random, about 1 in 5. Gstreamer or xine engine. Amarok makes no attempt to submit the other tracks to audioscrobbler, and doesn't put anything in submit.xml. It seems that a lot of people are seeing this bug, in 1.2.4, beta1, beta2 and SVN. Why does it remain uncomfirmed?
Probably because we can't reproduce it. Please, there are often problems such as audioscrobbler submissions disabled. also, submit.xml is only written on application close. Launch amarok from the console, and monitor audioscrobbler output, you might find some KIO errors.
As stated earlier in the reports, no KIO errors. Here's the only output I see in console for a track played which didn't submit: (process:3454): GStreamer-CRITICAL **: gst_bin_remove_func: assertion `GST_ELEMENT_PARENT (element) == (GstObject *) bin' failed (process:3454): GStreamer-WARNING **: pads don't accept old caps. We assume they did though (process:3454): GStreamer-WARNING **: pads don't accept old caps. We assume they did though - just the same output as for tracks that do submit. Built with --enable-debug=full. 1.2.1 submitted flawlessly, and rbscrobbler/rhythmbox continues to do it flawlessly now - I'm conscious of audioscrobbler server hold-ups so am careful to compare. I'm surprised you say submit.xml isn't written until app close - I see it writing every song it submits to audioscrobbler into it as it runs, that subsequently disappear once submitted. The songs which don't get submitted never appear in submit.xml. As stated before, I'm aware of audioscrobbler submission rules (time limits, no scanning etc.) and the missing tracks comply with these. They just never appear anywhere, and I never see the taskbar in Amarok indicating any attempt at submission. What else can I and others do to help debugging this? For me an internal audioscrobbler submission engine is vital to use Amarok,and one of the big attractions in the first place - I've had to discontinue using it for now.
I've already said what can be done. Get svn compiled with debug and check the output. (Or wait for beta3 to do that.) Now it will say the reason it doesn't submit, I supect it's detecting false seeks, but I can't be sure as I can't reproduce. Anyway, almost nothing had changed since 1.2.1 in that matter, but I'll check the diffs.
OK. Today's SVN uploaded, configured with --enable-mysql --enable-debug=full --prefix=`kde-config --prefix` and installed, and I played a whole LP consecutively. No manually skipping of tracks etc., just left amarok alone. It submitted the 1st and 3rd tracks, but not the 2nd. Track 2 was 4:19 in length. Here's the output from the console for the whole run up until the end of track 3: % amarok amaroK: [Loader] Starting amarokapp.. amaroK: [Loader] Don't run gdb, valgrind, etc. against this binary! Use amarokapp. QObject::connect: Cannot connect Engine::Base::statusText( const QString& ) to (null)::shortMessage( const QString& ) QObject::connect: Cannot connect Engine::Base::infoMessage( const QString& ) to (null)::longMessage( const QString& ) QLayout: Adding KToolBar/mainToolBar (child of QVBox/unnamed) to layout for PlaylistWindow/PlaylistWindow teapot%~> (process:10985): GStreamer-WARNING **: pads don't accept old caps. We assume they did though couldn't open fontconfigs chosen font with Xft!!! couldn't open fontconfigs chosen font with Xft!!! couldn't open fontconfigs chosen font with Xft!!! couldn't open fontconfigs chosen font with Xft!!! (process:10985): GStreamer-WARNING **: pads don't accept old caps. We assume they did though (process:10985): GStreamer-CRITICAL **: gst_bin_remove_func: assertion `GST_ELEMENT_PARENT (element) == (GstObject *) bin' failed (process:10985): GStreamer-WARNING **: pads don't accept old caps. We assume they did though (process:10985): GStreamer-WARNING **: pads don't accept old caps. We assume they did though (process:10985): GStreamer-CRITICAL **: gst_bin_remove_func: assertion `GST_ELEMENT_PARENT (element) == (GstObject *) bin' failed (process:10985): GStreamer-WARNING **: pads don't accept old caps. We assume they did though (process:10985): GStreamer-WARNING **: pads don't accept old caps. We assume they did though No indication of successful or failed submissions to audiocrobbler, but track 2 doesn't appear there. There doesn't seem to be any difference in console output between successful and failed submissions. It may (or may not) be of relevance that submit.xml is now sitting there with an entry of track 3 in it, which it's already successfully submitted to audioscrobbler (it's now playing track 4). Comment #21 maintained this was only written at application close. Track 4 has now submitted successfully to audioscrobbler, and is now the only entry in submit.xml. Maybe this is expected behaviour. Please let me know if I can test further. Hopefully this is definite evidence that songs don't submit for some of us, and that debugging shows no indication of the lack of submission even in the latest SVN.
Run amarokapp, not amarok.
Done so - same results (I've marked the boundary between tracks with ***). The middle track below wasn't submitted, and didn't appear at all in submit.xml: % amarokapp QObject::connect: Cannot connect Engine::Base::statusText( const QString& ) to (null)::shortMessage( const QString& ) QObject::connect: Cannot connect Engine::Base::infoMessage( const QString& ) to (null)::longMessage( const QString& ) QLayout: Adding KToolBar/mainToolBar (child of QVBox/unnamed) to layout for PlaylistWindow/PlaylistWindow Caps negotiation succeeded with 44100 Hz @ 2 channels STARTUP (process:11336): GStreamer-WARNING **: pads don't accept old caps. We assume they did though (process:11336): GStreamer-WARNING **: pads don't accept old caps. We assume they did though couldn't open fontconfigs chosen font with Xft!!! couldn't open fontconfigs chosen font with Xft!!! couldn't open fontconfigs chosen font with Xft!!! couldn't open fontconfigs chosen font with Xft!!! ... (process:11336): GStreamer-CRITICAL **: gst_bin_remove_func: assertion `GST_ELEMENT_PARENT (element) == (GstObject *) bin' failed (process:11336): GStreamer-WARNING **: pads don't accept old caps. We assume they did though (process:11336): GStreamer-WARNING **: pads don't accept old caps. We assume they did though *** (process:11336): GStreamer-CRITICAL **: gst_bin_remove_func: assertion `GST_ELEMENT_PARENT (element) == (GstObject *) bin' failed (process:11336): GStreamer-WARNING **: pads don't accept old caps. We assume they did though (process:11336): GStreamer-WARNING **: pads don't accept old caps. We assume they did though *** (process:11336): GStreamer-CRITICAL **: gst_bin_remove_func: assertion `GST_ELEMENT_PARENT (element) == (GstObject *) bin' failed (process:11336): GStreamer-WARNING **: pads don't accept old caps. We assume they did though (process:11336): GStreamer-WARNING **: pads don't accept old caps. We assume they did though
I should add that it's nothing inherent to the songs themselves: they submit fine when replayed - just tested on the missing song above. Further details: I play my songs over a wireless (802.11g) NFS link from a server. They've never make any audible skipping sounds, and the connectivity is very solid; other audioscrobbler submission engines never miss songs (e.g. rhythmbox+rbscrobbler). SVN compiled with Fedora Core 4's legacy gcc32 compiler (CC=gcc32 ./configure ...). I'm not sure if any of the others in this thread having problems have features in common (doesn't look like they have), but I thought I'd add details in case. Kernel 2.6.12.2, kdebase 3.4.1.
There's something strange, you're not getting any debug output from amarok itself, only warnings. Check if you don't have amaroK installed in two different places, it seems you may still be running the old one or something. With debug, you would get MUCH more lines of debug.
Help - About Amarok: shows amaroK 1.3-SVN. I really did scrub all the other amarok installations from my system before starting. % amarok --version Qt: 3.3.4 KDE: 3.4.1-0.fc4.1 Red Hat amaroK: 1.3-SVN % amarokapp --version Qt: 3.3.4 KDE: 3.4.1-0.fc4.1 Red Hat amaroK: 1.3-SVN Please let me know if I can do any other checks.
Hmm, on further inspection it appears checkinstall (which I used to make an rpm out of make install) strips binaries and so's, so my fault. I'll reinstall and report back proper console output tomorrow. I have to say that it's taking longer to test because it's missing fewer submissions than a few weeks ago: unsure if this is improvements you've put in since 1.2.4 or some other variable.
Right, I've wiped out all amarok installations (checked) and reinstalled yesterday's SVN from scratch, exactly as per instructions, using FC4's gcc32, including a standard make install instead of checkinstall. I'm still not seeing much more debugging info when running amarokapp. Configure line: % CC=gcc32 ./configure --enable-mysql --enable-debug=full --prefix=`kde-config --prefix` All I can do is give you some random smatterings of lines from console output - these will include all the unique lines printed: % amarokapp QObject::connect: Cannot connect Engine::Base::statusText( const QString& ) to (null)::shortMessage( const QString& ) QObject::connect: Cannot connect Engine::Base::infoMessage( const QString& ) to (null)::longMessage( const QString& ) QLayout: Adding KToolBar/mainToolBar (child of QVBox/unnamed) to layout for PlaylistWindow/PlaylistWindow Caps negotiation succeeded with 44100 Hz @ 2 channels STARTUP (process:30410): GStreamer-WARNING **: pads don't accept old caps. We assume they did though (process:30410): GStreamer-WARNING **: pads don't accept old caps. We assume they did though couldn't open fontconfigs chosen font with Xft!!! couldn't open fontconfigs chosen font with Xft!!! couldn't open fontconfigs chosen font with Xft!!! couldn't open fontconfigs chosen font with Xft!!! ... (process:30410): GStreamer-CRITICAL **: gst_bin_remove_func: assertion `GST_ELEMENT_PARENT (element) == (GstObject *) bin' failed (process:30410): GStreamer-WARNING **: pads don't accept old caps. We assume they did though (process:30410): GStreamer-WARNING **: pads don't accept old caps. We assume they did though (process:30410): GStreamer-CRITICAL **: gst_bin_remove_func: assertion `GST_ELEMENT_PARENT (element) == (GstObject *) bin' failed (process:30410): GStreamer-WARNING **: push on peer of pad adder0:src but peer is not active (process:30410): GStreamer-WARNING **: push on peer of pad adder0:src but peer is not active ... (process:30410): GStreamer-CRITICAL **: gst_bin_remove_func: assertion `GST_ELEMENT_PARENT (element) == (GstObject *) bin' failed (process:30410): GStreamer-WARNING **: pads don't accept old caps. We assume they did though (process:30410): GStreamer-WARNING **: pads don't accept old caps. We assume they did though (process:30410): GStreamer-WARNING **: pads don't accept old caps. We assume they did though ... (process:30410): GStreamer-CRITICAL **: gst_bin_remove_func: assertion `GST_ELEMENT_PARENT (element) == (GstObject *) bin' failed TagLib: MPEG::Header::parse() -- Invalid sample rate. (process:30410): GStreamer-WARNING **: pads don't accept old caps. We assume they did though (process:30410): GStreamer-WARNING **: pads don't accept old caps. We assume they did though TagLib: MPEG::Header::parse() -- Invalid sample rate. TagLib: MPEG::Header::parse() -- Invalid sample rate. TagLib: MPEG::Header::parse() -- Invalid sample rate. (process:30410): GStreamer-CRITICAL **: gst_bin_remove_func: assertion `GST_ELEMENT_PARENT (element) == (GstObject *) bin' failed Somewhere in the midst of this, two tracks failed to submit to Audioscrobbler. It's hard to say where, as it's happening less just now - I'd say 1 track in 20 is missing on average. Watched a bit more closely, the middle track of three here didn't submit: (process:30410): GStreamer-CRITICAL **: gst_bin_remove_func: assertion `GST_ELEMENT_PARENT (element) == (GstObject *) bin' failed (process:30410): GStreamer-WARNING **: pads don't accept old caps. We assume they did though (process:30410): GStreamer-WARNING **: pads don't accept old caps. We assume they did though (process:30410): GStreamer-CRITICAL **: gst_bin_remove_func: assertion `GST_ELEMENT_PARENT (element) == (GstObject *) bin' failed (process:30410): GStreamer-WARNING **: pads don't accept old caps. We assume they did though (process:30410): GStreamer-WARNING **: pads don't accept old caps. We assume they did though (process:30410): GStreamer-CRITICAL **: gst_bin_remove_func: assertion `GST_ELEMENT_PARENT (element) == (GstObject *) bin' failed (process:30410): GStreamer-WARNING **: pads don't accept old caps. We assume they did though (process:30410): GStreamer-WARNING **: pads don't accept old caps. We assume they did though You can see a pattern for three tracks above - I see no difference between the output, but the middle one didn't submit.
It's still not generating any debug information at all, and I can't look for patterns inside of nothing... The string you're getting is not from our source, it's from gstreamer or one of these plugins. Check the info on bug #106328, maybe you're not getting the debug info due to some of the things described there. Anyway, I can make a patch only for your that uses a classic cout instead od the debug(), but that's bizarre.
Redhat patches kdelibs to output no debug info by default, but doesn't patch kdebugdialog accordingly, so it is broken. Please try to create (or modify) the file ~/.kde/share/config/kdebugrc to have the following two lines in it: [0] InfoOutput=2 I don't use FC, so I couldn't test, but it should enable debug output.
Thanks Stefan and Alexandre, helpful. Stefan, I imagine I also need to install some kde*-debuginfo packages after looking at the other thread (Red Hat/Fedora pagckage these separately, and they don't install by default)? I tried kdelibs-debuginfo, but it didn't seem to add console information. Unless it needs recompiling against once installed? I'll also of course try your suggestion.
OK, this took some time to reproduce, but I've found a track not submitted. Stefan was dead right, and you don't need any debuginfo packages installed. Submission rate seems highly variable - last night earlier on it failed on maybe one track out of 10 - later on 1 track in 3. This is of course taking into account Audioscrobbler server jams, and waiting for submit.xml to clear any backlog if it should happen. So with debug on, a good submission looks like this (my username/password removed and some context added): amarok: BEGIN: void CollectionView::scanDone(bool) amarok: END__: void CollectionView::scanDone(bool) - Took 0.00013s amarok: END__: virtual void CollectionDB::customEvent(QCustomEvent*) - Took 0.31s amarok: [ThreadWeaver] Job completed: CollectionReader. Jobs pending: 0 amarok: [virtual KDE::ProgressBar::~ProgressBar()] amarok: [StatusBar] 1hideMainProgressBar() amarok: [Scrobbler] Submit data: u=<username>&s=<password>&a[0]=Pia%20Fraus&t[0]=Deep%20Purple%20Girl&b[0]=Plastilina&m[0]=&l[0]=260&i[0]=2005-07-12%2013%3A54%3A28&a[1]=Pia%20Fraus&t[1]=Swim%20In%20Eyes&b[1]=Plastilina&m[1]=&l[1]=345&i[1]=2005-07-12%2013%3A58%3A17 kded: [int NetworkStatusModule::status(const QString&)] no networks have status for host 'http://post.audioscrobbler.com:80/protocol_1.1' amarok: [Scrobbler] Submit successful amarok: [StatusBar] 1resetMainText() amarok: BEGIN: virtual void CollectionDB::customEvent(QCustomEvent*) amarok: END__: virtual void CollectionDB::customEvent(QCustomEvent*) - Took 6.6e-05s amarok: [void CollectionDB::createTables(DbConnection*)] amarok: [KDE::ProgressBar::ProgressBar(QWidget*, QLabel*)] The last track on the LP, which emphatically did not skip or touch reported: amarok: [Scrobbler] Won't submit: Seek of 3788ms detected. I unfortunately lost contextual output around this, so will repeat. So it appears sometimes it's detecting false seeks? I don't have crossfading on, and am using Gstreamer/alsasink, but as before, I've seen this behaviour with the xine engine too. I'll continue to monitor debug output for better contextual evidence. Any suggestions welcome.
Apologies for the double posting - amarok SVN hung completely, and dcopserver hung firefox (I think because of the FoxyTunes plugin) - on restart it must have reposted. Anyway, I had three successive songs which failed to submit or appear in submit.xml. None of them displayed audible skipping of any kind. Here's as full output as I could save from one of them before the crash - again, it detected false skipping, which no other players do, and it's not a feature of the MP3s, as they submit fine when replayed usually. (process:6085): GStreamer-WARNING **: pads don't accept old caps. We assume they did though amarok: [CollectionDB] Found APIC frame(s) amarok: [CollectionDB] Size of image: 17156 byte (process:6085): GStreamer-WARNING **: pads don't accept old caps. We assume they did though amarok: END__: static void GstEngine::newPad_cb(GstElement*, GstPad*, gboolean, InputPipeline*) - Took 0.67s amarok: BEGIN: static void GstEngine::found_tag_cb(GstElement*, GstElement*, GstTagList*, void*) amarok: END__: static void GstEngine::found_tag_cb(GstElement*, GstElement*, GstTagList*, void*) - Took 0.00028s amarok: BEGIN: static void GstEngine::found_tag_cb(GstElement*, GstElement*, GstTagList*, void*) amarok: END__: static void GstEngine::found_tag_cb(GstElement*, GstElement*, GstTagList*, void*) - Took 0.00015s amarok: [588x88] amarok: 3 amarok: 25 amarok: BEGIN: virtual bool CurrentTrackJob::doJob() amarok: [CollectionDB] Found APIC frame(s) amarok: [CollectionDB] Size of image: 17156 byte amarok: END__: void EngineSubject::newMetaDataNotify(const MetaBundle&, bool) - Took 2.3s amarok: END__: void GstEngine::endOfStreamReached() - Took 2.6s amarok: [CollectionDB] Found APIC frame(s) amarok: [CollectionDB] Size of image: 17156 byte amarok: END__: virtual bool CurrentTrackJob::doJob() - Took 1.5s amarok: [ThreadWeaver] Job completed: CurrentTrackJob. Jobs pending: 0 amarok: [void CollectionDB::createTables(DbConnection*)] amarok: [KDE::ProgressBar::ProgressBar(QWidget*, QLabel*)] amarok: [StatusBar] 1updateProgressAppearance() amarok: [void CollectionDB::dropTables(DbConnection*)] amarok: BEGIN: virtual void CollectionDB::customEvent(QCustomEvent*) amarok: [CollectionDB] Event from IncrementalCollectionReader received. amarok: BEGIN: void CollectionView::scanDone(bool) amarok: END__: void CollectionView::scanDone(bool) - Took 0.0001s amarok: END__: virtual void CollectionDB::customEvent(QCustomEvent*) - Took 0.16s amarok: [ThreadWeaver] Job completed: CollectionReader. Jobs pending: 0 amarok: [virtual KDE::ProgressBar::~ProgressBar()] amarok: [StatusBar] 1hideMainProgressBar() amarok: BEGIN: virtual void CollectionDB::customEvent(QCustomEvent*) amarok: END__: virtual void CollectionDB::customEvent(QCustomEvent*) - Took 6.5e-05s amarok: [void CollectionDB::createTables(DbConnection*)] amarok: [KDE::ProgressBar::ProgressBar(QWidget*, QLabel*)] amarok: [StatusBar] 1updateProgressAppearance() amarok: [void CollectionDB::dropTables(DbConnection*)] amarok: BEGIN: virtual void CollectionDB::customEvent(QCustomEvent*) amarok: [CollectionDB] Event from IncrementalCollectionReader received. amarok: BEGIN: void CollectionView::scanDone(bool) amarok: END__: void CollectionView::scanDone(bool) - Took 7.3e-05s amarok: END__: virtual void CollectionDB::customEvent(QCustomEvent*) - Took 0.13s amarok: [ThreadWeaver] Job completed: CollectionReader. Jobs pending: 0 amarok: [virtual KDE::ProgressBar::~ProgressBar()] amarok: [StatusBar] 1hideMainProgressBar() amarok: [Scrobbler] Won't submit: Seek of 8176ms detected. amarok: BEGIN: virtual void CollectionDB::customEvent(QCustomEvent*) amarok: END__: virtual void CollectionDB::customEvent(QCustomEvent*) - Took 9.4e-05s amarok: [ThreadWeaver] Threads in pool: 2 amarok: [void CollectionDB::createTables(DbConnection*)] amarok: [KDE::ProgressBar::ProgressBar(QWidget*, QLabel*)] amarok: [StatusBar] 1updateProgressAppearance() amarok: [void CollectionDB::dropTables(DbConnection*)] amarok: BEGIN: virtual void CollectionDB::customEvent(QCustomEvent*) amarok: [CollectionDB] Event from IncrementalCollectionReader received. amarok: BEGIN: void CollectionView::scanDone(bool) amarok: END__: void CollectionView::scanDone(bool) - Took 0.00013s amarok: END__: virtual void CollectionDB::customEvent(QCustomEvent*) - Took 0.33s amarok: [ThreadWeaver] Job completed: CollectionReader. Jobs pending: 0 amarok: [virtual KDE::ProgressBar::~ProgressBar()] amarok: [StatusBar] 1hideMainProgressBar() amarok: BEGIN: virtual void CollectionDB::customEvent(QCustomEvent*) amarok: END__: virtual void CollectionDB::customEvent(QCustomEvent*) - Took 7.1e-05s amarok: [void CollectionDB::createTables(DbConnection*)] amarok: [KDE::ProgressBar::ProgressBar(QWidget*, QLabel*)] amarok: [StatusBar] 1updateProgressAppearance() amarok: [void CollectionDB::dropTables(DbConnection*)] amarok: BEGIN: virtual void CollectionDB::customEvent(QCustomEvent*) amarok: [CollectionDB] Event from IncrementalCollectionReader received. amarok: BEGIN: void CollectionView::scanDone(bool) amarok: END__: void CollectionView::scanDone(bool) - Took 0.0001s amarok: END__: virtual void CollectionDB::customEvent(QCustomEvent*) - Took 0.11s amarok: [ThreadWeaver] Job completed: CollectionReader. Jobs pending: 0 amarok: [virtual KDE::ProgressBar::~ProgressBar()] amarok: [StatusBar] 1hideMainProgressBar() amarok: BEGIN: virtual void CollectionDB::customEvent(QCustomEvent*) amarok: END__: virtual void CollectionDB::customEvent(QCustomEvent*) - Took 6.8e-05s amarok: [static void GstEngine::eos_cb(GstElement*, InputPipeline*)] amarok: BEGIN: void GstEngine::endOfStreamReached() amarok: An input pipeline has reached EOS, destroying. amarok: BEGIN: void GstEngine::destroyInput(InputPipeline*) amarok: [Gst-Engine] Destroying input pipeline. amarok: BEGIN: InputPipeline::~InputPipeline() amarok: [Gst-Engine] Destroying input bin.
On Tuesday 12 July 2005 17:18, gneeki wrote: > ------- Additional Comments From gneeki gmail com 2005-07-12 17:18 ------- > Apologies for the double posting - amarok SVN hung completely, and > dcopserver hung firefox (I think because of the FoxyTunes plugin) - on > restart it must have reposted. Careful with FoxyTunes. We've had numerous report about it doing weird things in combination with amaroK.
Ok it's for some weird reason detecting false seeks. We gotta change the way we detect them, the code doesn't seem reliable.
Thanks Alexandre. Mark, in reference to comment #38, thanks for the warning, noted. I'd be interested to know what kind of problems (crashes, dcopserver hangups?). Just also so add that the audioscrobbler submission problems have been happening before FoxyTunes - I only added it a few days ago.
SVN commit 435397 by aoliveira: A better way to detect seeks, so we don't detect false seeks and end up not submitting to AS. This makes a small change to engineTrackPositionChanged. It now has a bool parameter that's true if it's a user seek (ie, the position didn't change due to normal playback). CCMAIL: amarok-devel@lists.sourceforge.net BUG: 100278 M +1 -1 app.cpp M +1 -1 app.h M +8 -1 enginecontroller.cpp M +1 -1 enginecontroller.h M +2 -2 engineobserver.cpp M +3 -2 engineobserver.h M +1 -1 playerwindow.cpp M +1 -1 playerwindow.h M +5 -20 scrobbler.cpp M +1 -2 scrobbler.h M +1 -1 statusbar/statusbar.cpp M +1 -1 statusbar/statusbar.h M +1 -1 systray.cpp M +1 -1 systray.h
Thanks Alexandre. So far (a few LPs) I can report back that the latest SVN hasn't missed a song. The rate at which it missed them seemed highly variable when it was a problem, so I won't report this as a definitive fix to CLOSE the bug (others who had problems confirming would be good), but I'll run in debug mode and keep looking.
Right - I can't make your new algorithm break after some time of testing - haven't detected any tracks missing from submissions. This looks fixed for me - thanks.