View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0019175 | MMW 5 | Main Panel | public | 2022-06-14 19:13 | 2023-10-06 02:35 |
| Reporter | zvezdan | Assigned To | |||
| Priority | high | Severity | minor | Reproducibility | always |
| Status | assigned | Resolution | open | ||
| Product Version | 5.0 | ||||
| Target Version | 5.1.1 | ||||
| Summary | 0019175: All sub-nodes in collections should have Unknown node (Genres, Artists,...) | ||||
| Description | All nodes in MM2-4 had Unknown node, including Genres, Artists, Albums and so on. In MM5 only Years and Rating have Unknown node, others are moved to the Files to Edit. There are use cases when these Unknown nodes are needed within their related parents. Heck, even my Magic Nodes had configurable such Unknown nodes for any possible case. At least make that optional. You could show them in italic, or something like that, to differentiate them from other nodes having entered metadata. | ||||
| Additional Information | Ticket 4971 | ||||
| Tags | No tags attached. | ||||
| Fixed in build | |||||
|
|
I don't think that Albums > Unkown node is necessary, the same node already exists under 'Files To edit > Unknown Album', so it would be just a duplicate. The same goes for other nodes like 'Unkown Artist', 'Uknown Composer' etc. that are all available under 'Files to Edit' If someone is missing the 'Unknown' node directly under Music > Albums then it can be easily added by an addon (rather than the default feature) IMO. Assigned to Rusty to review/decide. |
|
|
Yes, I am aware about Files to Edit, as I wrote in Description. I didn't suggest that you duplicate Unknown nodes, but to move them back. Or, to make that choice optional at least, so that users could choose where they want them located. It is funny that you are bringing the "duplicate" word as an excuse to not add them where they were before, but, at the same time, you are fine with all those Audio CD drives and Devices located both under the Folders node and at the root of the tree. These Unknown nodes were located under their corresponding parents for 20 years in the old program and you was perfectly happy with them there, and you didn't think to move them for all that time. And I don't remember that any user complained about their old position in the Forum either. But now, suddenly, you moved them just because you wanted something visually new, to make the new version of program distinct from the old one. In that process you made many things worse and many users are complaining about such choices in Forum. Just look at the number of requests in the Forum for e.g. the All nodes. In my opinion, there is no real reason why these Unknown nodes should be under Files to Edit. If I have a lot of files that don't have entered Album info, that doesn't mean that these files should be "edited". Maybe these files are from singles of whatever other reason is that they don't belong to any album. Or, if I don't have entered Publisher or Conductor or Composer, that doesn't mean that these files need to be "edited". Your new design is also less consistent. Why Years and Ratings still have these Unknown nodes? Files in these nodes could be "edited" as well, right? Now, when I think more about it, I am not sure that the "Files to Edit" name was the best choice at first place, since it suggests that other files don't need to/shouldn't be "edited". As I said, it would be best if you just add one new option for users to choose. If you don't want to bother adding new options to the Options dialog box, which also would require involvement of translators, you could just add one new option to the persistent.json and allow users to make that choice by editing that file. I have many options in my add-ons that are available only in such way. There are many programs that have similar approach, exposing only the most important options in GUI and others in the hidden settings, e.g. Firefox (about:config) or Chrome (chrome:flags). It is not user-friendly as options that are visually represented in GUI, but it is still better than not having them at all. |
|
|
I haven't seen users complaining about this particular issue. But I don't see much of a downside to this if the Uknown nodes can't be misinterpreted. The cleanest approach might be for such nodes to appear as the last one in the list with the name "" (i.e. blank), except in the case of rating. |
|
|
>> The cleanest approach might be for such nodes to appear as the last one in the list with the name "" (i.e. blank), except in the case of rating. << I think that leaving a blank node at the end of list looks rather strange (or as a bug)? I haven't seen much complaints about missing "Unknown" nodes (correct me if I am wrong) so I would just left them under 'Files to edit' Assigned back to Rusty to re-evaluate... |
|
|
As I said, such files are not always needed to be "edited", for one or another reason. Here is another question of consistency. When you click on the Albums node, you will get all files in the library displayed in the filelist, including these files with empty Album name, although you don't have the corresponding node in that branch. Why is that? If you don't have Unknown node in the Albums branch, you should not have displayed files with empty album names in the filelist when you click on the Albums node. The same is happening with all other nodes from collections, including Artists and so on. And here is one example why I would need such nodes. I have one old add-on that could export all sub-nodes of any selected node, including Artists, Albums and other nodes from the Entire Library or other collections. So, if I want to export nodes from the Albums branch, I expect to get exported playlist file for "unknown" albums as well, not only playlist files for albums having entered names. |
