Strange behaviour of library when adding album from Qobuz

Roon Software Discussion
1

Hi there,

The way I often use Roon to add (new) is through the “new releases for you” screen. On there I see all the recent Qobuz album. I then click on an album, and start playing it. The screen ( for a non library album) shows which song is playing, even if I go forward or back on the album. So far all good.

The problem arises when I then decide to add the album to my library. When I click on the “+” the album screen changes to the screen for an album that is included in the library. I can now like songs, the album, edit the album data, add the album to a tag, etc. Normal behaviour. But the song playing, is no longer highlighted, even though it is still playing.

If you check the new release screen, that album is no longer visible (normal behaviour).

But the behaviour becomes very strange strange when I use the queue to get back to the playing (and newly added) album: then the “non library” version of the album screen is shown, without any changes made (eg without the added tag). However, through the main menu and the Album screen, I see the album as added to the library. Click on that album, and you get the “in library” screen with all changes made (eg included the added tag).

I find this behaviour VERY CONFUSING, and am tempted to call it a bug. It trips me up every time, I try to add the album again. Which seems to confuse the UI.

Where do I go from here to report this to development?

Kr,
Jan Stes.

2 Likes
2

I would have to agree. Not a great experience. In principle you need to raise a change request.

You may have more luck if your change request is specific and “actionable” from a development perspective rather than a more general request to improve usability.

3

See:

4

I have voted for that long ago, hope that this gets more votes, has now 30 votes…

I started to work the other way, adding an album to library before I listen it, then deleting it from library if I dont want to keep it.

5

The challenge is that there is no perfect way for roon to do this. The library version is considered separate from what you started playing from Qobuz. That is why when you go to the queue, you still see the Qobuz track playing, because that is what you played, but Roon does not consider that the same as the version that is now in your library.

6

That is exactly why I consider this a bug, an error, a fault. To me as a user, those 2 tracks are the same object. Any use case should ensure that those 2 objects are equated. There are plenty of advanced programming techniques avaible to implement this. One can only hope that the differentiation is not engrained in the SW architecture of the system.

7

That is a nice workaround. To bad it may be the only available (non-)solution.

8

Roon marches to a different drum - it makes a distinction between objects that are inside or outside of your library.

9

Still an very important bug: once the album is added to the library, the object outside the library no longer has a right to exist.

More importantly, that drum is a major architectural and design fault: when an attribute of an object changes (the library) that should not change the identify of the instance of the object. Basic OO rules.

But I know that Roon has a very poor history in recognising those faults, let alone correcting them.

1 Like
10

That’s at least debatable

11

Why? Which sense does it make, that e.g. the exactly same title from Qobuz has an inside and outside library existence?

12

Think of the analogy of an album that exists in the form of CDs and Vinyl - it is exactly the same title, but it exists as thousands (millions) of objects. So an album can exist as an object that can be streamed via a streaming service, but also as an object that exists in the Roon library. And as the article I referred to states, the object in the Roon library can have attributes applied to it that are unique to that object.

13

Because you might change the in-library object with, e.g., a different album cover or edited credits and other metadata, and then it’s not actually the “the exactly same title” anymore.

Maybe such edits should create a new top-level object with different versions below it (the original and the edited one), but I agree with Roon that one should have the option to still see the original. (And maybe keeping the original separate is less messy with larger edits you could also make. E.g., you might merge a single local track into the in-library copy of the Qobuz album).

That’s not to say that the in-library / not-library dichotomy doesn’t create its own problems, much of it discussed in the thread that @BlackJack linked further up (and the other threads linked from there), but I believe it’s a hard problem.

14

ok, for the debate:)

If I edit a local hard drive version, how could I see how it looked before? And why should I? To show someone how nice I made it?
I never will make any edits to a streaming version anymore, as we know, all that work will be lost, when the streaming service is just changing the catalogue number or such. The possibility to have a look how it was before editing does in no way compensate for that in and out library quirks.

15

Maybe there should be a way to do this, too. Currently, if you edit metadata of a local album, Roon will stop updating these properties from its metadata sources. It might be nicer if you could still see the metadata that Roon has - it might change over time and some properties might get improved. (Like, maybe you entered the wrong recording dates).

