My use case for this - I am tracking and logging process to what has been listened to in a playlist (audiobooks / podcasts). When returning to the player at a later date, I wish for the user to start where they left off.
@danpastori: I think Jacob’s feature use case is very interesting. Do you think we should track that as a separate feature? This is different from what we understood yesterday.
just to clarify - I have all of that data stored in my database, I don’t want the player to store any of that data in cookies or local, I just want the Plyr to start where I tell it to, without having to load the track multiples times or at 00:00 and then 90 seconds in. (which I believe it’s currently doing)
Love the idea! This is definitely one feature with a few parts to it.
What I’m thinking is we add a timestamp that we set along with the starting song. There are two approaches I’m bouncing around in my head to make this work from a configuration perspective.
Adding A Config Variable
To initialize the start song time stamp on Amplitude.init() like so:
This would be easy to expand if other initialization measures that aren’t covered for. Just a though. If you can think of any other start scenarios besides what we discussed, I’d recommend going with this route so we don’t flood the config.
How this would work
Mainly for me as I think about this, but we’d have to override the preload so we don’t have it loading twice. What this would do is if there’s a start song & start time, we’d initialize the start song on the audio object, then set the time, but set preload to none so it doesn’t start loading right away and we end up with a double load.
If there are any other thoughts on this feature, let me know and we can plan out the implementation.
I think an object is the right choice - as you said, more scalability in the future. The only other thing I have to also initialize is playback speed, as I want users to have it play at the speed they select, when they return in the future.
I also admit one of the more confusing aspects of this JS to me is anything involving plugins (I don’t want to get off topic but I can expand on my confusion if you want).
If you want to open a thread and share your ideas, it’d be much appreciated ! We are discussing the future of AmplitudeJS with a 6.0 release in early discussion. Besides fixing the immediate bugs in 5.3: https://github.com/521dimensions/amplitudejs/projects/16 we will be looking at the next level of the project soon.
I made a serious typo in my previous post, and wrote plugins instead of playlists. I find playlists, involving the settings // data-handlers that connect to html elements to be confusing. I don’t need them for my project though so it’s not an important request or complaint or anything on my end.
I think i found in dist/amplitude.js why start_song parameter is ignored (the original github issue), but i don’t know wich files need to be edited for a proper PR; i am more comfortable with php PR than js projects
No worries, I don’t understand JavaScript at all I am a server guy and a designer hahaha.
If you think it is something that is more of a bug than a feature, I would open a bug on Github and use the links from Github files to explain where you think the issue is.
Any help we can give @danpastori will only make it easier for him to take a look at it