Is deep linking no longer supported?

[stenskjaer]

I can't get deep linking to work with the standalone web player. On the website (http://podlove.org/podlove-web-player/) the link referring to deep linking has an overstrike, but the link itself is dead, so it is very unclear to me what that means.

Is deep linking no longer supported in the web player?

[line-o]

The upcoming version 3 will extend the preexisting support for deeplinks. If you are using the version 2.0.x I would recommend to playback the media for a second or two and have a look at the hash portion of your URL. It should have been changed to something like #t=1:23:45 Sorry, for the outdated docs. We are working on them as well.

[stenskjaer]

Well, the strange thing is that I don't get these URL-updates when playing or pausing the audio, so I wonder if somehow it has to be set up in a special way. I run the player in a simple Python/Flask setup.

[line-o]

Can you provide a URL?

[stenskjaer]

Sure: https://mirash.herokuapp.com/listen/12-1 https://mirash.herokuapp.com/listen/12-1 (far from finished)

Den 08/09/2015 kl. 16.06 skrev Juri Leino notifications@github.com:

Can you provide a URL?

— Reply to this email directly or view it on GitHub https://github.com/podlove/podlove-web-player/issues/251#issuecomment-138569854.

[line-o]

You are using the new player. OK.

[line-o]

It works the same way as before see this example You can test it on your site with https://mirash.herokuapp.com/listen/12-1#t=1:23:45.678

[line-o]

PS: Please bear with us as we are still in beta, too. :smile: And consider to add the duration property to your JSON configuration object.

[line-o]

Wich version are you running exactly? One of the prereleases from bower?

[stenskjaer]

