It's not expected and it is a bug.

Album databases are folder based. The Create Database Utility is run through the batch processor which is also folder based so all works as you'd expect. The UI based Create Database function is also doing it correctly ... so t some point I actually though this out correctly.

The issue is that the Update Database functionality is working on albums which is causing the problem. It has to work on folders. I'll have a look at the code today and see if I can get it squeezed into v8.0.2 which is coming out this week.

This bug has been in for about 10 years. The reason it didn't rear its head is that nowadays many people do not keep separate disc folders. Many of today's popular players do much better when an album does not cross multiple folders.

Good catch.

I'm looking into making this work a little better. Unfortunately it will always be fraught with issues. Track databases have entries which are always unique. A track is a row and a row is a track. The main intent of the Yate Track Id was initially to enable tracks in a db to be recovered if they were moved in the file system. This is used for example by the m3u Suite to update m3u files after their referenced tracks are relocated.

Album databases are tricker. An album can be split over different folders (ie. by disc). If the tracks in a release span different folders and yet they all have the same Album name it becomes somewhat unwieldy. Album IDs are shared across the entire album and yet any Album db row is always associated with a single folder. When there are multiple folders associated with a single album the detection falls apart. Album Ids must be unique for an entire album as it is entirely possible to have multiple instances of the same album (different release dates or encoding, etc).

Multiple folders for a single album also falls apart if you move a track from one disc (folder) to another. There is no way to catch this unless the album names are unique per folder. This is distasteful.

The best I can accomplish is that the update for your scenario will work as long as the Album name is not changed and the folder remains the same. This is non issue for an album contained in a single folder. If these rules are broken, you will more than likely get new rows in the db and the older rows will remain. This is already possible in a few scenarios. If you are going to change the Album metadata or move the folder, you should remove the database rows first. Directly or via File>Database Functions>Remove from Databases. Again this is not necessary for albums in a single folder.

I've tested this fix and it seems to work fine. Let me know if it all makes sense.

This entirely goes away if the tracks in a multi disc set are kept in the same folder. That's what the Disc field is for 🙂

Hi Barry, me again!
I tested the update and I'm still getting the same result as described in my initial post.
I'm curious as to how you get a different result.
It's honestly not a big deal. I will eventually flatten my library...
--
Andy

The following will help.

Load up all the tracks (all discs) in one album.

Install the Dump Metadata action. You can do it via the action installer (on the Yate) menu, or by locating it on the resources web page.

Run the action with all loaded files selected. Send the produced zip file to support@2manyrobots.com

I have an action which produces audio files with the same name, file structure and metadata as the files. Everything is there except the audio. I will be able to produce a database and test with the produced files.

Hi, and thank you for the prompt replies again.

OK, before doing a metadata dump, I did a bit more testing and I think I've worked out what's going on. I've read and re-read your detailed explanations above and I understand (I think!) the differences between "folder based" and "album based" processing in Yate.
I'll leave you be the judge as to what is normal behaviour in the scenarios below.

Setting the scene:
Given an album with 2 discs where each disc is in its own folder and the Album fields are the same for all tracks and no Yate Album ID is saved in tags.

-----
Test I
With all the album tracks selected, if I Actions > Yate Database IDs… > • Set if missing • Both, I get 1 unique Yate Album ID for all the tracks.
The same occurs when I run my home cooked action that I use to rename folders and files when adding to my library. This action contains the Set Yate Album ID and Yate Track ID if missing function, and all tracks within the album get the same unique Yate Album ID.

If I then add that album via File > Database Functions > Update Databases, only disc 1 appears in the Album database.
-----

Now, I remove that album from the Album database, and delete the Yate Album ID from the tracks' tags for the next test.

-----
Test II
If I run the Create Database Utility action with the Create Yate Album IDs if missing option on the source folder of my library, that same album gets listed on 2 rows (Disc Combined > 1 of 2, 2 of 2) in the Album database AND each disc gets its own unique Yate Album ID, so 2 different Yate Album IDs for the album.
-----
Test III
Same as Test I, but I then run the Create Database Utility action and now the album gets listed on 2 rows (Disc Combined > 1 of 2, 2 of 2) but with the 1 unique Yate Album ID for all tracks.
-----

This is why it has taken me this long to come across this issue. Having had a big tidy up of my music library a few months ago, clearing out all the Yate Album and Track IDs, all my multi-discs albums now have multiple Yate Album IDs from building a fresh Album database via the Create Database Utility action. It's only when I recently added a new multi-discs album to my library (via my home cooked action) that the issue revealed itself.

As I said before, it's not really a big deal… I'm just like a dog on a bone when I come across these kind of things and I like to understand how stuff works!

Let me know if you still need the metadata dump, or if my ramblings are enough to go on.
--
Andy