On 5. 6. 2012 Alan Ezust wrote:
> Hi Matěj,
>
> Here are the rowcounts for the tables, bad and good
>
> amarok2 amarok3
> (bad) (good)
> albums 2485 2629
> artists 2301 2335
> composers 199 199
> devices 12 0
> genres 194 195
> labels 0 0
> tracks 18702 18661
> urls 18699 18661
> statistics 38446 18661
>
> I thought the culprit was the "statistics" table.
> There are quite a lot of entries in it that have a "deleted" = 1.
> So I did a "delete from statistics where deleted=1" to see if that got
> rid of the delays.
> It did not.
Hmm, nothing major wrong here.
> Then I followed the instructions above and ran mysql with logging of
> long transactions.
> I started up Amarok with the bad DB and let it play to the end of the
> first track.
> It had a long delay to figure out what to play next, and then repeated
> the same track.
>
> Here is my mysql log.
Hmm, nothing interesting here, the slowest query is 0.2s if I understand it
correctly, to 20-30 s delays. You say the Amarok event loop stops for that
extended periods of time. Could you please:
1. Install debugging symbols for Amarok, kdelibs, qt, glibc, glib
2. Run Amarok grom gdb: `gdb --ex run --args amarok --debug --nofork`
3. Trigger the temporary freeze
4. Hit Ctrl+C in gdb,
`(gdb) thread apply all bt 30` <- save entire backtrace
`(gdb) cont` <- resumes normal Amarok operation
Please repeat Ctrl+C -> backtrace -> cont cycle several times and look if the
backtrace of Thread 1 looks similar each time. If so, please file a bug about
it, copy the full backtrace and CC me on the bug.
Thanks,
Matěj
_______________________________________________
Amarok mailing list
[email protected]
https://mail.kde.org/mailman/listinfo/amarok
