GNOME Bugzilla – Bug 633094
Rhythmbox imports (some) videos and plays them
Last modified: 2010-11-26 16:10:48 UTC
Created attachment 173164 [details] Rhythmbox imports videos Rhythmbox version: 0.13.1, packaged for Ubuntu 10.10 I'm uncertain about the Rhythmbox component: this bug is relative to "importing", "playback" and "plugin" so I'm filling it under "general" This bug was first reported in Ubuntu Launchpad: https://bugs.launchpad.net/ubuntu/+source/rhythmbox/+bug/665865 Hello, I have various video files in my Music folder, for instance music videos or live footage ripped from some album's bonus CD or DVD or downloaded form the Internet. To my surprise, this version of Rhythmbox imports some of them in the music library, but not all of them. In the attached screenshot you can see five FLV videos downloaded from the Internet and listed by Rhythmbox in the music library (with Unknown as Genre / Artist / Album, quite understandably). All other videos in my Music folder are not recognized. At first I suspected Rhythmbox importing videos or not was a matter of container format and/or audio-video codecs, but I have examples of files in the same format and codecs, one of them being imported but the other not, so I have no idea of a possible interpretation. Then, to my utmost surprise, Rhythmbox plays these videos! I found out that when the Visualization plug-in is enabled, Rhythmbox plays the video flawlessly in an external window (see attached screenshot) (restarting Rhythmbox seems necessary, though), and when this plug-in is disabled, Rhythmbox plays only the audio, with the position slider not working as it should, i.e. it runs quickly to the right and then stops at the end while the remaining audio is read (always at normal speed). During video playback, Rhythmbox controls work as expected (pause, previous/next, moving the slider). If the Visualization button is clicked, the external window is docked into Rhythmbox (like a visualization). If it is clicked again, the external window does not pop out, the visualization disappears but the audio keeps playing. One more quirk: if I close the video window during playback, the video that was played disappears from the music library to go in the Missing Files section, with the error "Output window was closed" (see attached screenshot). The next time I start Rhythmbox, these errors are gone and the videos are back in the music library. So... From perusing the bug archives, I understand that Rhythmbox, although not a video player or video library manager, has some video podcast abilities through the Visualization plug-in, so perhaps the five video files it lists are recognized as downloaded video podcasts (they are not, as far as I know)? I appreciate that Rhythmbox lists and plays them, but would be even more delighted if it listed and played all the video files in my Music folder, not just these arbitrary five. To sum it up: 1. What I expected to happen: as far as I know, Rhythmbox is not supposed to list video files in the music library, let alone play them. 2. What happened instead: Rhythmbox imported and played videos, but only some of them, and with a few quirks. I have run apport-collect on this bug in Launchpad if it helps, see: https://bugs.launchpad.net/ubuntu/+source/rhythmbox/+bug/665865. If you need it, I may attach an example of video that gets recognized and an example of video that does not, and of course provide any other kind of information needed.
Created attachment 173166 [details] Rhythmbox plays videos
Created attachment 173167 [details] Error after closing video window
Video playback isn't supposed to work, so the only thing I'm really interested in fixing here is that we're not filtering out all video files. Output from '/usr/lib/rhythmbox/rhythmbox-metadata --debug --load file:///path/to/file.flv' will probably help in figuring out why that's happening.
Attached two outputs: one for a file that is imported in the library, the other for a file that is filtered out. Both files are VP6F/MP3 in FLV container according to mplayer.
Created attachment 173229 [details] Output of rhythmbox-metadata --debug for a video file that is imported in the music library
Created attachment 173230 [details] Output of rhythmbox-metadata --debug for a video file that is filtered out of the music library
That doesn't explain what's going on at all. If you remove and re-import a video file, does it still get added to the library?
No, it doesn't. Re-importing the video file through "Music > Import a file..." fails silently. I tried drag-and-dropping the file into Rhythmbox and got the error message: "Didn't get a playback URI for entry file:///home/romain/Musique/Coming%20Soon/Ghost%20Train%20Tragedy/17%20-%20Moonchild.flv". I use the "Watch library" feature so I wanted to check if this feature can re-import the video file I removed. I deleted ~/.local/share/rhythmbox/rhythmbox.xml and restarted Rhythmbox, but to my surprise the video file was not re-imported. I guess removed files are blacklisted somewhere else?
No, they're not. I think this just means that the bug that caused these files to be imported has already been fixed. If you can reproduce this with files newly imported into 0.13.1 or newer, please reopen this bug.
I don't get it. I am using 0.13.1 and it is a fresh install. I mean, it is not a version of Rhythmbox updated from a pre-0.13.1 version. That is to say, these files were imported into 0.13.1 directly (a few days ago), they were not imported into a previous version that was latter updated. That being said, I cannot really reproduce this bug any more since I removed four of the five video files from the library and they wouldn't be re-imported again, even after I deleted rhythmdb.xml. I can now see the blacklisted video files in rhythmbox.xml, with type="ignore" and mimetype application/octet-stream. The last video file that remains in my library is also listed, with type="song" and mimetype video/x-flv. Of course, when I change back the type and mimetype fields of a blacklisted video file, it comes back in Rhythmbox's music library. Anyway, I will keep an eye on it and report back if necessary.
Hi! I'm back on this bug report. I had some time to toy around with Rhythmbox's "Import" function and try to understand how Rhythmbox could have imported some video files in the music library (initial bug report) and then refused to import them again (my comment 8). So I ran a little experiment and Rhythmbox's behavior was so weird I thought I should share the lol. Before this test, I de-activated library change monitoring in "Edit > Preferences > Music" and emptied my music library by deleting ~/.local/share/rhythmbox/rhythmdb.xml. The test ran as follow: 1. I import one of the five video files that Rhythmbox did not filter out, using "Music > Import a file". The video is correctly imported and rhythmdb.xml reads: <?xml version="1.0" standalone="yes"?> <rhythmdb version="1.7"> <entry type="song"> <title>17 - Moonchild.flv</title> <genre>Inconnu</genre> <artist>Inconnu</artist> <album>Inconnu</album> <duration>252</duration> <file-size>69702953</file-size> <location>file:///path/to/17%20-%20Moonchild.flv</location> <mtime>1287498769</mtime> <first-seen>1288993310</first-seen> <last-seen>1288993310</last-seen> <bitrate>192</bitrate> <date>0</date> <mimetype>video/x-flv</mimetype> </entry> </rhythmdb> 2. Then I remove this video file using "Right clic > Remove". It disappears, and rhythmdb.xml is updated as follows, after a while though (slightly longer than usual): <?xml version="1.0" standalone="yes"?> <rhythmdb version="1.7"> </rhythmdb> 3. I try to re-import the video file. It is not re-imported and rhythmdb.xml gets updated as: <?xml version="1.0" standalone="yes"?> <rhythmdb version="1.7"> <entry type="ignore"> <title></title> <genre></genre> <artist></artist> <album></album> <location>file:///path/to/17%20-%20Moonchild.flv</location> <mtime>1287498769</mtime> <date>0</date> <mimetype>application/octet-stream</mimetype> </entry> </rhythmdb> 4. I quit Rhythmbox, delete rhythmdb.xml, thereby coming back to the begin conditions of this test, restart Rhythmbox and try to re-import the video file, just as in step 1. To my surprise, it is not re-imported and rhythmdb.xml is re-created exactly the same as before deletion. Returning to the "begin conditions of this test" is actually more difficult than I thought at first: quitting Rhythmbox + deleting rhythmdb.xml + restarting Rhythmbox is not enough since the video file is not re-imported after that, although its blacklisting is supposed to be gone with 'rm rhythmdb.xml'. Actually, it looks as if some persistence of the blacklisting of the file is kept somewhere else. And this somewhere else resists to several Rhythmbox restarts, rhythmdb.xml deletions and computer reboots... So I decided it was enough eccentricity, ran one last 'rm rhythmdb.xml' and went to bed. This morning I just tried step 1 for fun's sake, and sure enough, it worked now: the video file /is/ imported, and the rest of the test runs just as yesterday. To sum it up: -- it is still possible to have Rhythmbox import the video file, if Rhythmbox starts in some sort of "new" state (empty library) (that explains my initial bug report, which was relative to my first run of Rhythmbox on a newly installed system) -- after removing the video once, it is not possible to have Rhythmbox import it again (that explains my previous comment 8 on this bug report) -- returning to the "new" state is not as easy and clear as 'rm rhythmdb.xml' but somehow, after some time, Rhythmbox has indeed returned to the "new" state and the bug may be reproduced OK, now I am not re-opening this bug though, because well, it just affects five files on one guy's computer on the whole planet, and there's an easy workaround (remove the files from the library and don't rm rhythmdb.xml!), so it's fine... Still, I felt like I had to give some feedback on it, in case it proves useful somehow in the future.
(In reply to comment #11) > Returning to the "begin conditions of this test" is actually more difficult > than I thought at first: quitting Rhythmbox + deleting rhythmdb.xml + > restarting Rhythmbox is not enough since the video file is not re-imported > after that, although its blacklisting is supposed to be gone with 'rm > rhythmdb.xml'. Actually, it looks as if some persistence of the blacklisting of > the file is kept somewhere else. And this somewhere else resists to several > Rhythmbox restarts, rhythmdb.xml deletions and computer reboots... No, it definitely is not. > OK, now I am not re-opening this bug though, because well, it just affects five > files on one guy's computer on the whole planet, and there's an easy workaround > (remove the files from the library and don't rm rhythmdb.xml!), so it's fine... > Still, I felt like I had to give some feedback on it, in case it proves useful > somehow in the future. If you can reliably reproduce this, please provide output from 'rhythmbox -d' where you start with an empty database and successfully import one of these video files.
Hi! Sorry for the delay in reporting on this bug, loads of work. I confirm that I can reproduce this behavior, however I do not control the causes that make Rhythmbox import or refuse these video files, so I keep trying from time to time and sometimes it imports, sometimes it refuses, with no obvious reasons. Anyway, I'm attaching the output of 'rhythmbox -d' when I start with an empty database and successfully import one of these video files, as you requested (files import-successful.out|err). I'm also attaching the output of 'rhythmbox -d' when I start with an empty database and Rhythmbox refuses to import the same video file (files import-denied.out|err), for diff. > No, it definitely is not. Yes, I totally agree, it sounds crazy, and it is not what really happens, but this is how it looks like. Just an delusion of course. While I'm at it, more fun with Rhythmbox's "Import"! During my tests I found out that step 2 in my previous comment 11 may be replaced by: 2'. Then I quit Rhythmbox, delete rhythmdb.xml, and restart Rhythmbox. The other steps being exactly the same. I say, it is weird. As I see it, it looks as if Rhythmbox imports the video file, or not, depending on how much time has passed since the last time it imported, or not, the video file: -- if enough time has passed since the last time it refused to import the video, it accepts to import it -- if not enough time has passed since the last time it accepted to import the video, it refuses to import it A behavior somewhat reminiscent of hysteresis phenomena in physical sciences. Once again, I am totally aware that this is not a rational explanation: I'm merely trying to put words on this behavior. -- PS: of course, after each refusal of Rhythmbox to import the video, I remove rhythmdb.xml to have a chance to see Rhythmbox import the video again, and after each acceptance of Rhythmbox to import the video, I remove it from the library (step 2) or delete rhythmdb.xml (step 2') to have a chance to see Rhythmbox refuse to import the video again.
Created attachment 175255 [details] stdout of 'rhythmbox -d' when successfully importing .flv file
Created attachment 175257 [details] stderr of 'rhythmbox -d' when successfully importing .flv file
Created attachment 175258 [details] stdout of 'rhythmbox -d' when unsuccessfully importing .flv file
Created attachment 175259 [details] stderr of 'rhythmbox -d' when unsuccessfully importing .flv file
OK, so what's actually happening here is that the creation of the video pad in the flv demuxer is racing against the pipeline state change. If the video pad is created first, the file is correctly rejected. If the pipeline state change happens first, we only see the audio pad, so the file is imported. The code in rhythmbox that deals with this is going to be replaced soon anyway, so I'm not going to look into this any further until that's done.
OK, thank you very much for your time and investigations !