GNOME Bugzilla – Bug 110129
Winamp windows m3u playlist compatibility
Last modified: 2004-12-22 21:47:04 UTC
The player does not read windows \\servername\sharename\filename in the playlist.
Created attachment 15517 [details] [review] Patch for windows samba style names
I ll review that patch together with Bastien Nocera. Indeed we maintain together the playlist widget which is shared with totem project. I think we will have to discuss the way to handle samba shares on other playlists too.. Thanks for that patch anyway, i ll keep you updated. Dolphy
Reassigning that to Totem, I'll bounce it back to gst-player when I've reviewed the patch.
The code is very ugly, especially the dos2unix newline conversion. Can you clean the code up a bit? I'm willing to add this functionality to the playlist.
Created attachment 17717 [details] [review] Updated to read m3u files using windows style smb (patched against 0.5.1)
Could you please provide a diff -u patch? Thanks. :).
Created attachment 17718 [details] [review] diff -u of previous patch
Ofer, you attached a patch against your old patch. Could you update your patch against totem-0.99.0? Cheers
Created attachment 17747 [details] [review] Diff of totem modfied vs totem orig
Created attachment 17748 [details] [review] unified diff of previous attachment
The changes to gtk_playlist_add_mrl_with_data are broken. The gnome_vfs_get_mime_type call in gtk_playlist_add_mrl should already figure out that it's an m3u file. The changes to gtk_playlist_add_m3u are slightly broken too. Instead of: + char *split_char = " "; + split_char = "\n\0"; /* This is broken, the string will end up with 2 null-terminators */ You should have something like: char *split_char; split_char = "\n"; To create your patches more easily, you could: 1) checkout totem from the GNOME CVS. 2) Once you have checked it out, modify src/gtk-playlist.c 3) Send us the output of "cvs diff -u" (makes diffing a lot easier :) Thanks for working on that
Created attachment 17760 [details] [review] cvs diff -u difference and fix for double null
I thought i needed to allocate and deallocate cstring*'s, i didn't know it could do it dynamically, i was trying to avoid allocating / deallocating... The gnome_vfs_get_mime_type_for_data function reads m3u's as text/plain which is incorrect and disallows the loading of m3us, so i stuck in to get it via MRL.
" The gnome_vfs_get_mime_type_for_data function reads m3u's as text/plain which is incorrect and disallows the loading of m3us, so i stuck in to get it via MRL. " Yes, but gnome_vfs_get_mime_type call in gtk_playlist_add_mrl should already catch the file as an m3u file, and the _data call doesn't need to be called (otherwise, it's a bug). Please provide an example m3u file if there's such a bug please
Created attachment 17763 [details] A demo m3u file that doesn't get detected
$ gnomevfs-ls | grep m3u foo.m3u (Regular, audio/x-mpegurl) size 112 mode 0644 As long as this file has a .m3u extension, it will show up properly in the playlist. What is the filename you're trying to use it as?
i'm actually working against GST, not totem, but its an m3u (.m3u), and it gets detected as plain/text Maybe the totem gtk-playlist doesn't have that problem, but i can't get 0.99.1 running, it compiles fine but just hangs when i try to run so i can't actually see how it runs in totem
Which program you use shouldn't make a difference. What is the filename you're using for this file? Add some debug in gtk_playlist_add_mrl() if you're not sure, it shouldn't even need to go near the _data call. To make totem work... (it's at the top of the README btw) http://lists.gnome.org/archives/gnome-announce-list/2003-May/msg00096.html
Committed without the gnome_vfs_get_mime_type_for_data bit 2003-06-27 Bastien Nocera <hadess@hadess.net> * README: upd * src/bacon-video-widget-xine.c: (xine_event_message), (xine_event): change the message when a destination doesn't resolve, implement reference MRLs as close/open calls * src/gtk-playlist.c: (gtk_playlist_add_m3u): patch from Ofer Achler to allow Totem to read Winamp m3u files with SMB locations (Closes: #110129)