Pre-load doesn't work with 1.1.3
I just reinstall from scratch with the new 1.1.3 release. Pre-bufferization was something I was really waiting for, but it seems not to work :(
Here's my config:
- Server:
- nginx 1.6.2
- php 5.6.29-0+deb8u1
- mysql Ver 14.14 Distrib 5.5.53
- Client:
- Firefox 50.1.0 (Mac)
Did you try to clear your cache ?
I'll try that!
Just to be sure, you're talking about the browser cache right? (not the sonerezh cache)
Yep, browser cache
I... have a doubt suddenly... Is the pre-loading feature to have seamless transition between two songs or just to pre-load the next song, in case it needs to be converted for instance?
The pre-loading feature pre-load the next song in the browser cache to have a seamless transition.
Yep, well, I do have my browser cache that is increasing, but there is still a cut between the songs :(
I'll try with Safari, to see.
Are you sure that you let enough time for the next song to be cached?
I played 3 songs in a row without changing the time, it seems that the next song is indeed loaded, but the transition isn't seamless.
I'm listening to a Wax Radio album: http://www.waxaudio.com.au/albums.html It's downloadable for free, there is a link under the first album cover: MediFire link
Edit: If you don't know Wax Radio, listen to Thunder Busters ;)
BTW Safari is worst than I expected (and I wasn't expecting very much): the songs simply doesn't play lol
@atomiix does it work for you on Firefox? (when using albums with gapless songs)
I'm trying to understand why it's not working on Firefox. I'm pretty sure it worked during my development tests but it appears that it's not working anymore.
Does it work on Chrome? (I don't have it on my machine, I'm quite against it ;) )
Yes, it works on Chrome.
edit: doesn't work anymore. I'm trying to find another way to preload the next song...
@MightyCreak can you try the development branch ?
It seems that it's working both on chrome and firefox now.
Are there changes on the database between master and dev? (how safe it is to downgrade afterwards?)
The current dev is only 1 commit ahead of the master and this is my commit with only JS changes.
Cool! Testing it then ;)
ETA: 2 hours (I got an appointment)
@atomiix nope, there is still a silence between the two songs, although it seems shorter. I cleared my cache and verified that it was the right .js in "Show page source". Is there something I can do in the Firefox dev tools to get you some debug data?
My sonerezh instance isn't local, it runs on a distant dedicated server.
You can lookup on the network tab. When you start playing a song you must see a request with 206 status. When the song is fully buffered, a second request is made, this is the buffering of the next song. Once the first song is finished, you must see one of these 2 cases:
- no new request for the second song
- 206 status but from cache (grey circle instead of green)
In both case, you might see a new request for the 3rd song to be cached.
It's in french, but it seems to work as expected (red line is when I started to play the first song -- both the first second and third songs were already cached):

That being said, we can see that the small cover for the player is still downloaded each time a new songs is played, that might explain the shorter, yet still audible silence:

And more generally, although I've displayed the album several times, all the covers are fetched every time the page is refreshed as well:

It seems that the covers aren't cached for some reason.
Here is my nginx conf:
server {
server_name xxxxxxxxxx.xxxx;
listen 443 ssl spdy;
listen [::]:443 ssl spdy;
# SSL
include snippets/ssl-xxxxxxxxxx.xxxx.conf;
access_log /var/log/nginx/xxxxxxxxxx.xxxx_access.log;
error_log /var/log/nginx/xxxxxxxxxx.xxxx_error.log;
root /var/www/sonerezh/app/webroot;
index index.php;
location / {
#try_files $uri $uri/ =404;
try_files $uri $uri/ /index.php?$args;
expires 14d;
add_header Cache-Control 'public';
}
location ~ \.php$ {
include snippets/fastcgi-php.conf;
fastcgi_pass unix:/var/run/php5-fpm.sock;
}
}
(On Debian 8, nginx/1.6.2)
Well, I think we can't do better than that for a seamless transition. The purpose of this feature was mainly for "slow" internet connections which result with a notable break between 2 songs. The only break is now the time that takes your browser to take the song from its cache storage and start to play. Even if the covers was in cache, I'm pretty sure you would hear a tiny little break between 2 songs.
So, I'm considering this issue closed. You can open another issue for the covers not being cached if you want but that's only nginx configuration.
Thanks for your contribution !
OK, I thought html5 was capable of having seamless transitions between audio stream, that's why.
Fixed then ;)