Could tumbler add support for generating thumbnailers for rm/rmvb(RealMedia) files ? By simply renaming "whatever.rmvb" to "whatever.avi", i could get a thumbnailer. So could tumbler add some codes to deal with this issue? Thanks in advance.
Can you please post the output of "gvfs-info whatever.rmvb"?
(In reply to comment #1) > Can you please post the output of "gvfs-info whatever.rmvb"? Of course. kernel@fairland:~/tmp$ gvfs-info test.rmvb display name: test.rmvb edit name: test.rmvb name: test.rmvb type: regular size: 10592997 attributes: standard::type: 1 standard::name: test.rmvb standard::display-name: test.rmvb standard::edit-name: test.rmvb standard::copy-name: test.rmvb standard::icon: application-vnd.rn-realmedia, gnome-mime-application-vnd.rn-realmedia, video-x-generic, application-x-generic standard::content-type: application/vnd.rn-realmedia standard::fast-content-type: video/x-msvideo standard::size: 10592997 standard::allocated-size: 10612736 etag::value: 1291888613:0 id::file: l17:59669 id::filesystem: l17 access::can-read: TRUE access::can-write: TRUE access::can-execute: FALSE access::can-delete: TRUE access::can-trash: TRUE access::can-rename: TRUE time::modified: 1291888613 time::access: 1291888648 time::changed: 1291888648 unix::device: 17 unix::inode: 59669 unix::mode: 33152 unix::nlink: 1 unix::uid: 1000 unix::gid: 1000 unix::rdev: 0 unix::block-size: 4096 unix::blocks: 20728 owner::user: kernel owner::user-real: owner::group: kernel After I rename test.rmvb to test.avi, the output is as follows: kernel@fairland:~/tmp$ gvfs-info test.avi display name: test.avi edit name: test.avi name: test.avi type: regular size: 10592997 attributes: standard::type: 1 standard::name: test.avi standard::display-name: test.avi standard::edit-name: test.avi standard::copy-name: test.avi standard::icon: video-x-msvideo, gnome-mime-video-x-msvideo, video-x-generic standard::content-type: video/x-msvideo standard::fast-content-type: video/x-msvideo standard::size: 10592997 standard::allocated-size: 10612736 etag::value: 1291888673:0 id::file: l17:60262 id::filesystem: l17 access::can-read: TRUE access::can-write: TRUE access::can-execute: FALSE access::can-delete: TRUE access::can-trash: TRUE access::can-rename: TRUE time::modified: 1291888673 time::access: 1291888674 time::changed: 1291888673 unix::device: 17 unix::inode: 60262 unix::mode: 33152 unix::nlink: 1 unix::uid: 1000 unix::gid: 1000 unix::rdev: 0 unix::block-size: 4096 unix::blocks: 20728 owner::user: kernel owner::user-real: owner::group: kernel thumbnail::path: /home/kernel/.thumbnails/normal/d0ba2933a4bf3f6032a6864233a7637a.png Hope this would help
(In reply to comment #1) > Can you please post the output of "gvfs-info whatever.rmvb"? Thanks for your hint, after hacking with /usr/share/mime/packages/freedesktop.org.xml, I successfully cheated gvfs-info, and make it believe "whatever.rmvb" is of content type "video/x-msvideo", which is supported by tumbler. So the thumbnailer is successfully generated. As you can see, this is kind of ugly. Is there a more elegant solution?
(In reply to comment #3) > As you can see, this is kind of ugly. Is there a more elegant solution? Well, there are two options I think: 1. add application/vnd.rn-realmedia to the MIME types supported by the ffmpegthumbnailer plugin and hope it will work 2. check standard::fast-content-type in addition to standard::content-type and assume the file is supported if either of these returns a type that one of the plugins can handle Not sure what's the best way here, though. I suppose that standard::fast-content-type won't always be reliable enough for us to use it.
Created attachment 3260 Added support for realmedia
(In reply to comment #4) > (In reply to comment #3) > > > As you can see, this is kind of ugly. Is there a more elegant solution? > > Well, there are two options I think: > > 1. add application/vnd.rn-realmedia to the MIME types supported by > the ffmpegthumbnailer plugin and hope it will work > > 2. check standard::fast-content-type in addition to > standard::content-type and assume the file is supported if > either of these returns a type that one of the plugins can > handle > > Not sure what's the best way here, though. I suppose that > standard::fast-content-type won't always be reliable enough for us to use it. I took option 1, and it worked as expected, could the upstream apply this one line patch ? I think the bug could be closed. Thank you.
I've pushed the patch to master: commit 6d3cdc19e0f4479349bf106fcba9d8128b58d4bf Author: churchmice <firefoxelectric@gmail.com> Date: Fri Feb 24 17:05:53 2012 +0000 Add application/vnd.rn-realmedia to the ffmpeg plugin (bug #6949).