XSPF Playlists and Thumbnails integration with CCK Imagefield/Filefield

I came to this issue from http://drupal.org/node/494818. Using 6.x-1.0-alpha2 I also have the behavior described there. I manually applied the patch provided here to a xspf_playlist_cck 6.x-1.0-alpha2. It seems to do the work, now I can have my FileField files in playlist (node/xx/xspf and views).

Here is a patch file against v6.x-1.0-alpha2. I generated the file using Bazaar as VCS. I'm new to Drupal dev. so I don't know if it fit contributed patch requirements.

This patch builds on the previous ones to take module weight into consideration when selecting the thumbnail to use...

You can select multiple sources for the thumbnail. In the config page it says: "Select the thumbnail type you would like to use. You can select multiple, but if multiple thumbnails for an item exist, the first one found will be used."

With this patch, module weight is also taken into consideration when selecting the thumbnail, you can at least get some control over what the 'first one found' will be.

My use case is that I'm using media mover to generate an automatic thumbnail, but also providing a cck field to allow this to be overridden if desired. So, by ensuring that xspf_playlist_thumb runs after media_mover_api (by adjusting module weights) I can ensure that the thumbnail from the cck field will be used if it exists.

The patch in #2 works with alpha 2 to show the relevant CCK fields to choose from to generate your playlist. This should be rolled into the dev as its pretty crucial functionality that seems to be missing before this patch
Unfortunately the thumbs patch in the original post does not patch against alpha 2 cleanly and so I dont get the option to choose the cck field for thumbnail.

Any chance of rolling a newer version of the thumbnail patch that will work with alpha 2?

Thanks

I elevate the priority of this issue to critical since it renders the xspf_playlist_cck module unusable. Hopefully, it would help to get the patches reviewed and included in a future release.

I manually applied all of these patches against both alpha2, and the latest dev available atm (2009-Jul-17). As stated before they dont patch clean from the command line anymore, but the playlist_cck patch up to #2 work like a charm, but the playlist_thumb still seems not to work, rather than associating the files from the node as thumbnails its currently posting them as being part of the playlist which isn't right at all. Anyone have suggestions on how to fix this or what the issue might be?

subscribing. thanks

subscribing... any chance this could be ported to the D5 version?

Tested #8 patch -- so far so good
Thanks.

I applied xspf_playlist_cck_2.patch and now I can specify filefields to build the playlist. I'm using only mp3 files.

Problem #1
I am not getting XML output at URL ../node/XX/xspf . Instead, this page looks like this:
"XSPF Test Node http://localhost:8888/ Default playlist info jsulmar /sites/default/files/f1.mp3 http://localhost:8888/node/30 mp3 XSPF Test Node #1 30 jsulmar /sites/default/files/f2.mp3 http://localhost:8888/node/30 mp3 XSPF Test Node #1 30 jsulmar /sites/default/files/f3.mp3 http://localhost:8888/node/30 mp3 XSPF Test Node #1 30
"
Problem #2
The FLV player window displays the message "No suitable model found for playback of this file.

Any suggestions will be much appreciated. Thanks.

I think you need to get the latest dev version of the flv media player from CVS to fix problem #2
The dev version might work but using CVS will guarantee the latest copy.
Here is a post about the issue http://drupal.org/node/524180

I am not quite sure what is the issue in problem #1?
Have you set up a flv media player profile? Have you been to the xspf settings page and associated the correct node you want an xspf playlist to render on? Make sure after you have specified this content type you save and then click on the specific content types settings, associate your filefield and then save?

Maybe if you format your output to be the same as the xspf page is showing you it may be easier to debug and work out whats going wrong. I find your phrasing of #probem 1 above a bit difficult to understand.

Which browser are you using ? Using Chrome (beta 4.0.222.5) on Ubuntu Linux I get similar looking results when viewing any XML document. I need to right-click and select "View page source" to see the full XML.

Thanks very much, the CVS files solved my problem #2. A post by user 92190 identified what files needed to be updated relative to 6.x-1.0-alpha2. See http://drupal.org/node/505276#comment-1765510

Thanks mongolito404, my xml was there all along. I just had to "view page source".

Patch in #8 almost work, but I need to change this line:
if ($xspf_item = xspf_playlist_node_build_file_item($node, $GLOBALS['base_path'] . $field['filepath'])) {
to:
if ($xspf_item = xspf_playlist_node_build_file_item($node, $GLOBALS['base_url'] . '/' . $field['filepath'])) {

Without this the cck filefield path is wrong.

When trying to install the dev release, it appears in my menu underneath 'Content types' in stead of 'Site configuration'
I can not configure any settings nor associate it with a content type.

I am too much of noob to patch it myself

With the latest alpha release, I only see CCK text fields to associate with... Not my CCK file field
Can I download another patched alpha version in stead of the dev release?
Anybody else experiencing this problem?

I am but for now, i am only using video stored in youtube, still no luck with thumbnails in playlists

Hello;

Can anyone please give clear instructions how to get thumbnails from cck filefield to show in the alpha version. The dev version is quite different. I have applied the patch, uploaded images with filefield and nothing shows up. The only way I get thumbnails is to use the upload module as a file attachment, but i want to use filefield because it is more flexible. Please any clear instructions would be greatly appreciated.

Kemi

Once again, thanks jcmarco for the patch. I applied this to dev, ready for testing.

calling it fixed, then, thanks!