GNOME Bugzilla – Bug 645737
Songs without track numbers end up as hidden files on device; are not recognised
Last modified: 2011-03-26 18:48:14 UTC
I recently started synchronizing my new Cowon J3 with Banshee, and noticed that about 2000 of my songs were not showing up in the device's total. They were similarly omitted from any playlists containing them. Looking at the playlist, entry, I realized that the filenames all started with periods, and the player must be based on some unix-like OS, as it was treating them as hidden. Here are some example playlist entries: \Music\OverClocked ReMix\Castlevania OC Remix\. Wickedest Child.mp3 \Music\C418\Minecraft\. calm1.ogg \Music\Kazumi Totaka\Mario Paint\. Ambience.ogg The mass storage support should be naming these files using the same rule as the desktop file organization and omitting the period when no track number is present.
Files transferred to a mass storage device should already follow the same rules as on the desktop, if there are no specific limitations on the folder depth for that device. To confirm that, please check whether your device contains a ".is_audio_player" in its top-level, and if it contains a "folder_depth" parameter. If yes, removing it should do the trick. Please also check that the file naming rules you have selected really omits the period. You can look at the value of the "/apps/banshee-1/library/file_pattern" key in the GNOME Configuration Editor, it should be : {%track_number%. }%title%
Thanks for the tip. It turns out that my file_pattern was somehow set to: "%track_number%. %title%". I re-selected the "other" choice for Track Number. Title in the preferences and it now shows up as: {%track_number%. }%title% I know I never manually edited my config, so I guess one version of Banshee somehow mangled this on me (I'm on the daily build PPA).
It was the same for me. When we added the new rule for the optional track number, we replaced the existing pattern, and it was set as the default value for file_pattern. But this only applies for new users, it doesn't overwrite any existing value. So I'm marking this as invalid. Thank you for your report, and feel free to report any other bug you find.
This was actually a dupe of bug #634096 *** This bug has been marked as a duplicate of bug 634096 ***