Does the example link you give to my site (https://mirash.herokuapp.com/listen/12-1#t=1:23:45.678) work for you? In my browser it simply starts the recording from the beginning...

The version I use seems to be 3.0.0-alpha.3, according to the bower.json-file.

[line-o]

The problem is still that the player cannot figure out the duration of that episode. Therefore a lot of things do not work properly. I created a test configuration for further experiments. You can see the outcome at http://sandkastenlie.be/playground.html?gist=4ad34be493e17b593e22 If you want to edit it yourself you can do that either directly in the ACE-editor window on sandkastenlie.be or by cloning the gist and replace the gist= parameter in the url with yours.

It seems the problem is that the audio element cannot figure out the duration of the mp3 file. I will look into that matter.

[line-o]

On a side note sandkastenlie.be uses a different form of integration. The source array defines the tracks to be added to the audio or video element.

[line-o]

Heroku does not accept range headers. Therefore deep-linking, skipping and seeking does not work. Accept-Ranges: bytes

[stenskjaer]

Hmm.. That's interesting. Well, I will probably be moving the site to another location later tonight (digital ocean), and then I will be able to see how it goes there. Because despite adding duration, I did not get it to work on Heroku, and probably that's the reason.

[line-o]

Just double-checked that another server responds correctly with a status 206 Partial Content when making a range request. If you want to test it yourself: curl -I http://mirash.herokuapp.com/static/recordings/12-1.mp3 -r 0-20000

[stenskjaer]

I still can't get this to work after moving to Digital Ocean. Try this link: http://188.166.71.115/listen/12-1#t=00:53:38 Or any other in the list on this page: http://188.166.71.115/song-index Does that work in your browser? Can you spot what I am doing wrong?

[line-o]

First, you should not include the player source into your main page. The moderator will replace the matching (audio) tag with an iframe that will include the player itself along with the necessary scripts. We chose an iframe to overcome issues with CSS which is not properly scoped at the moment.

Second, the duration attribute is not set. Even if this is not necessary for the player to work properly the user will have to wait until metadata is loaded before the player can be rendered fully. As the player has to figure out the media duration itself.

[stenskjaer]

Is it really necessary to embed with iframes? The code is generated dynamically based on the specific recording. This way I don't have to create a static pages for each recording which will then need to be maintained and updated individually...

And as I see it, the duration-attribute is set in the <script>-tag. If you look at the source (in Firefox or whatever) you can see the duration attribute at the end of the <script>-tag, right?

Edit: The attachment didn't work, so I removed that. Edit 2: By the way, the deeplinking-example embeds the which-format-file, and that does not have the duration tag set either, right?

[stenskjaer]

A few notes on this. I have still not gotten it to work, but it seems to work the very first time you enter a given time url. But only the first time. Any subsequent attempts do not jump the player to that time. This means that any subsequent visit to the same link (which should therefore start at the same time, e.g. 12:34) only makes the audio-file continue the playback from where you it stopped before the reload.

I am 100% certain that I have set the duration parameter. You can see my test setup here: http://188.166.71.115/listen/10-2#t=12:34

Dont mind the irregularities with the css. I will get to that later.

By the way, I am willing to grant that the iframe-solution is better, and I am probably going to switch to that. But I need to be sure the deeplinking works before getting to that. Note: As you can see I have tested deeplinking with the iframe-solution, and it makes no difference to that.

[Kambfhase]

I have still not gotten it to work, but it seems to work the very first time you enter a given time url. But only the first time. Any subsequent attempts do not jump the player to that time. This means that any subsequent visit to the same link (which should therefore start at the same time, e.g. 12:34) only makes the audio-file continue the playback from where you it stopped before the reload.

This is intentional. The player remembers the playtime in localStorage and continues from there the next time.

[stenskjaer]

Yes, I also thought so. But this means that calling a different deeplink on the same track does not jump the time to that point. And besides that, it only rarely works even the first time I visit a deeplinked url. For instance, does that link above work in your browser?

[Helmi]

it worked for me (never visited the site before) - just in case that helps.

[Kambfhase]

Works for me, too. Can't think of a reason, why it shouldn't work for you, too.

[stenskjaer]

Well yes, actually now I am starting to see some real progress. I have to admit that the iframe-solution actually also solves some problems with the deeplinking (it buffers the file when player is injected, but not otherwise). Thank you for your help so far (all of you!).

But, a question: What is the rationale behind saving the time in localStorage? In my browser this has the effect that only the first deeplink to a recording works. Subsequent deeplinks to the same recording only continues from where you left off. Is that intended? Try some of these links in sequence: http://188.166.71.115/listen/12-1#t=00:00:16.750 http://188.166.71.115/listen/12-1#t=00:49:50 http://188.166.71.115/listen/12-1#t=01:02:56.250

The subsequent links only work if I clear the localStorage in between. Is it possible to disable the SaveTime-function in the player? Otherwise I have to seriously consider calling a clear of the relevant element in the localStorage when deeplinking on the site.

Any thoughts?

[Kambfhase]

Is it possible to disable the SaveTime-function in the player?

No, we do not have an API/config for change the players functionality. This is, so that the user can expect the same functionality whenever they see a PWP on the web.

What is the rationale behind saving the time in localStorage?

The idea is that, when ppl close a web page for whatever reason, the recording will resume later at the correct position in time. VLC recently added such a feature to their player and it is the right thing to do.

Subsequent deeplinks to the same recording only continues from where you left off. Is that intended?

I don't think this is intended but just an artifact from the players internal logic. Will have to think about this.

What is your use case for multiple different deep links?

[stenskjaer]

Yes, I understand how this would often be what is expected.

Let me explain my use case: I am working on a website registering several sessions where different types of Albanian folk songs have been recorded with intervening commentary and conversation. Since the songs are not recorded in perfect order, and some are recorded several times, there is a page index listing all the songs in sorted order (http://188.166.71.115/song-index). It contains a table build with deeplinks to the places in the sessions where the relevant songs occur. I should be possible to browse back to the index and find another song, which is expected to play, although it will happen to be in a session that has been linked already.

[line-o]

Definitely, the behaviour should change to let the deep link overrule a stored playtime in local storage. We have to come up with a solid solution to know when to use which position, though.

[stenskjaer]

But do you have to make the decision? You can't let the player continue at the stored time, unless it receives a timestamp from the url? Well, I can't implement the solution anyways, som maybe I shouldn't try to lecture you on how to change your software :) I think that for now I might just clear the localStorage when the links are clicked.

[Kambfhase]

Even though your use cases is slightly off from what we are used to, I agree this is a bug.

But do you have to make the decision? You can't let the player continue at the stored time, unless it receives a timestamp from the url?

Exactly. At the moment it's the other way round.

Thanks for reporting.

[stenskjaer]

No, sure. Thanks for listening and helping! Do you have any idea about the timeframe of the implementation? I need do decide if I should implement a hack on my site until you have found a solution.

[Kambfhase]

It's done, when it's done. Better start hacking. ☺

[stenskjaer]

Sure thing. Thanks for the help!

Den 3. nov. 2015 kl. 18.28 skrev Frank Hase notifications@github.com:

It's done, when it's done. Better start hacking. ☺

— Reply to this email directly or view it on GitHub https://github.com/podlove/podlove-web-player/issues/251#issuecomment-153425522.

[jonasschoen]

FYI: The deep links don't work for me (OS X 10.11.1, Chrome 46.0.2490.86). It's always playing from the beginning.

[jonasschoen]

And I have a question: Will you add the possibility to share the episode with a specific start time to the new player's share tab? Like "This podcast", "This episode", "This episode, start at ..."

[stenskjaer]

I am aware of the problem with deep links in Chrome (see https://github.com/podlove/podlove-web-player/issues/284). I am struggling to find the reason for this problem (any input is of course appreciated).

I have not really thought to much about the sharing possibilities yet. I am not aware if what you describe is already possible or would have to get implemented from the bottom. Do you know?

[jonasschoen]

Hi @stenskjaer, I don't know whether this is easy to implement. I just know that with the old player the URL changed every few seconds to the new play position and if this will be the case again with the Web Player 3 I would think you can add this to the share tab. But as I'm not a programmer at all I am just guessing.

[stenskjaer]

Well, as I understand it, the timestamp in the addressbar should actually already be a feature implemented in development of version 3. But it doesn't work on my installation though, and honestly I have no clue why, but I have the impression that all these problems all go back to the same cause. Obviously, I am trying to find that cause...