Remove Direct Link to Mp3

Do you find any solution for this?
I try to disable mp3 donwload...

+1
Then in jplayer.tbl.php i changed line 44 to
Now new dev , the line 44 is different .......
How to fix it ......

Any help?

The documentation for the Jplayer plugin (http://www.jplayer.org/) states that there is an optional property for allowing download of media. Has this option been over-ridden, or could this not be implemented with a value of false to remove links?

http://www.jplayer.org/latest/demos/

'The playlist item object can include an optional {free:true} property to make the media easily available via a right-click. (Ctrl+click on Mac.)'

I hid it with css. Figured it was as good considering that it can't be kept all that protected due to it being put in the browsers cache folder to be played.

@VM, when you say you hid it with CSS, do you mean the playlist itself?

#8 yep. though I only use a single instance ie: not multiple files in the playlist. The player is set to autoplay thus no need for the playlist to show. However, it's important to note that even if this is stripped the files can still be downloaded. All one has to do is look at the source code and use the url to the file. Which is basically the same for every player I've looked at. There really is no way to protect files from being downloaded as the reality is the must be downloaded to play. Albeit into the browser tmp folder.

I believe everyone here is on the right track by dealing with this at the theme layer.

I see, thanks for the reply. Yeah, I know there really is no way to protect the files, but I wanted to make it a bit harder than right click and save, you know just for those people that don't know better. I would like to keep the playlist and its click and play functionality. I'm looking into how I can use the {free:true} property that Elder Brother talked about in post #6 but I'm having trouble figuring out how/where to use it in this module's code. If I could only find where the playlist properties are.

{free:true} is js and I'm guessing (haven't dug through jplayer javascript docs) that it would have to be in the jquery js that is being used. Thus it may not go directly into the module.

edit: dug a bit into the reference from elder about {free:true} http://www.jplayer.org/latest/demos/

looking at the jplayer module files. There is a jplayer.js file in the theme folder. My uneducated jquery guess is that it's going to have to go in there somewhere. likely where the playlist is initialized. I have no idea how that would be implemented nor the syntax needed. It's likley more than just adding {free:true} to the file somewhere though.

Yeah, I thought so too, I've been looking at that file up and down but can't really find where it should go. I'm guessing there should be an array of playlist properties somewhere where I can add this, but still haven't figure it out. I'm going to continue looking today.

as an aside, http://drupal.org/project/mediaelement allows control over the download link

Thanks, I'll give it a try.

Ok, I tried MediaElement and I really like it. It doesn't display the songs titles, but even though I haven't looked at MediaElement's code, I think it'll be easier to modify the code to display the title of each song that it is to prevent direct download from the jplayer playlist.

I'll report back with my results.

Well I kind of solved the issue. I was so obsessed in finding where to add the {free:false} property to the jplayer playlist that I overlooked a stupidly obvious way to achieve the almost same result by simply using the javascript event onContextMenu. Of course, it's still easy to obtain the URI, but at least it's a setback for the not so savvy people.

It's not exactly the same as the free property. You can still clearly see the URI of the media by hovering over it unlike when using the {free:false} property. It's still something but not as good.

Update: Also fixed the "URL showing in status bar when hovering over the link" issue by simply using an onclick JS event to redirect the user when selecting a song from the playlist.

#16: Great, can those adjustments be committed to the -dev release?
(But the "real" fix should be setting the {free:false} where it should be, though, even if that may take longer to get in.)

@ #17 no one in this issue is a maintainer of the module. The module is minimally maintained at this time. There are multiple patches that are in the queue which haven't seemed to make any progress.

#18: The state of this module is currently "actively maintained", which leads me to assume that even if the maintainers arent replying right here, at least they are watching new comments. If not, this module should have its status changed to "seeking maintainer".

I'm not speaking for the maintainers merely taking into consideration the last commit which was in March 2011 and the last activity in the queue with reference to patches.

