I have found a small bug in roonalbumtag, or perhaps in scan interactions with roonabumtag. I’ve been using roonalbumtag for over a year (in the same fashion) without seeing this behavior, so perhaps its related to software version. My Rock on NUC is rock 1.0 build 254, and my roon server is 2.0 build 1223.
This may rank as a minor bug, but it seems to be new and may have ramifications for the roon database.
I use roonalbumtag to maintain my personal album ratings. For example ROONALBUMTAG: rating = 7. I use a metadata editor (mp3tag) for this. When I first import an album, I set ROONALBUMTAG to unrated. When I rate the album, I use mp3tag to change ROONALBUMTAG from unrated to a numerical value, 1 to 10. I then use albums/edit to rescan the album so roon picks up the change to ROONALBUMTAG. I have done this without issue AFAIK over 5000 times.
Today I changed 2 albums from ROONALBUMTAG = unrated to ROONALBUMTAG = 7 for one album and 8 for the other. When I rescanned, I picked up the new value, but roon now displays both “unrated” and “rating = 7” or “rating = 8” for the value of ROONALBUMTAG. (I changed a number of other albums at the same time without this resultant behavior). I checked in mp3tag, and both albums show only “rating = 7” or “rating = 8” for ROONALBUMTAG. I cross-checked, and foobar 2000 also shows the correct value only for ROONALBUMTAG. So it appears that occasionally, at least with recent roon software, the old value was not deleted from the roon database.
A minor issue perhaps. Editorializing as a former software architect, database issues should always be taken seriously…
thanks, good to know. I have literally applied ROONALBUMTAG to thousands of albums, and only seen this on the 2 occasions I documented, both in one session of updating data, while other albums updated in the same session deleted the stale tag fine. Sounds like a low probability race condition or something.
I confess to not completely following your previous issues, but it certainly sounds related. Thanks.
I’ve learned not to expect much from roon support. The product itself is great, and I’ve voted with my wallet (lifetime subscription). I’ve been doing digital music systems, originally home built, since about 1990, and have tried probably 30 applications over the years. There are some great options for small to medium music collections, but roon is the only database oriented app I have experienced that doesn’t keel over with a large collection. The roon user interface is also very well done IMO.
that said, this experience has shaken my confidence. I initially thought I was being a good citizen and reporting a minor database bug. Your experience tells me it might not be so isolated, and a new test I just did worries me about data integrity. Initially, for 2 albums I recently rated, ROONALBUM tag did not delete the old tag value when I changed it (my initial post). As I mentioned, this is the same process I had used previously for 5000 albums without seeing this error.
Today, I took one of those 2 albums with stale tags, removed it from my library (moved it out of my music library directory from the linux fileserver side), and then did a forced rescan of my library from roon. The whole album is no longer in the filesystem, yet after rescan roon still showed it (of course, playback failed since the album wasn’t there). I then rebooted the server, checked that the album no longer showed up, moved it back into my library, and did yet another forced rescan. The album now shows up and the bogus stale value in ROONALBUMTAG was gone.
Back in the day when I managed software teams, I would have tasked a senior engineer to look at this sort of data integrity bug. I also think its highly inefficient to not have a white paper explaining what different flavors of scan do. Clearly a forced rescan and a scan on restart have different scope. (I have asked for an explanation of roon scan operation previously for multiple reasons. If users understand how things are supposed to work, there would be less noise and confusion in this forum, and we could use the system more intelligently.).
Yeah, there’s a bit going on in that thread. The main thing that I thought related to your issue is the inability to remove a ROONTRACKTAG (I assume ROONALBUMTAG works the same) that no longer exists in a music file.
It’s been some time since I tried to address this issue, so I don’t remember if I tried what you did. I’ll have to read through my thread again to see what I tried. If I didn’t try what you did, I may try it with one or two albums (in my case, every one if my classical titles is affected!) and see what happens. However, even if that does work, it would be a major pain to isolate every album affected, delete them from Roon, then reimport them all. I’m guessing I may also lose any other Roon edits I may have done on them, in which case it simply would not be worth the effort since in my case this issue amounts to a “cosmetic“ problem.
Some time ago I gave up trying to understand Roon behavior and just go with the flow. Fortunately, it reliably does most of what I want it to do.
BTW, as a somewhat frivolous aside, a central concept in mission critical databases is atomic transactions. A transaction should either complete successfully or leave the system untouched. a failed transaction should cause roll back to a previous consistent state. In my example, ROONALBUMTAG wrote the new value (‘rating = 8’), but failed to delete the old value (‘unrated’), so the update transaction was non-atomic. ‘atomicity’ and rollback are used to guarantee consistency in critical databases. The consequences in this case of atomicity violation are not of major significance, but non-atomic transactions elsewhere might be more serious. Thats why I would recommend a root cause analysis.
Today I was correcting meta data on a classical album that I added (from a disc rip) some time ago. This album was one affected by the “bogus/non existent” ROONTRACKTAG. I decided to do what you did on this album and sure enough, the bogus/non existent ROONTRACKTAG no longer shows (I didn’t have to reboot Roon like you did).
So, deleting and re-adding affected albums should work to clean up my bogus ROONTRACKTAGS. However, I have about 140 affected albums, so it would be a pain to locate all the files and delete/re-add them. That’s not a project I’d like to take on at this time, especially since I already implemented a successful workaround when this issue popped up for me (maybe someday I’ll tackle it).
PS - I found two albums that only listed the bogus ROONTRACKTAG. I pulled up the files and corrected the tag using Mp3tag, without going through the delete/re-add procedure. Roon correctly removed the bogus tag and added the corrected tag.