Re: [squid-users] MP3 files cut short

Fili wrote:
> Hello Squid-people!
>
> On a network that I'm administering there is a weird ongoing problem.
> The basic setup is as follows:
>
> Squid-cache -> Apache webnodes -> NFS Fileserver
>
> Strangly enough on some of the website's embedded mp3 files are often
> cut short to a mere 2sec file (while they are minutes long). When
> performing a hard refresh, the file usually can be played as normal.
> I've tried on several operating systems, using different mp3 files,
> browsers, ISP connections and embedding techniques. One time it works
> the other time it doesn't, it seems to be totally unpredictable.
>
> This all leads me to think that maybe Squid has something to do with it.
> When looking in the cache-spool the mp3-files always seem to have the
> right filesize (this is hard to check for certain).

Check the access.log column which lists how many bytes of reply object
sent to the client on each request.
If these are wildly smaller than the requested file size on Apache then
look closer at the cached object size (squidclient or cachemgr.cgi can
show the list)

The cache file size will be around 1-2KB larger than the MP3 file
itself. Which should not be much

> There also is enough diskspace and inodes available on the caching server.
>
> As a test I've instructed squid to prevent the caching of mp3-files all
> together by using this refresh_pattern:
>
> refresh_pattern -i \.mp3 0 0% 0

Won't work. refresh_pattern determines how long an object gets to stay
in cache. _after_ its already been stored there.

Use "cache deny XX" to prevent things entering the cache.

>
> and also a .htaccess on a test-domain with these lines:
>
> <IfModule mod_expires.c>
> ExpiresActive On
> ExpiresDefault "access plus 2 hours"
> ExpiresByType audio/mpeg "access"
> ExpiresByType audio/mp3 "access"
> </IfModule>
>
> This did the trick in never swapping out, however the problem did not go
> away.

Those apache lines tell Squid not to cache the object at all.
It's likely a transfer problem then...

Check the HTTP headers sent by Apache. (www.redbot.org) If there are no
explicit file sizes (Content-Length) header and Squid set with reply
object max limits things may get truncated without notification.

> I find it very hard to debug this issue and have no idea where to look
> next.
> Maybe I'm on the wrong track in thicking that Squid is involved.

Maybe yes, maybe no. It's good to know for certain either way.

I'm inclined to think its the NFS filesystem sometimes not giving Apache
all the data. The same check of apache access.log as I mention for the
squid one above should tel you if its that.

>
> Does anybody have experienced something similar?

We get infrequent reports of jitter and re-buffering in playback but
your the first with corrupted files in a long time.

> Or maybe has a suggestion as to where to look next?

see above.

>
> Thanks in advance,
> Fili
>
> ==Some version information==
> Debian Lenny
> Squid3 3.0.STABLE8-3+lenny
> Apache 2.2.9-10+lenny4
>

Amos

-- 
Please be using
   Current Stable Squid 2.7.STABLE6 or 3.0.STABLE19
   Current Beta Squid 3.1.0.13