OK, so as suggested, I uninstalled the system all the way and did a clean install.
I have been using the Merge facility to combine separate albums in a multi-disc set (rather than the way I was doing it previously), and this has largely worked - until now.
However, earlier today I combined the two discs of Rogue’s Gallery: Pirate Ballads etc into one entry, successfully. Just now I was combining the discs in Beatles Anthology 3 and it accepted the merge with no queries. However the Anthology 3 entry then disappeared and by searching for individual tracks found all its entries have been stuff into Rogue’s Gallery.
This is the start of a slippery slope, if last time’s experiences are anything to go by, so I’ve stopped.
What I need now is the following:
Instructions for UNDOING what the system just did, ie reverting to the previously correct Rogue’s Gallery and the Anthology 3 as two discs.
Instructions on how to merge multi-disc sets that don’t throw the tracks somewhere else.
I am presuming that this is a bug: I see no reason why this should happen wherever the two component albums may have been stored.
Please let me know if there are any ways to resolve this.
I have experienced this also. It is an insidious bug because it doesn’t happen all the time, and so is difficult to replicate, which is the first step in squashing a bug. This is under active investigation by Roon devs, but it is proving to be a difficult one to reproduce.
I found that it was fruitless to try fixing the botched merger. I had to delete the affected albums (both the source and target) from the file system and re-rip them. So far as prevention goes I found that if I closed Roon down between merging albums then the bug didn’t appear. That could have been just chance, I have only merged about five or six albums after the bug hit me.
I would also recommend backing up the database prior to attempting a merge. That way, if the bug does hit, you can revert to the saved database prior to a botched merge.
It may be that @mike has some better suggestions, but the above was what I experienced.
I do not see conceptually why there should be any way that the information for one album should be capable of being written to another more or less at random.
I am not in a position where I can happily replace items in my library - it’s used by two other systems, and anyway all the original CDs are in boxes packed away, AND some of them are downloads where the concept of re-ripping is not available. Roon claims to leave the original library files alone and this must remain the case or it’s no use to me. In addition I have previously failed to remove a corrupted album from the database - as soon as I add the source files back the faulty assignments return. In the case of a downloaded album I would not have a sensible means of altering the files so they didn’t appear the same as the old ones - I can’t deliberately corrupt the file metadata (and my other systems that rely on it) to fix a problem that is actually due to a separate database getting its records cross-linked. The problem is the crosslinking, not my source files: it should simply not be able to write to arbitrary other records. That is surely a pointer gone astray or something.
As far as I can see the problem is solely in Roon’s database and not my original source files - even if some of them are in sub-optimal structures such as the two discs of a two-disc set being in two adjacent folders. Whatever my source structure is I can imagine that perhaps making it harder for me to find tracks to merge, but once I’ve found them it should be fine.
The fundamental issue is that Roon must not write arbitrarily to other album records. If I give myself trouble due to source track locations that’s my problem, it does not explain why Roon is corrupting the records of other albums when I edit one.
As far as difficult to replicate is concerned… I have deleted and re-installed Roon from scratch three times now and I can tell you, it is 100% replicable - just merge half a dozen or so albums and it will start doing it. There have to be several previously-merged/edited/identified albums before it starts doing it, but merge albums enough and it’ll happen without fail. Following yesterday’s experiences I deleted everything once again and started from scratch once again. I am not messing with the database until there’s a testable fix for this issue and I will be pleased to beta-test such a fix and help get it working.
I agree completely with you that this shouldn’t be happening. It is something that needs to be fixed as soon as possible.
My experience was with an organised folder which meant my file structure was corrupted as well as the albums in the database. If this happened to you in a watched folder then the underlying file structure ought not to have been affected. In that case it may be enough to copy the files of the target and source to a folder outside Roon, delete the albums in Roon, and then re-import the files into a watched folder. I haven’t tried that myself so can’t tell you that it will definitely work, it may be that the database retains some memory of the files. Have names or tags on your underlying files been changed ?
The devs are aware of this bug and @vova is bashing away on it at the moment. As you say, I would expect that repeated merging of multi-disc albums initially separated by different folders ought to result in the merge bug appearing at some stage.
As soon as I hear any news on a solution which I am able to pass on I will post again in this thread. The conjunction of New Year and CES has interfered a little with Roon’s usual attentive Support but I expect you will hear further directly from the devs as soon as possible.
Today, I entered the disks from the Bruce Springsteen box set “The Ties That Bind: The River Collection.” At first, things whent more or less OK: I ripped all the CDs under the title The Ties That Bind: The River Collection and Roon did what it occasionally does – it identified disk 1 as one edition of the album and disks 2, 3 and 4 as a second edition of the album. Minor problem – it has happened so many times, that it is almost expected behaviour and not worht posting about here. Indeed, I was pleased that Roon didn’t insist that disks 1 and 2 weren’t really “The River” (which in a real way they are). I highlighted both editions and merged them. I was asked to create an album with 52 tracks, which is the correct number of tracks, and one would have thought every thing was fine. That’s where things went wacky. check out this screenshot:
The 88.2kHz versions are not from the album at all, but from Cheap Thrills by Big Brother (whose cover art was then attached. Those tracks had formerly been correctly identified by Roon and had been in the system for some time. Now look at this screenshot:
This is the file info on the first track, and as you can see, the track is really Combination of the Two, and is in the correct artist/album folder. I can’t understand why Roon mixed these up. Corruption of my database maybe? Is there anything I need to do or be worried about?
FYI, I was able to manually remove the Cheap Thrills tracks using Fix Track Grouping, so the only real issue is troubleshooting the misidentification.
I’ve shifted your post in here because it looks like another instance of the merge bug that is under priority investigation at the moment.
I will flag it for @vova, @mike and @ncpl who are all trying to assist in reproducing this behaviour.
After a remote session with Vova over the weekend (where we weren’t able to reproduce it) I fell to thinking about it on a long country drive and there is a detail I would like to check with you, if you don’t mind.
You will recall that after hitting Merge Album you go to the Track Grouping screen where you can fix disk and track numbers. After you do that you “Create Album” and the merger (hopefully) occurs. Sometimes a popup will appear noting that the tracks are different or in a different order and you can “Create Album Anyway”.
Now sometimes after “Create Album Anyway”, instead of being returned to the Album view (or whatever other view you were in) we are presented with the Track Grouping screen again. In our remote session Vova and I were hitting Cancel at that point.
But I have since remembered that when the bug hit me, I was hitting “Create Album” again at that point, because I thought that the merge process had failed or not occurred for some reason.
Is it possible that you were hitting “Create Album” twice in the same way that I was ?
Robert is reporting the identical issue to mine, as far as I can see. I would ask him if he had previously at some point edited Cheap Thrills and I bet this is the case - I only get albums corrupted (by having the tracks of the current album dumped into them) that I have previously edited.
Regarding the issue of potentially clicking “Create Album” twice, I have been sure never to do this. Firstly it seldom appears as an option - in fact, the window generally goes away and the album changes to something wrong in front of my eyes, which sounds like happens to Robert too - and second, if I see the Create Album option a second time I always hit Cancel.
It’s a really tough one to replicate also. I have done tons of edits and merges and only saw this once recently. It fits exactly the description but I cannot fathom the specific scenario.
Suggest we all keep an eye for it and try and document as much as possible. This will give @Brian et al the best chance of finding it.
My hunch is that there is a temp file or cache written somewhere that (for whatever reason) isn’t being flushed when the edit/merge is completed. It then somehow mingles with the next.
The merge album screen doesn’t close cleanly for me. I always click outside the box, so, that is where my hunch comes from FWIW.
I don’t know if my source file organisation is part of the issue. In most cases on my system, a multi-album set will be stored on my system in the form of folders with names like “Artist - Album Name Disc00”. In the notes on album merging it is specifically stated that this type of structure “will almost certainly not work”.
It could be argued that if I persist in using a specifically-deprecated file structure (which I am obliged to do as the files are used by two other systems, and there are rather a lot of them) then that’s my problem, not Roon’s. However, what “will almost certainly not work” is equally likely to refer to Roon not being able to interpret such a structure automatically - that on the other hand I totally accept. I don’t mind doing the work to get my multi-disc sets into order, and certainly conceptually I don’t see why Roon should not be able to let you assemble an album from any collection of tracks you like.
In my case, album corruption is 100% repeatable, and I suspect the following might produce a repeatable demonstration of the issue:
Make a collection of, say, a dozen or more multi-album sets in which each individual disc is in a folder named something like “Artist - Album Name Disc00”
Let Roon discover them - we assume it will create them as separate albums, one disc each
Select a pair (for example) of discs to merge and create a single multi-disc album from them
Repeat until failure
I appreciate that some people who have been getting this problem may have a different source file structure. However, on my system the effect has been 100% repeatable if you merge for a couple of days - say a dozen or so multi-album sets. My structure may not be the only way to demonstrate the effect but it does seem to be particularly prone to it.
In my case I need to have been merging albums for some time before the problem emerges. When it emerges, it will always throw the tracks from the current album into an album I had previously edited - not the previous album, but one from several merges ago.
My suspicion is that if you don’t get this happening, you haven’t edited enough albums yet. I’ve tried this three times now and on each occasion I had been merging discs for a day or so before it started happening. Once it starts happening, it happens on every occasion. And it never throws the tracks into the previous album I had been working on, but one several albums back - generally an album I had merged the previous day.
@brian has managed to drag the merge bug out from under the couch and drive a stake through it’s cold undead heart. Looks like it was an issue arising from restarting a Remote.
A fix has been implemented and should be in the next build (which may or may not be 1.2).
Thanks everyone for your patience and reports. I hope we can mark this thread [Solved]. I know it’s one that @mike has been wanting to clear for a long time. Let’s see what everyone’s experience is when the fix is out.
As per my above post. It will be in the next build released. We haven’t been told whether that will be 1.2 (which will have a longer test cycle) or another bugfix release (which would have a shorter test cycle).
I’ve just spent a frustrating afternoon working with this type of issue.
As I’ve run across albums that are split in Roon (they appear to be fine in the music folder Roon is watching) attempting to merge the albums seems to create huge problems in the database by creating an entirely new monster album that defies correction.
As best I can determine, there is at least one of these monsters in my library and I don’t know how many split albums remain.
A forced rescan doesn’t have any effect on the splits. Merging doesn’t work. These are owned albums on my system so I can’t simply delete the album and restore from Roon and I’m using RoonServer on the same Mac that has the music drive attached to it so access is a pain.
I have 2 questions:
Is this behavior fixed for the next release?
Should I totally uninstall Roon and start over with a fresh database?