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
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
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 <irar...@gmail.com> wrote:
> On Thu, Jul 12, 2012 at 2:37 PM, Modestas Vainius <mo...@debian.org>wrote:
>> 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,
>> > 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
>> 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
>> > However, I
>> > have a larger database (4600+ tracks in a playlist, with more on disk),
>> > this takes more along the lines of 1 1/2 to 2 hours, where it then
>> > give any obvious indication that it is then doing anything (but which I
>> > 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
> 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
> 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.
pkg-kde-extras mailing list