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).<br>
<br>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.<br>
<br>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.<br>
<br>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:<br><br>1. Implement a dialog showing the progress on the database upgrade. The release notes said that this was present, but I never saw it.<br>
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.<br>
<br>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.<br><br><div class="gmail_quote">
On Thu, Jul 12, 2012 at 3:02 PM, Ira Rice <span dir="ltr"><<a href="mailto:irarice@gmail.com" target="_blank">irarice@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br><br><div class="gmail_quote"><div class="im">On Thu, Jul 12, 2012 at 2:37 PM, Modestas Vainius <span dir="ltr"><<a href="mailto:modax@debian.org" target="_blank">modax@debian.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hello,<br>
<br>
On Tuesday 10 July 2012 13:07:23 Ira Rice wrote:<br>
<br>
> In the NEWS file for 2.6~beta1, it mentioned that for smaller playlists,<br>
there<br>
> would be a few minute delay while it updated the database format.<br>
<br>
There is no NEWS file in amarok packaging. You are probably referring to<br>
changelog.gz<br>
<br>
Anyway, could you exactly quote the changelog entry you are referring to?<br></blockquote></div><div><br>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.<br>
<br>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 (<a href="http://amarok.kde.org/en/releases/2.6/beta/1" target="_blank">http://amarok.kde.org/en/releases/2.6/beta/1</a>), 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."<br> </div><div class="im"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> However, I<br>
> have a larger database (4600+ tracks in a playlist, with more on disk), and<br>
> this takes more along the lines of 1 1/2 to 2 hours, where it then doesn't<br>
> give any obvious indication that it is then doing anything (but which I can<br>
> verify that it's upgrading the tables through MySQL Workbench).<br>
<br>
Can you paste what<br>
<br>
$ cat ~/.kde/share/apps/amarok/mysqle/amarok/admin.MYD | od -a -x<br>
<br>
returns? You may get more help by reporting the bug to <a href="https://bugs.kde.org" target="_blank">https://bugs.kde.org</a><br>
though.<br>
</blockquote></div></div><br><br>Sure:<br><br>0000000 etx nul dc3 soh nul ~ ff A M A R O K _ T R<br> 0003 0113 fe00 410c 414d 4f52 5f4b 5254<br>0000020 A C K soh nul nul nul nul soh nul dc1 nul ~ nl D B<br>
4341 014b 0000 0000 0001 0011 0afe 4244<br>0000040 _ V E R S I O N bel nul nul nul soh nul nak nul<br> 565f 5245 4953 4e4f 0007 0000 0001 0015<br>
0000060 ~ so A M A R O K _ P O D C A S T<br> 0efe 4d41 5241 4b4f 505f 444f 4143 5453<br>0000100 etx nul nul nul etx nul sub stx nul ~ dc3 A M A R O<br>
0003 0000 0003 021a fe00 4113 414d 4f52<br>0000120 K _ U S E R P L A Y L I S T stx nul<br> 5f4b 5355 5245 4c50 5941 494c 5453 0002<br>
0000140 nul nul nul nul etx nul etb soh nul ~ dle A M A R O<br> 0000 0000 0003 0117 fe00 4110 414d 4f52<br>0000160 K _ B O O K M A R K S eot nul nul nul nul<br>
5f4b 4f42 4b4f 414d 4b52 0453 0000 0000<br>0000200<br><br>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.<br>
<br>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.<br>
</blockquote></div><br>