Allow chapter seeking based on urls as describe in http://www.longtailvideo.com/support/jw-player/jw-player-for-flash-v5/17... chapter "Alternative seeking use: permalinks".

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

corvus_ch’s picture

FileSize
3.06 KB
corvus_ch’s picture

Status: Needs work » Needs review
Berdir’s picture

Status: Needs review » Needs work
+++ b/jw_player.jsundefined
@@ -5,6 +5,7 @@
   Drupal.behaviors.JWPlayer = {
     attach: function(context) {
+      console.log('foo');
       var players = Drupal.settings.jw_player;

:)

+++ b/jw_player.moduleundefined
@@ -455,6 +457,8 @@ function jw_player_process_jw_player(&$variables) {
+  // Add js file that enables url based seeking.
+  drupal_add_js(drupal_get_path('module', 'jw_player') . '/jw_player_seek.js');

File is missing...

corvus_ch’s picture

Status: Needs work » Needs review
FileSize
3.32 KB

Removed debug and included the missing file.

corvus_ch’s picture

FileSize
4.21 KB

For my current use case I needed to extract the player id for usage in another field.

This patch contains the changes that allows me to do that.

Berdir’s picture

Status: Needs review » Fixed

Looks good, commited and pushed.

corvus_ch’s picture

Status: Fixed » Needs review
FileSize
897 bytes

I would like to reopen this for a follow up.

Today I realized that I need to be able to trigger seeking without knowing the player id.

The attached patch allows to do exactly that.

Hopiu’s picture

Does the player_id really have to be generated with the file id? What about a player having a playlist with multiple files?
See Issue: #1215108: Create a playlist field formatter (I rewrote that patch already to work with the current dev snapshot, but it get's dirty...)

corvus_ch’s picture

Status: Needs review » Needs work

That is really a problem.

The original intention was to get a id that is static and allows us to make use for linking. The module i am developing that had the need for this does not do so anymore. That is another problem.

The question then is how to proceed from here on?

  1. Revert the change back to wat it was before.
  2. Find a beter way to create a static id

Personally I would opt for option two. So my question goes to Hopiu: what can we use to build a static id that does not interfere with what you are trying to achieve?

Berdir’s picture

Title: Allow seeking by url paramters » Allow seeking by url parameters
Hopiu’s picture

In my opinion we should at first create another field type "playlist" and solve those structural problems before getting more features into the module. According to your problem a static id could be part of this playlist type.

A playlist could look the following:

{
    "id": "[number]",
    "items": [
        {
            "title": "[string]",
            "description": "[string]",
            "mediaid": "[number]",
            "captions": [
                {
                    "file": "[file](could be url too)",
                    "label": "[string]"
                }
            ],
            "image": "[image]",
            "sources": [
                {
                    "file": "[file](could be url or video too)",
                    "label": "[string]",
                    "height": "[number]",
                    "width": "[number]"
                }
            ]
        }
    ]
}

The first "level" isn't actually needed, but it provides a static id. Not all the fields have to be accessible for the user, or maybe there could be something like an advanced input form.

Maybe someone more experienced could give a hint if this can be done with "Fields" or on a better way to create such a strucutre...

  • Berdir committed 6ce6249 on 8.x-1.x authored by corvus_ch
    Issue #1894656 by corvus_ch: Allow seeking by url paramters.
    
corvus_ch’s picture

Assigned: corvus_ch » Unassigned
Issue summary: View changes
ron_s’s picture

Title: Allow seeking by url parameters » Fix js seek functionality
Version: 7.x-1.x-dev » 7.x-2.x-dev
Status: Needs work » Needs review
Related issues: +#2713725: Refactor theming, +#2719977: Add js file to build player
FileSize
4.07 KB

The included patch connects to our Refactor theming work, and incorporates what has been done in previous patches on this thread.

There are three major components to what we have done:

1) Modify jw_player.seek.js to support JW Player 7.
2) Ensure jw_player.seek.js is loaded after jw_player.drupal.js (new file with Refactor theming), otherwise it won't work.
3) Include a new option for seek that is available as a preset checkbox, so developers can choose to enable seek for only one particular field on a page (such as the primary content video). This is based off of the concept shown here: https://developer.jwplayer.com/jw-player/demos/basic/linking-to-time-off...

Note 1: #3 is not included in this patch, since we're trying to keep this focused on just the existing seek functionality. However we have a patch ready to go once some of the other current patches have been committed.

Note 2: As discussed in the refactor theming thread, this is another issue that relies on the need for a (fairly) unique html_id.