There are a number of issues marked waiting for review and have been for some time as well as a number of issues that have been marked RTBC and have waiting for a commit for some time. It is from this information that my comment/suggestion was made.

Perhaps the current maintainers are just busy with other more important tasks. If comments are being watched as you suggest ... cool. If that equates to maintenance also cool. I don't tend to assume based on tags on the project page. My assumptions are made based on checks for physical activity/forward progress in the queue and commit logs which IMO is a much better indication of how a module is being maintained. Which is not and should not be an indicator for overall maintenance or a return to physical activity picking up in the future.

Unfortunately there is no patch in this issue to be able to mark it "needs review" or for everyone here to be able to test and RTBC it. Rereading the entire thread it's gotten a bit murky as it looks as if therer are multiple issues being discussed.

I can't do anything about the current state of the tag you reference.

Here's a patch with the changes I posted in post #16.

I get this error on the latest dev applying "git apply -v hide-direct-link-1046744-16.patch"

hide-direct-link-1046744-16.patch:19: trailing whitespace.
      $attributes['oncontextmenu'] = "return false;"; //Custom Code
hide-direct-link-1046744-16.patch:28: trailing whitespace.
      $playlist[] = l($file['label'], '#', array('attributes' => array('id' => $player_id . '_item_' . $num, 'tabindex' => 1, 'onclick' => '<?php drupal_goto($file["url"]) ?>;')));  //Custom Code
hide-direct-link-1046744-16.patch:37: trailing whitespace.
      $playlist[] = l($file['label'], '#', array('attributes' => array('id' => $player_id . '_item_' . $num, 'tabindex' => 1, 'onclick' => '<?php drupal_goto($file["url"]) ?>;')));  //Custom Code
Checking patch includes/jplayer.theme.inc...

warning: includes/jplayer.theme.inc has type 100755, expected 100644
error: while searching for:
      if ($i == $num_items - 1) {
        $attributes['class'][] = 'last jp-playlist-last';
      }
      $output .= '<li' . drupal_attributes($attributes) . '>' . $data . "</li>\n";
    }
    $output .= "</$type>";

error: patch failed: includes/jplayer.theme.inc:86
error: includes/jplayer.theme.inc: patch does not apply

Thanks for letting me know. I'll look into it.

Edit: I applied the patch to the latest dev and it worked fine for me.

Anyone else getting this error?

Edit 2: If you open the patch with a text editor you'll notice that line #12 ends with the number 100644. This is a shot in the dark, but try changing that number to 100755 and see if that does anything.

It works. Guess maybe this was due to I opened the file in dreamweaver and some code (spaces?) changed without my knowledge.

Good to know.

Thank you! Thank you! Thank you MakubeX! Your patch has saved me after a week of frustration : )

I'm glad it helped someone other than me. :)

This patch isn't working with Views. Do we have to add seperate support?

Nevermind, just realized this was for playlists.

I'd be OK with adding this as a feature, but it should be configurable with a variable per field instance. The patch in #21 is fine for any sites needing to implement this now, but to commit this I'd want it to be an exposed option.

After i add this patch(#21), my jplayer not play any mp3 file.
My jplayer version is 2.4
My Jplayer module version is newest version.

I'm concerned about the patch above. It doesn't create anchors '#' the right way, and it tries to use drupal_goto() in a way that doesn't seem correct.

I have rerolled the patch with these things fixed. If I ever get time, I will make a configurable version, as proposed above.

@RoloDMonkey: I have applied your patch to the latest dev build. Thanks for your assistance. If you get the configuration set up, please open a new issue.

So left click on download button doesn't work now, which is not very useful to the visitors if they don't know what to do with it atm. I am not sure if i understand this correctly, please tell me if i am wrong... Why would we like to disable right or left click on download button anyway?

@Nemanja: For my client, they wanted the music to play when the link was clicked. But, they didn't want people to be able to easily download the entire MP3 just by right-clicking. My guess is that the other participants in the thread wanted something similar.

If you want to provide a separate "Download" button/link, that shouldn't be difficult for you to set up.