GNOME Bugzilla – Bug 167659
Add "Type" and "File Size" (and possibly others) to visible columns and Automatic Playlist editor
Last modified: 2018-05-24 10:41:21 UTC
It would be nice to be able to see what year a particular track is from. In many cases, this information is stored in the ID3 tags of MP3 files (et al). Having the year as a choice in the visible columns display preferences would allow for easier (or, at least, alternate) sorting of albums by artists with long careers. Having the year as a choice in the Automatic Playlist creation would allow for such playlists as "60's music" and "Best of the 70s", etc. iTunes, FYI, allows all the colums which rhythmbox currently offers, plus: Year, Size (of the file), Sample Rate, Play Count, Last Played, Kind, Grouping (typically used with classical music), Equalizer, Disc Number (for multi-disc box sets), Date Modified, Date Added, Composer, Bit Rate and Beats per Minute.
i would like to see the year column introduced as well. it might also be nice to be able to filter songs with the browser by year. This makes it easier to find songs of which you don't remember the title, but you know what year it was from. Plus it would allow "Play all tracks from 1992" and similar.
The patch attached to bug 132566 adds year, playcount, last played, disc number, date added and bitrate as criteria options for automatic playlists. It doesn't add file size or date modified and the others aren't currently available in RB (although some of those would be easy to add).
Isn't this a duplicate of bug 128155? (At least for the columns part)
Urp. Yes, it does overlap with 128155. That bug, however, does not contain the suggestion of using a year as an automatic playlist or the implied suggestion of adding the rest of the columns/options that iTunes allows. Speaking of which, yesterday, iTunes 5.0 came out. One of the added features is lyrics storage support. It looks like (at least sometimes) they lyric info is put into the ID3 tag with a USLT identifier.
At least year in the automatic playlists seems to have been added in CVS. (See comment #2 above).
I've just looked and somehow I actually missed the year property out of the playlist-editor patch I committed. I'll fix that soon
Created attachment 53976 [details] [review] patch This patch adds "Quality" (bitrate) and "Type" as columns, and adds "Type" as a field in the track info window. NOTE: MP3s have type "application/x-id3", which for some reason gnome-vfs doesn't have a description of - hence they get listed with type Unknown.
"Some reason". That'd be because it's not a mime-type, and I don't know anyone using it apart from GStreamer. The proper mime-type for MP3s is audio/mpeg.
Good point. I guess it's because although it's probably audio/mpeg with ID3 tags, it could be something else with ID3 tags.
Created attachment 54760 [details] [review] updated patch updated to apply to cvs
This version patch works with Rhythmbox 0.9.2: http://koti.mbnet.fi/olljanat/rhythmbox/rb-0.9.2-quality_and_type_column.patch.bz2
*** Bug 315361 has been marked as a duplicate of this bug. ***
Created attachment 57448 [details] [review] updated patch Updated to cvs. Makes the type column ellipsizable (since it doesn't have a fixed width) and makes application/x-id3 not show "Unknown".
Works for me against CVS. My only quibble is that for ID3 tagged MP3 it shows: ID3-tagged audio (application/x-id3) so you know it's tagged, but not the actual kind of audio but for non-ID3 tagged MP3s and tagged OGG files you see what you would expect: MP3 audio (audio/mpeg) Ogg Vorbis audio (application/ogg) respectively. Is there anyway this could be switched to MP3s with ID3-tags (application/x-id3) are non-MP3 ID3 tagged audio files (does FLAC use ID3? I don't know). Either way, I'd say commit now, and then sort this out later. It's a nice addition. [Finally there should be a way to use "Type" in the automatic playlists, e.g. an automatic playlist called "All my OGG files". I could work on that after it was committed].
(In reply to comment #14) > Works for me against CVS. My only quibble is that for ID3 tagged MP3 it shows: > > ID3-tagged audio (application/x-id3) > > so you know it's tagged, but not the actual kind of audio A file having the mime-type "application/x-id3" just tells you that it is ID3-tagged, it doesn't indicate what kind of audio it contains. > Ogg Vorbis audio (application/ogg) Now that I think about it, this is odd - since application/ogg doesn't imply it contains Vorbis audio. I don't think that the "type" column is that useful, unless we do deeper typefinding, because most people won't care about the files being ID3-tagged or in a Ogg container. > [Finally there should be a way to use "Type" in the automatic playlists, e.g. > an automatic playlist called "All my OGG files". I could work on that after it > was committed]. I thought we already added that, but it doesn't appear to have been. The basic version would be a one-line addition to rb-query-creator-properties.c, however having a menu to select from would probably be better than marking the user enter the mime-type.
Can the "Quality" column at least be added? I still think the ability to include the "Type" column is still useful, even if imperfect. (Switching patch state, so it is visible from product page.)
Retitling bug, to reflect that Year and other columns are now available in both the list of columns and autoplaylist options.
(In reply to comment #16) > Can the "Quality" column at least be added? I still think the ability to > include the "Type" column is still useful, even if imperfect. (Switching patch > state, so it is visible from product page.) > I definitely agree that type column is a useful. Please do add it! As for the discussion above, I noticed that in nautilus when you check the audio properties tab, it correctly determines the codec. My flac files are id3 and flac tagged with Easytag.
*** Bug 304718 has been marked as a duplicate of this bug. ***
Created attachment 59626 [details] [review] updated patch I've committed the "Quality" column bit to cvs. This patch is the bits for the "Type" column. The reason Nauilus displays the type correctly is that it is using gnome-vfs to determine the mime-type. We're currently doing surface typefinding via gstreamer. Until we have "deep typefinding" in the metadata backend, we could probably switch to using gnome-vfs for mime-type detection too.
Created attachment 60196 [details] [review] patch using gnome-vfs for mime-type detection This patch changes it to use gnome-vfs for mime-type sniffing, so the type names are more meaninful. This can probably be committed if no-one sees issues with it.
Looks fine to me. I think it's good to commit. I did notice I need to re-import songs to see the change from ID3-tagged audio to MP3 audio.
Patch applies to CVS, but fails to build. Needs updating to CVS.
(In reply to comment #23) > Patch applies to CVS, but fails to build. Needs updating to CVS. gcc -DHAVE_CONFIG_H -I. -I. -I.. -DGNOMELOCALEDIR=\"/usr/local//share/locale\" -DG_LOG_DOMAIN=\"Rhythmbox\" -I.. -I../lib -I../lib -I../player -I../metadata -I../rhythmdb -I../sources -I../library -I../iradio -I../shell -DXTHREADS -D_REENTRANT -DXUSE_MTSAFE_API -DORBIT2=1 -pthread -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/X11R6/include -I/usr/include/atk-1.0 -I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/include/freetype2/config -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libgnomeui-2.0 -I/usr/include/libgnome-2.0 -I/usr/include/libgnomecanvas-2.0 -I/usr/include/libart-2.0 -I/usr/include/gconf/2 -I/usr/include/libbonoboui-2.0 -I/usr/include/orbit-2.0 -I/usr/include/libbonobo-2.0 -I/usr/include/gnome-vfs-2.0 -I/usr/lib/gnome-vfs-2.0/include -I/usr/include/bonobo-activation-2.0 -I/usr/include/libxml2 -I/usr/include/libglade-2.0 -I/usr/include/gnome-vfs-module-2.0 -pthread -I/usr/include/gstreamer-0.10 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libxml2 -g -O2 -Wcomment -Wformat -Wnonnull -Wimplicit-int -Wimplicit -Wmain -Wmissing-braces -Wparentheses -Wsequence-point -Wreturn-type -Wswitch -Wtrigraphs -Wunused-function -Wunused-label -Wunused-value -Wchar-subscripts -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wcast-align -Wall -Werror -std=gnu89 -MT rb-entry-view.lo -MD -MP -MF .deps/rb-entry-view.Tpo -c rb-entry-view.c -fPIC -DPIC -o .libs/rb-entry-view.o cc1: warnings being treated as errors rb-entry-view.c:425: warning: 'struct RBEntryViewCellDataFuncData' declared inside parameter list rb-entry-view.c:425: warning: its scope is only this definition or declaration, which is probably not what you want rb-entry-view.c: In function 'rb_entry_view_mime_cell_data_func': rb-entry-view.c:430: error: dereferencing pointer to incomplete type rb-entry-view.c:432: error: dereferencing pointer to incomplete type make[2]: *** [rb-entry-view.lo] Error 1
Created attachment 61216 [details] [review] first attempt at deep typefinding Attempts to find the 'real' stream type by looking at the caps on the sink pad of the decoder element that created decodebin's source pad. This gives us audio/mpeg instead of application/x-id3 for id3 tagged mp3, audio/x-vorbis instead of application/ogg for ogg vorbis, and audio/x-wma instead of video/x-ms-asf for the one wma file I have to test with. It might be considered something of a hack, though.
The only "real" solution I can think of is making decodebin emit a signal for each new pad it decodes (not just the end ones), and have RB use this to collect all the mime-types. This would let us create a list of all mime-types, rather than just a single stream's type. However the way you've done it seems to work well for me, and is probably a lot more practical. Combining this and the above "Type column" patch looks fine to me.
Created attachment 61590 [details] [review] combined patch This combines the last two patches. It works well for me, except for gnome-vfs not having a description of audio/x-vorbis (it calls application/ogg "Ogg Vorbis Audio").
Works for me. Commit away. ;-)
(In reply to comment #26) > The only "real" solution I can think of is making decodebin emit a signal for > each new pad it decodes (not just the end ones), and have RB use this to > collect all the mime-types. This would let us create a list of all mime-types, > rather than just a single stream's type. I think we could just iterate the elements in the bin once it's gone to PAUSED and get a list of the types on the element links, then pick the most interesting one to report as the actual file type.
Is there any reason why this patch has not been committed yet or is it just forgotten?
I suspect it's been forgotten. I would like to see this get in. It probably needs to be updated to latest SVN. Have you tested whether it applies against the SVN HEAD?
I'm working on a proper solution for determining media types that will make most of the hackish parts of this patch unnecessary.
Hi, Since there seems to be no inclusion of this feature into the latest 11.4 release, can I ask for an update on the (hackish) patch so that it can be applied for 11.4? Hope to see the patch with the proper methodology for type finding soon!
(In reply to comment #32) > I'm working on a proper solution for determining media types that will make > most of the hackish parts of this patch unnecessary. Any updates on this? Adjusting summary as Quality is now in both the auto playlist editor and the columns, also add "File Size" as originally requested.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/rhythmbox/issues/54.