[Pkg-kde-extras] Bug#681121: Bug#681121: amarok: attempts to upgrade MySQL database on every application start

[Ira Rice]

Replying to this since I have a new theory on what might be going on in
this bug, and which might end up with resolving this issue if someone would
check the code to see if this is the case or not (not that I can't, but I'd
honestly prefer to leave this to someone who knows where to look and is
more familiar with the code base, rather than to miss something important).

What I think is going on is this: Amarok is set to time out and bail out of
the database upgrade after allowing for it to continue on for a set amount
of time (maybe 2 hours or so), after which point, the upgrade is left in an
incomplete state overall. Due to the size of my playlist, which is above
and beyond what the developers tend to expect, I've timed out on several
occasions, and it led me to believe that it in fact wasn't completing the
database upgrade, and was perhaps redoing it each time it launched.

Now, the main reason I mentioned this is that recently, it appears as if I
am finally down to a few minutes of wait time on my last launch, which is a
huge improvement over what it has been. If the upgrade was failing each
time, then I wouldn't expect to see this.

However, if this is closed, I do think that there are perhaps a few
different bugs which might be worth filing upsteam to help avoid this in
the future:

1. Implement a dialog showing the progress on the database upgrade. The
release notes said that this was present, but I never saw it.
2. Don't block on database upgrading and run the upgrade in the background
(but block functionality that depends on that upgrade from working until it
completes). This though, might be a big task though, depending on how the
code's structured.

In any case, just thought that I'd report on this, since I figured this new
information might help a lot in isolating the culprit of this problem. Let
me know what you want done on this.

On Thu, Jul 12, 2012 at 3:02 PM, Ira Rice <irarice at gmail.com> wrote:

>
>
> On Thu, Jul 12, 2012 at 2:37 PM, Modestas Vainius <modax at debian.org>wrote:
>
>> Hello,
>>
>> On Tuesday 10 July 2012 13:07:23 Ira Rice wrote:
>>
>> > In the NEWS file for 2.6~beta1, it mentioned that for smaller playlists,
>> there
>> > would be a few minute delay while it updated the database format.
>>
>> There is no NEWS file in amarok packaging. You are probably referring to
>> changelog.gz
>>
>> Anyway, could you exactly quote the changelog entry you are referring to?
>>
>
> I seem to recall getting a prompt of some sort, perhaps from apt-listbugs,
> which alerted me to a database upgrade. I don't see it mentioned in the
> changelog, and assumed that it was from the NEWS file, because of my own
> settings with it.
>
> However, you can see the same announcement about a database upgrade if you
> look at the beta announcement for 2.6 beta 1 for amarok (
> http://amarok.kde.org/en/releases/2.6/beta/1), where it says: "This
> release includes a database update that can take up to a few minutes to
> complete. A dialog will prevent use of Amarok while this critical change is
> applied."
>
>
>>
>> > However, I
>> > have a larger database (4600+ tracks in a playlist, with more on disk),
>> and
>> > this takes more along the lines of 1 1/2 to 2 hours, where it then
>> doesn't
>> > give any obvious indication that it is then doing anything (but which I
>> can
>> > verify that it's upgrading the tables through MySQL Workbench).
>>
>> Can you paste what
>>
>> $ cat ~/.kde/share/apps/amarok/mysqle/amarok/admin.MYD | od -a -x
>>
>> returns? You may get more help by reporting the bug to
>> https://bugs.kde.org
>> though.
>>
>
>
> Sure:
>
> 0000000 etx nul dc3 soh nul   ~  ff   A   M   A   R   O   K   _   T   R
>            0003    0113    fe00    410c    414d    4f52    5f4b    5254
> 0000020   A   C   K soh nul nul nul nul soh nul dc1 nul   ~  nl   D   B
>            4341    014b    0000    0000    0001    0011    0afe    4244
> 0000040   _   V   E   R   S   I   O   N bel nul nul nul soh nul nak nul
>            565f    5245    4953    4e4f    0007    0000    0001    0015
> 0000060   ~  so   A   M   A   R   O   K   _   P   O   D   C   A   S   T
>            0efe    4d41    5241    4b4f    505f    444f    4143    5453
> 0000100 etx nul nul nul etx nul sub stx nul   ~ dc3   A   M   A   R   O
>            0003    0000    0003    021a    fe00    4113    414d    4f52
> 0000120   K   _   U   S   E   R   P   L   A   Y   L   I   S   T stx nul
>            5f4b    5355    5245    4c50    5941    494c    5453    0002
> 0000140 nul nul nul nul etx nul etb soh nul   ~ dle   A   M   A   R   O
>            0000    0000    0003    0117    fe00    4110    414d    4f52
> 0000160   K   _   B   O   O   K   M   A   R   K   S eot nul nul nul nul
>            5f4b    4f42    4b4f    414d    4b52    0453    0000    0000
> 0000200
>
> As for reporting my bug directly, I can't say that I've really had much
> success with that in the past in relation to other bugs, and have had more
> luck with IRC (which, although they then got fixed, then got reverted back
> to where they were before shortly afterwards, which kind of shook some of
> my confidence in them a bit), as well as having been redirected on a few of
> them as well, which still haven't been fixed, to report them to my distro
> directly, because they then claimed that they didn't exist, even though I
> could reproduce them on several different machines that I had or which I
> had access to.
>
> In any case, while getting this fixed upstream would be rather desirable
> for me, all I'm concerned with at the moment is whether this is suitable
> for release in Wheezy or not. Also, sorry for the short rant as well for
> why I haven't bothered with forwarding this upstream yet.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-kde-extras/attachments/20120731/c2621574/attachment.html>