GNOME Bugzilla – Bug 489861
Wider range of tokens in Preferences - File System Organisation
Last modified: 2020-03-17 08:22:21 UTC
The current list of legal tokens for defining the organisation of my library is: %artist%, %album%, %title%, %track_number%, %track_count%, %track_number_nz% (No prefixed zero), %track_count_nz% (No prefixed zero), %path_sep% (portable directory separator (/)) For certain users (myself included) it isn't possible to reflect how they currently organise their music files. Personally mine is ~/Music/Artist - Year - Album/Track Num - Track Name.mp3 but there is no %year% token in the above list. I would suggest that the list covers all of the metadata fields for a track - Artist, Album, Title, Genre, Track Number, Track Count, Year.
The support for %genre% has been added in bug #492181. So it looks like the only thing missing is %year%. I guess it would be pretty easy to do, using the patch in bug #492181 as a template.
Consolidating ideas from similar bugs: Components to add: * disc_number * disc_count * conductor * composer * grouping Since most of these don't apply to one's entire library (unless all you have are multi-disc albums and/or classical songs), how can they be used? Should we allow specifying one format for classical tracks, one for audio books, one for music, etc? Also, this issue is now tracking whether/how to add a widget the user can enter a custom folder/file pattern into.
*** Bug 570161 has been marked as a duplicate of this bug. ***
*** Bug 566949 has been marked as a duplicate of this bug. ***
*** Bug 579947 has been marked as a duplicate of this bug. ***
(In reply to comment #2) > Since most of these don't apply to one's entire library (unless all you have > are multi-disc albums and/or classical songs), how can they be used? Should we > allow specifying one format for classical tracks, one for audio books, one for > music, etc? Same thing for the "year" component, not all albums have it and some albums (compilations?) may have different year for their tracks. See duplicate bug 579947.
*** Bug 581478 has been marked as a duplicate of this bug. ***
*** Bug 584562 has been marked as a duplicate of this bug. ***
Wouldn't it be better to let the user type in the predefined string, like Amarok does? Amarok allows the following which you can enter freely in a text field: * Album - %album * Album Artist, The or The Album Artist - %albumartist * Artist - %artist * Bitrate - %bitrate * BPM - %bpm * Comment - %comment * Composer - %composer * Directory - %directory * Disc Number - %discnumber * Filename - %filename * File Size - %filesize * File Extension of Source - %filetype * Collection Base Folder - %folder * Genre - %genre * Artist's Initial - %initial * Length - %length * Rating - %rating * Sample Rate - %samplerate * The Album Artist - %thealbumartist * The Artist - %theartist * Title - %title * Track Number - %track * Type - %type * Year - %year Anything surrounded by curly braces is optional and will only be added when applicable. I am not saying all of those should be supported, but it would be nice. Adding some character replacement patterns would also be nice. As a personal example I am using the following presets: Compilation albums: %folder/C/Compilations/%album{/Disc %discnumber}/{%track - }%title.%filetype Regular albums: %folder/%initial/%artist/%year - %album{/Disc %discnumber}/{%track - }%title.%filetype Replacement pattern: [:/,%?] -> removed.
(In reply to comment #9) > Anything surrounded by curly braces is optional and will only be added when > applicable. I really like this idea, it would take care of the problems mentioned in comment #2 and comment #6.
Created attachment 135797 [details] [review] {Optional tokens} and additional tokens This patch implements optional tokens as suggested by Jensen in comment #9. For example this part: "%album%{ (disc %disc_number% of %disc_count%)}" will be converted to: "Some Album (disc X of Y)" if both %disc_number% and %disc_count% are non-empty; and to: "Some Album" if at least one of them is empty. The patch also adds these additional tokens: * disc_number * disc_count * conductor * composer * grouping To test the patch you need to edit these keys using gconf-editor: /apps/banshee-1/library/folder_pattern /apps/banshee-1/library/file_pattern Before changing the patterns, don't forget to backup your media files and the database (it can be found in ~/.config/banshee-1/banshee.db)
*** Bug 586608 has been marked as a duplicate of this bug. ***
*** Bug 587536 has been marked as a duplicate of this bug. ***
Marking the patch as needs-work, I will update it with more unit tests.
*** Bug 591265 has been marked as a duplicate of this bug. ***
Created attachment 140297 [details] [review] fixes + more unit tests
Is it possible to distinguish when the track is in a compilation album or not? For example, if the track is in a compilation album I like to organize it like Album Artist / Album / Track Title - Track Artist.ogg but if it is in a common album, I don't need the Track Artist.
*** Bug 599392 has been marked as a duplicate of this bug. ***
Bulk changing the assignee to banshee-maint@gnome.bugs to make it easier for people to get updated on all banshee bugs by following that address. It's usually quite apparent who is working on a given bug by the comments and/or patches attached.
*** Bug 600463 has been marked as a duplicate of this bug. ***
Review of attachment 140297 [details] [review]: This looks really good Alexander! I somehow missed this patch; brilliant! If you agree with the below advice, do it, if not, commit as is. Thanks! ::: src/Core/Banshee.Core/Banshee.Base/FileNamePattern.cs @@ +279,3 @@ + var sub_pattern = match.Groups[1].Value; + foreach (var conversion in PatternConversions) { + var token = "%" + conversion.Token + "%"; Can we cache these "%" + conversion.Token + "%" strings in the conversion itself, maybe in a conversion.TokenString or similar property?
Thanks Gabriel, I committed the patch with the optimisation you mentioned. I'm not closing the bug because the following issues still need to be addressed: 1. Are we going to allow editing the custom file system organisation strings from the user interface? Currently it's only possible via GConf. 2. Should we update the existing pre-sets to use the new {optional} tokens? For example: "%album_artist%%path_sep%%album% (%year%)" could become "%album_artist%%path_sep%%album%{ (%year%)}" because not all albums have a year set (see bug 579947 and bug 587536). Similarly, we should replace "%track_number%. xxx" with "{%track_number%. }xxx" (see bug 587536). Also, we should probably append "{%path_sep%Disk %disk_number%}" to most default schemes to fix duplicate bug 584562 and bug 586608. 3. If we do the previous item, we probably want to migrate existing preferences. 4. A few people asked for an alternate naming scheme for compilation releases. Others want another scheme for albums with non-empty composer tag. May be we should generalise and include some kind of an IF token, for example: {{%composer%,composer scheme here,regular scheme here}} I don't want to re-invent the wheel here, if other players do it in a different way, we could borrow their design.
*** Bug 563403 has been marked as a duplicate of this bug. ***
(In reply to comment #22) > 4. A few people asked for an alternate naming scheme for compilation releases. > Others want another scheme for albums with non-empty composer tag. May be we > should generalise and include some kind of an IF token, for example: > > {{%composer%,composer scheme here,regular scheme here}} > > I don't want to re-invent the wheel here, if other players do it in a > different way, we could borrow their design. I love the way Picard does it. You can write your scheme in a textfield in Preferences, and there are two fields, one for usual discs and other for compilations.
(In reply to comment #22) > 1. Are we going to allow editing the custom file system organisation strings > from the user interface? I hope so! It would be nice to have a "Custom scheme..." entry at the bottom of the predefined list which would just open a small window with a text entry and a small description and listing of possible tokens (maybe clickable?) on the top (see easytag's filename editor for example). Now someone may shout "but this is not user friendly". I would say, it is. Compare a nice window like that to the gconf editor: ugh. Real life use case: I could easily tell my girlfriend to use "Custom scheme..." and then build her won scheme there but pointing her to gconf is a no-go. Also, most users don't know or don't care about gconf (or are not willing/capable of asking on IRC etc), so if the option is not listed in the GUI "it dors not exist".
*** Bug 608678 has been marked as a duplicate of this bug. ***
*** Bug 613108 has been marked as a duplicate of this bug. ***
*** Bug 613347 has been marked as a duplicate of this bug. ***
*** Bug 615153 has been marked as a duplicate of this bug. ***
For reference: While this bug report was originally an enhancement request, the last 4 duplicates are all related to Banshee creating invisible files on devices if no track number is set. This "sub-issue" is definitely a bug, and it would be fixed by item #2 of Alexander's Comment #22. Specifically, Banshee should use the {optional} token for the Track Number field, especially when adding files to devices. I'm updating the Severity to reflect that this issue is no longer just an enhancement.
We can eventually adopt foobar's control flow syntax: http://wiki.hydrogenaudio.org/index.php?title=Foobar2000:Titleformat_Reference
Yes, that's a very powerful syntax and would certainly make power users happy :) It's used on foobar2000 for anything that you could use the tagging information for, like for grouping in the media library tree, for making custom columns for the grid display, for making the strings for the title / status bars, for transcoding output filenames and for file copying / moving / renaming.
*** Bug 628501 has been marked as a duplicate of this bug. ***
*** Bug 629874 has been marked as a duplicate of this bug. ***
Just curious if there's something holding up this bug/rfe for release ? I was a little surprised to see the limited choices banshee offers for the directory/filename layout.
(In reply to comment #35) > Just curious if there's something holding up this bug/rfe for release ? I was a > little surprised to see the limited choices banshee offers for the > directory/filename layout. Nobody has written a patch implementing a good UI for this. Patches welcome.
Created attachment 188332 [details] [review] add GUI for custom file path patterns The attached patch changes the preferences GUI for file path patterns in the MusicLibray and AudioBooksLibrary (and where else it may occur) from a ComboBox to a ComboBoxEntry that allows either choosing a predefined pattern (and optionally editing that) or defining a complete custom pattern. There is no place for descriptions for the values that can be used atm. Also, it looks a bit more technical after choosing the pattern (the pattern is displayed as it may be edited), but the example at the bottom should provide good control. Another, but more complex option would be to add GtkEntries in addition to the ComboBoxes, but that takes much more space and the would preferable to be auto-hiding if no custom option is used.
Created attachment 188340 [details] screenshot of GUI for custom patterns
*** Bug 652891 has been marked as a duplicate of this bug. ***
*** Bug 653374 has been marked as a duplicate of this bug. ***
Review of attachment 188332 [details] [review]: ::: src/Core/Banshee.ThickClient/Banshee.Preferences.Gui/DefaultPreferenceWidgets.cs @@ +219,3 @@ this.source = source; + folder= (PatternComboBoxEntry)a; + file = (PatternComboBoxEntry)b; add a space before = ::: src/Core/Banshee.Widgets/Banshee.Widgets/DictionaryComboBoxEntry.cs @@ +4,3 @@ + * Copyright (C) 2006 Novell, Inc. + * Written by Aaron Bockover <aaron@abock.org> + ****************************************************************************/ Are you an employee of novell? Else remove copyright And put your name as author @@ +110,3 @@ + + Console.WriteLine (val.ToString () + "not found!"); + Remove debug message
Created attachment 197858 [details] [review] add GUI for custom file path patterns incorporated the changes proposed in the review: removed copyright, put correct author, removed debug message, and corrected spacing/code formatting
Review of attachment 197858 [details] [review]: Thanks for the patch Frank, sorry it took so long to review it. Technically, the patch seems fine, I'm just worried about the impacts on the UI : The values for the two preferences now look a bit scary, even if the user hasn't changed the defaults. It'd be better if we could still display the more user-friendly labels. I tried to find a way to do it, but didn't succeed, so maybe you or someone else will have a good idea about this.
(In reply to comment #44) > Review of attachment 197858 [details] [review]: > > Thanks for the patch Frank, sorry it took so long to review it. > > Technically, the patch seems fine, I'm just worried about the impacts on the UI > : > The values for the two preferences now look a bit scary, even if the user > hasn't changed the defaults. It'd be better if we could still display the more > user-friendly labels. > > I tried to find a way to do it, but didn't succeed, so maybe you or someone > else will have a good idea about this. Rather than having a single, editable selection box for each field, add a textfield below each selection box. The selection boxes can be kept as-is, except for the addition of a "Custom" option, which enables the textfield. If the user selects a preset option, the text field is disabled or hidden altogether.
Banshee is not under active development anymore and had its last code changes more than three years ago. Its codebase has been archived. Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect reality. Please feel free to reopen this ticket (or rather transfer the project to GNOME Gitlab, as GNOME Bugzilla is being shut down) if anyone takes the responsibility for active development again. See https://gitlab.gnome.org/Infrastructure/Infrastructure/issues/264 for more info.