beaTunes can't load preferences, can't find library
This morning I started beaTunes. I received two error messages in dialog boxes. I don't remember the exact wording, but it was something about not being able to load preferences. (It was the same error twice.) Then BT came up and wanted to create a new library, asking me if I wanted iTunes or folder-based.
I x-ed out of that, closed and re-opened BT. This time, no error messages, but it still wanted me to create a new library. I went to Preferences to see if I could select my existing library. There was nothing to select from in the drop-down list - not my regular library nor a couple of test libraries I had been playing around with a long time ago and had never deleted.
Just yesterday, BT finished running a big Task queue to add "color" to my tracks, and then resynchronizing my folders. Plus I did a few other ordinary things. But there were no problems yesterday. I shut down BT before retiring. Again, nothing out of the ordinary.
The library db files are still in their folder with a date/time of 6/30/2020 11:49pm (matching the BT shutdown time).
I don't know how to tell BT to load my preferences or how to get it to use my existing h2.db. Hendrik, can you help? I'll send logs in a moment in case that is needed.
Thanks,
Richard
(BT 5.2.9, folder-based library, approx 388k tracks, Windows 8.1, 32GB RAM, 8GB allocated to beaTunes in the environment variable)
PS- I see the preferences2.xml file in AppData/local. There seems to be some differences between the current one and an old backup I have form 2018. I'll explore further when I have more time.)
Comments are currently closed for this discussion. You can start a new one.
Keyboard shortcuts
Generic
| ? | Show this help |
|---|---|
| ESC | Blurs the current field |
Comment Form
| r | Focus the comment reply box |
|---|---|
| ^ + ↩ | Submit the comment |
You can use Command ⌘ instead of Control ^ on Mac
1 Posted by Richard on 01 Jul, 2020 05:11 PM
I'm thinking beaTunes created a new, default preferences2.xml when I opened it this morning and it couldn't find a valid xml file for whatever reason. I discovered a "preferences2.xml~" from 6/30/2020 at 5:06pm in my backups that is full of binary zeros and a same-named file in AppData Local that is identical to the current default preferences2.xml. Maybe yesterday's valid xml file got corrupted somehow? I did have a BSOD last night that I think was unrelated to beaTunes. I don't know what was going on with beaTunes when that happened. It might have been open but not doing anything. I had other things running as well. Maybe that corrupted my good preferences2.xml?
Comparing the 2018 preferences2.xml file to the new one reveals that the new one has nothing referencing a "file-collection persistentid" (I guess because BT created it new and I didn't go through the New Install dialog ).The 2018 xml has several, including the one I consider to be my current "real" library.
There are some other differences that I think are likely explained by choices I made that are different from the default New Install values. For example, "embed-audiometadata" is "false" in the new xml, but "true" in the 2018 xml.
I'll continue to work on this. My approach atm will be to manually create a new xml, taking relevant pieces from the old and see if that gets me back up and running. I probably will have lost some of my work since I have no more recent backup of the xml since 2018.
2 Posted by Richard on 01 Jul, 2020 09:05 PM
This may or may not be related to the thread I started earlier today. I manually created a preferences xml file I thought would be appropriate. Opened beaTunes. It displayed my library, seemingly up-to-date or pretty close to it. So far, so good.
I thought it might be a good idea to run Synchronize. It just took a couple of minutes (as I hoped it would) until the progress bar got to 100%. There it sits now for over 2 hours. Task Manager shows minimal disk activity but CPU usage in the 25-30% range. (See attached screen grabs.) I wonder what it is doing?
I could Cancel, but for now I'm letting it run.
Update: Now over 5 hours, same status.
Further update: It finished whatever it was doing at an unknown time between 6 and 21 hours after it started.
Support Staff 3 Posted by hendrik on 02 Jul, 2020 04:20 PM
Hey Richard,
indeed looking into preferences2.xml was a good idea.
I am not exactly sure what happened here.
Is it working as expected again?
Cheers,
-hendrik
4 Posted by Richard on 02 Jul, 2020 05:08 PM
I think everything is working as expected again. I'll know more over time, but so far I've seen nothing else unusual.
I decided to Analyze the entire library in order to add Mood. beaTunes estimates that process will complete sometime on July 7. So for the next week or so, I won't be using beaTunes for much else besides that. If I have any questions on Mood, I'll start a separate discussion thread. I do wonder, however, if the next Synchronize will "take forever" due to all the Mood updates, like it did for the Color updates, or if it will go quickly due to very few other changes in the library since the last Synchronize.
As always, thanks for your help.
Support Staff 5 Posted by hendrik on 05 Jul, 2020 10:55 AM
Hey Richard,
Note that mood is currently determined by looking up values via either Last.FM or AcousticBrainz. If neither service features your track, the mood field will remain empty. Also, because both methods require Internet lookups, the speed of the analysis does not so much depend on your hardware, but on your Internet bandwidth and rate limiting imposed by those services. That why it unfortunately takes pretty long.
As we have talked about in the other thread. It should not take forever, because beaTunes should be aware of its own changes, if this is a folder-based library. Synchronization for an iTunes/Music-based library works completely different.
If it takes forever again, please upload your logs right afterwards and let me know. That's definitely something I'd like to look into.
Thanks,
-hendrik
6 Posted by Richard on 06 Jul, 2020 02:53 PM
Hendrik, Thanks for that info. If I see a problem, I will upload the logs. I still have a couple of days to go before I get to that point.
(Update: This post was longer, but was somewhat off-topic. I moved the rest of the original post to a new discussion.)
7 Posted by Richard on 08 Jul, 2020 03:45 AM
Hendrik:
The task queue finished. I had to stop, reboot my PC and restart everything for reasons having nothing to do with beaTunes.. The task queue continued with about 94.000 tracks to go. Interestingly, the task queue ran a lot quicker after the PC reboot & beaTunes restart... about 10 times the rate it was going previously.
Anyway, after the task queue finished completely, I exited beaTunes, then restarted it, then began a Synchronize. It took 30-35 minutes for the progress bar to go from 0 to 100%. Then it continued working for another 6 hours, plus or minus one hour. There was nothing else substantial happening on the PC for the duration. Because it did take a long time, I just now uploaded the logs before proceeding further.
Synchronize didn't find any new tracks (at least none it offered to Inspect & Analyze). I thought there should have been a few, but maybe not. I don't know for sure. [Update July 8 (the next morning): Yes, beaTunes should have found 26 new songs I copied into the folders while the analysis was going on. Synchronize didn't pick them up.]
I noticed a few things. After the progress bar got to 100%, there was a period of 10-30 minutes where there was a lot of disk activity, and then for the remaining time, there was much less disk activity with the CPU for the beaTunes process at around 25%. I've attached a couple of screen grabs showing CPU and disk activity.
I also checked inetcache in Local AppData (C:\Users\Richard\AppData\Local\tagtraum industries\beaTunes\caches\inetcache). After Analyze finished, and after I closed beaTunes, inetcache stood at 7.0GB and 724,994 files. I don't know if that is significant or not. It seems like a lot of cache and it's taking up a lot of room on my SSD C: drive. FYI, my overall library is 388,326 songs in a folder-based library. I'm using beaTunes v5.2.9 at present.
I then shut down beaTunes again. Shut-down took 2 minutes, much longer than usual. After shut down, the h2.db file is slightly larger at 3,883,324 KB, and the inetcache is unchanged. I know db maintenance happens at shutdown, so I opened and exited beaTunes one more time. 25 seconds to open (which is good) and 1 minute 42 seconds to close (which is long). No change in the h2.db size and no change in inetcache. I was kind of hoping the shutdown process would get rid of some or all of the inetcache. Clearly, it doesn't.
I'll be curious as to what you think might be happening.
8 Posted by Richard on 08 Jul, 2020 03:54 AM
One more screen grab showing inetcache size.
I will say I'm a little gun-shy about doing another Synchronize if it's going to take 7 hours. I'm hoping it only took so long because of all the Task Queue updates that it needed to digest, and that next time it will go back to being quick, just a few minutes.
9 Posted by Richard on 08 Jul, 2020 03:11 PM
I discovered that the Synchronize that took about 7 hours to run did not find 26 tracks added to the music folders while the earlier multi-day Analyze was going on. I am now running Synchronize again (despite my hesitation expressed in the post immediately above) to see if those tracks will be picked up this time.
Synchronize begun at 9:52am. Progress bar went to 100% within 3 minutes. Synchronize is continuing to run as described earlier: CPU usage around 25% with nominal disk activity. Still going at 12:53pm. Note that there were no changes whatsoever within the library itself between the initiation of yesterday's Synchronize and the conclusion of today's.
This Synchronize finished sometime between 12:53pm and 1:52pm. So, 3.5 hours in total, plus or minus 0.5 hours, based on clock-watching. I see that the h2.db has a timestamp on it of 1:37pm, so maybe that's when the sync finished, which would mean a total runtime of 3 hours 45 minutes. And it did not pick up the new files it missed before, which is the result I expected. I think I'll have to update the time stamp on those files for Synchronize to find them.
I've looked into what inetcache is and realize that is likely unrelated to the lengthy Synchronize run. So my question there is, can that huge cache be gotten rid of somehow without causing a problem?
Support Staff 10 Posted by hendrik on 09 Jul, 2020 07:20 AM
Hey Richard,
Thanks for your descriptions and most importantly the logs. Something is definitely very inefficient there and needs to be investigated. I'll get back to you as soon as I have figured out what exactly is going on.
What I can say for sure is that it is not connected to the InetCache.
Cheers,
-hendrik
11 Posted by Richard on 09 Jul, 2020 02:56 PM
Hendrik, now I've confirmed a definite problem separate from but perhaps related to the preceding discussion.
I added a few dozen songs to my folders yesterday AFTER I did the most-recent Synchronize I described above. THEN, since sync takes so long, the last thing I did last night before turning in was to run Sync again to pick up the songs I just added. I expected to come in this morning and find that Sync had finished and it would be offering to Inspect and Analyze my new songs.
Instead, there were no Inspect of Analyze choices. beaTunes was just sitting there. h2.db has a time stamp of 7:46am today. I'm writing this at 9:21am. So that likely means the overnight Sync finished at 7:46am. (I checked that to make sure my memory didn't fail me and I really did run the Sync.)
I searched for some of the new tracks. beaTunes doesn't find them. So Synchronize ran for 6-hours plus but didn't actually incorporate any of the new tracks into the db.
That's definitely a problem bigger than just a performance issue. I can adjust to a performance issue for awhile. For this problem, I have no options.
I'm sending my logs again to document the latest info. BTW, it should have found...
> 3 new tracks in the new folder D:\MuDl\Propaganda [d]\The Nine Lives of Dr Mabuse
> 10 new tracks in the new folder D:\MuDl\Michael Cassidy [d]\Nature's Secret
> 32 new tracks in 3 new subfolders of the pre-existing folder D:\MuDl\Flash Cadillac & the Continental Kids [d]
> 6 updated tracks in the folder D:\MuDl\Livingston Taylor [d]\(no album) ... These were some of the tracks that should have been found by an earlier Synchronize from a couple of days ago. I had updated the comment tag of these tracks (with another app) in order to give them a newer time stamp, hoping that would cause Sync to find them this time.
There were others besides those listed.
As I write this I just remembered that I had to recreate my preferences2.xml last week. That was the original subject of this discussion thread. My library has 2 root folders, "D:\Rips" and "D:\MuDl". ("MuDl" is short for "Music Downloads".) Now I'm wondering if the MuDl folder group isn't fully incorporated into the library. My recollection is that I started out with Rips and then added MuDl later, back when I first started using beaTunes.
I'm going to exit beaTunes, take a fresh backup of the existing db, reopen bT, try to add MuDl (again?) as the second root folder, and then see if things are better. That might explain the mystery performance issue, too. It might have been churning through MuDl each time (which is has many more tracks than Rips) without a place to store those updates that it already knew about from the Analyze.
Update: "MuDl" was not referenced as the 2nd root folder in preferences2. I added it and started Synchronize at 10:14am. I will report back after Synchronize finishes.
(PS- I upgraded to 5.2.10-x64 yesterday afternoon, from 5.2.9.)
Support Staff 12 Posted by hendrik on 02 Aug, 2020 03:34 PM
Hey Richard,
I finally took a longer look at those logs from 2020-07-07 20:39 and it turns out that beaTunes deleted data for a ton of tracks—almost 300,000. Perhaps those were the tracks residing in
D:\MuDl? Removal of the tracks from the database took some time, but what took most of the time was deleting all the audio-fingerprints from the database. When done in an orderly fashion that's just a lot of updates involving a lot of housekeeping.After you re-added the
D:\MuDlfolder and finished the initial synchronization (importing metadata for—I assume—300,000 tracks), how long does synchronization take now (roughly)?Cheers,
-hendrik
Support Staff 13 Posted by hendrik on 03 Aug, 2020 02:35 PM
If you are testing this again, please consider using the current version (v5.2.11).
Thanks!
14 Posted by Richard on 06 Aug, 2020 05:24 AM
Yes, MuDl is right around 300,000 tracks.
I have no idea what happened. There's probably no way to know now, and maybe wouldn't matter even if I did. I won't worry about it unless it happens again. In the meantime I made a fresh backup of the h2.db file.
I'm happy to report that Synchronization is back to approximately its old performance levels. It took about 10 minutes to add 758 tracks spread over 80-ish CDs that I recently ripped in flac format. That's a reasonable amount of time. I think it runs quicker if fewer tracks are being added or updated. So I'm comfortable again in running Synchronize. And I did upgrade to 5.2.11.
I'm still not crazy about the inetcache being so large, ALTHOUGH it has shrunk somewhat. Down to 6.1GB and 379,257 files (down from 7.0GB and 724,994 files). Does this cache eventually clean itself up if the cache items become old enough?
Support Staff 15 Posted by hendrik on 06 Aug, 2020 05:40 AM
No it does not. Feel free to delete the whole folder, when beaTunes is not running, to clear some disk space. Whatever is in there is cached, i.e., you should be able to load it again, when needed.
16 Posted by Richard on 06 Aug, 2020 03:59 PM
tyvm. It's good to know I can delete it when I need to, when beaTunes is not running.
I'm ready to have this tread closed. Thanks again!
Richard closed this discussion on 06 Aug, 2020 05:33 PM.
hendrik re-opened this discussion on 06 Aug, 2020 05:37 PM
Support Staff 17 Posted by hendrik on 06 Aug, 2020 05:37 PM
It looks like I have to correct myself. The cache is cleared every time beaTunes is closed. Older entries are purged.
18 Posted by Richard on 06 Aug, 2020 05:56 PM
Thanks for the update. I did wonder because I saw differences in that folder over time: Users//App Data/Local/tagtraum industries/beaTunes/caches/inetcache
At the moment, with beaTunes 5.2.12 open, the size of inetcache is 5.0GB with 271,944 items, including 270,612 files. After I close beaTunes, the inetcache is 4.4GB, 215,320 items including 213,988 files. So it's definitely doing some housekeeping, and going in the "right" direction!
I'll let beaTunes do its thing and not let this be a concern anymore. It was probably a side effect of my extreme library activities over the past month or so, which have now returned to maintenance levels.
Richard closed this discussion on 06 Aug, 2020 05:56 PM.