So, this seems actually a strengthening of the reason to retain access to the unaltered copy that Roon imports from the streaming service (plus Roon’s metadata sources).

Although I’d agree that this can be better represented than having a separate copy.

That’s true but is a separate problem. One could conceive of ways for Roon to retain edits in this case, and it very much should. (The current marketing claim that you can edit metadata of streaming albums is indeed quite leaky if those edits can disappear at any time).

E.g., certain metadata could be applied to a virtual parent object, rather than specific versions. Then they would remain available even if the specific version changes. This would make sense anyway, apart from the current discussion, because certain data (like performers) are arguably applicable to the parent, and should be available for every version. We shouldn’t have to redo all edits for a new version just because a new remastered version becomes available, for instance. (Although there would still be a need to have version-specific data because some, e.g., remastering credits, are version-specific).

In a less fancy way, the user could be given the option to simply copy metadata (at least own edits) from one version to another. This would have other uses as well, e.g., copying musicians edits from one album by a given band to a new album they release. I made some posts about this in various relevant Feedback > Feature Suggestions topics.

It doesn’t, but it’s also not the fundamental cause and not an argument against it. The library / not-library problem can only be solved on a much deeper level, which would most likely fix both problems.

The real problem ist most likely, I think, that Roon’s database features (like Focus) can only be applied to a subset of all existing albums, i.e., those in the library, because the whole Qobuz catalog database doesn’t fit into home servers, nor are they able to efficiently run detailed queries on it. It would be very cool if Roon could run the whole database in a cloud instance and you could run Focus queries against everything.

16

I agree to all that, what you mention for the in and out library versions making sense. But all that is not given. If that all is ever realized, only then this in and out library „feature“ can be considered to be implemented, if the mayority would ask for it, i believe not.

Until then I agree with Jan, its a logical failure in design, we could ask Spock.:wink:

1 Like
17

In a way, maybe. Roon originally had only local files, there was no streaming integration, so the whole thing was not an issue. Then they added streaming, but you can’t put a 100 million tracks database into people’s NUCs. Thus, the idea was born that you may consider the streaming services like a record shop, where you pick albums and take them home to add them to your personal library.

Maybe at this point one could have done a complete redesign instead, and maybe there could have been a more elegant solution for the fundamental problem than the one we have now. So, in this sense it may reasonably be seen as a design flaw.

However, I maintain that the fundamental issue is in the necessary split between personal, local library and streaming service content one way or another. And that was not fundamentally solvable at the time (the cloud and people’s internet connections were far from the necessary level) and IMHO still are not (cf. the uproar when Roon tried to require an always-online Roon server). Refer to this post detailing what’s necessary to just run a full text search on the streaming service databases:

In the future, if everyone has really always-on internet, running each user’s personal database in the cloud would bring immense advantages, such as simplification for users and the ability to scale up immense resources to run a Focus query on all of Qobuz/Tidal. And Roon has expressed an interest in this when it becomes possible. Until then, we’ll have to live with some compromises.

18

Great discussion but still the choices made by Roon on how to handle the particular problem in this post, goes against all SW design rules: look at the situation from the user’s perspective (use case), not from the developer’s perspective.

When you start to listen to a non-library album and then add the album to you library (creating a library album), your session should from then on exclusively refer to the library album. Why? Because adding the album to your library is like buying the album and taking it home. So as a user, from then on, you expect to deal with YOUR copy (the library album).

If you then want to deal with a generic (non-library) instance, you need to go back to the shop. In Roon terms: go to the Qobuz screen and navigate to the relevant (generic) album. That is implemented correctly: you are shown the non-library album. It may be a nice suggestion to include a warning on that screen that you “own a copy”, and give the user the possibility to easily switch to his library copy.

The choice to keep listening to the non-library album at the moment of adding the album to your library, leads to inconsistent and unexpected behaviour (from the user point of view), and is therefor a bug, a fault, an error.

Making an error is nothing bad. Can happen to everybody. Denying it, refusing to recognise it, and persisting the behaviour, that is another matter.

2 Likes
19

I don’t disagree.