PDA

View Full Version : playback position slider



joggs
2008-08-27, 00:10
Any suggestions how to build a playback position slider?

Either poll for it to the CLI each x seconds which feels like a lot of unnecessary traffic.

Another way could be to subscribe the value which feels like a lot of traffic but less than the above because of the lack of requests.

another maybe the best one could be to do it like on the duet remote. Click on a button that you want to ffwd and a slider pops up, you get the current position, length of song and sends back the new position to the cli. this is the cheapest solution traffic wise but will not display the current position of the song until you click the button.

Well, any suggestions? Do i need to care about frequent requests to get the current position? how much does it affect the server?

pippin
2008-08-27, 01:12
I don't fully understand what you want to do.
But you can have a look at the JavaScript code in iPeng, I did a slider there.
Here's how it works:
Displaying elapsed time: Like the other skins: I set a timer that advances the slider each second and every 15s I calibrate the actual position by polling the server.

To MOVE the position within the track you can touch and drag the slider handle, but I do not update the playback position immediately but only after you release it (would be too much "jumping around" if done otherwise, IMHO). Instead it will display the position in mm:ss format while you drag the handle.
When you release the handle it will jump to that position (CLI, "time", I think) and restart the one-second-timer.

The code is in status.js and statusplayer.js (actually, I think it's all in statusplayer.js).

joggs
2008-08-27, 01:27
Yes, I have thought about doing it your way and if I do it that way I guess I have to implement an event that trigger if you press pause or stop that stops the one second timer so that the slider won't continue ticking on and on.

Thanks for your suggestion.

pippin
2008-08-27, 01:37
Yes, I have thought about doing it your way and if I do it that way I guess I have to implement an event that trigger if you press pause or stop that stops the one second timer so that the slider won't continue ticking on and on.

Thanks for your suggestion.

Yes, I forgot to mention that. Whenever you press play/pause or power the timer gets initiated or stopped. The same is true when you recognise a state change through the 15s-polling.

mherger
2008-08-27, 01:46
> recognise a state change through the 15s-polling.

How accurate is this timer on the iPod? I'm using 5s intervalls - and even
this often isn't very accurate. Timer's drifting more than a second
between polls, depending on the load. Have you seen this too?

Michael

pippin
2008-08-27, 01:55
> recognise a state change through the 15s-polling.

How accurate is this timer on the iPod? I'm using 5s intervalls - and even
this often isn't very accurate. Timer's drifting more than a second
between polls, depending on the load. Have you seen this too?

Michael
Yes.
On "normal" operation, the timer is VERY accurate on the iPod, I was surprised about that, but sometimes, especially if you've got a lot of 3rd party apps running it can get pretty slow and then the timer is getting inaccurate, too.

But if you do a clean start, e.g. from a reboot and you don't have too much background JS activity 15s is fine. The iPod is not thought to have too much backgroun d activity going on so I think that's why it's better than on a PC or Mac.

5s intervals would probably even make it worse because you increase background activity.

mherger
2008-08-27, 02:28
> 5s intervals would probably even make it worse because you increase
> background activity.

You might be right there. Yesterday I've done some profiling on a MacBook (core2duo), a Vista VM on top of XP, and an eeePC, all showing the same server's web UI. The poor eeePC is working hard on one single background request. I was wondering whether we should change the interval, or (yes!) make it configurable, as those requests not only hit slow clients, but servers even more.

--

Michael

pippin
2008-08-27, 05:19
> 5s intervals would probably even make it worse because you increase
> background activity.

You might be right there. Yesterday I've done some profiling on a MacBook (core2duo), a Vista VM on top of XP, and an eeePC, all showing the same server's web UI. The poor eeePC is working hard on one single background request. I was wondering whether we should change the interval, or (yes!) make it configurable, as those requests not only hit slow clients, but servers even more.


15s works pretty well for me.
The main issue (at least on iPod) is not the accuracy of the progress bar but when you catch other events, like state changes (play/pause...) track changes and - especially important but iPod specific - catching a "turn on" event - iPod will stup executing the browser when the screen saver kicks in and will continue at just that position when it's restarted. If that's 20 min later you are typically in a totally different position on the playlist. I tried to get around that by detecting the delay (checking for time changes in a 2s interval thread) and triggering a reload but that's not perfect either because you typically have no WLAN connection if you trigger that event too early.
So 15s is a good compromise for iPeng and it keeps traffic a bit at bay.