GNOME Bugzilla – Bug 651743
youtube plugin - 'play in banshee' does not work
Last modified: 2011-11-28 15:03:42 UTC
This report was originally filled at: https://bugs.launchpad.net/ubuntu/+source/banshee/+bug/791902 youtube plugin does not work. the videos are visible in the context pane, but they do not play in banshee. (they do play in web browser) 1. install plugin: edit - preferences - extensions - context pane - youtube 2. activate context pane: view - context pane 3. play video: video drop down menu - play in banshee - nothing happens Banshee Debug: [1 Debug 16:33:04.365] Banshee supported playback Uri not set [1 Debug 16:33:13.603] Banshee supported playback Uri not set [1 Debug 16:33:25.762] Banshee supported playback Uri not set [1 Debug 16:33:28.048] Player state change: Paused -> Playing [1 Debug 16:33:30.161] Banshee supported playback Uri not set [1 Debug 16:33:38.117] Opening URL via gtk_show_uri - http://www.youtube.com/watch?v=lVK2sLDivQg&feature=youtube_gdata_player [1 Debug 16:33:49.247] Player state change: Playing -> Paused [1 Debug 16:33:52.450] Banshee supported playback Uri not set
Since almost 5 months, any update ?
I was looking at this a little while ago and found where the problem is, but would prefer a banshee developer or someone that has more time to look into the youtube api to fix this. From what I can tell the problem occurs in file: src/Extensions/Banshee.YouTube/Banshee.YouTube.Gui/YouTubeTile.cs in function: GetPlaybackUri From what I can tell the youtube api there are 2 different values for the various video formats. http://code.google.com/apis/youtube/2.0/reference.html#formatsp http://code.google.com/apis/youtube/2.0/reference.html#youtube_data_api_tag_media:content What I don't understand (and didn't dig into) was that uint content_format = Convert.ToUInt32 (m.Format); was returning a different value than what int flv = (int)YouTubeQuery.VideoFormat.Embeddable; int mobile = (int)YouTubeQuery.VideoFormat.Mobile; generated. So, what effectively happens is the checks in there that create the playback_uri all fail. I'm not sure what the correct fix is, but that would be the place to start. Of course, this is ignoring the issue of codecs ;)
I'm not sure if the library is being used wrong or this is an upstream bug. Here is the bug I filed against google-gdata http://code.google.com/p/google-gdata/issues/detail?id=553&colspec=ID%20Type%20Status%20Owner%20Summary I'll attach a patch to this bug.
Created attachment 200537 [details] [review] Makes it so that at least clicking on the button does something Makes it so that at least clicking on the button does something. It seems to load and play audio, but no video.
This has been fixed upstream in google-gdata.
Comment on attachment 200537 [details] [review] Makes it so that at least clicking on the button does something (In reply to comment #5) > This has been fixed upstream in google-gdata. Awesome, did they raise the version number of the library? If yes, I guess we can now depend on the new version to close this bug? And we don't need this patch anymore.
Yes, it's 1.9.0.* in AssemblyVersion.cs now. I'm working on packaging it.
Awesome. Chow thanks for doing that.
Great, but can't we do also some m4/conf magic to make banshee complain if it doesn't find the new version of the lib?
Mm sorry, I forgot to mention that. The .pc files have their Version field populated with the version extracted from the AssemblyVersion, i.e. 1.9.0.0.
Created attachment 202230 [details] [review] Proposed patch (In reply to comment #10) > Mm sorry, I forgot to mention that. The .pc files have their Version field > populated with the version extracted from the AssemblyVersion, i.e. 1.9.0.0. Cool, then, I assume this patch works? Can someone test please?
Comment on attachment 202230 [details] [review] Proposed patch The bug is not fixed in gdata 1.9, so bumping the requirement does not help.
This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report. I just committed a fix for this issue, adding our own enum with the right values, instead of using the incorrect one in gdata : http://git.gnome.org/browse/banshee/commit/?id=d4da0469 As indicated above, the fix in gdata is NOT in their 1.9 release, so no need to rush to package it ;)