Radar: Skipping Ahead Broken in Some Podcasts

The bug occurs in 2 out of 10 well-known tech podcasts and can be reproduced in iTunes 11. This isn’t related to iOS or Mac development but since I spent much time in researching this, I want to post it on my blog as well. Also I believe that if people file better bug reports Apple has more reason to fix the bugs.

I noticed then when I was investigating why skipping in some of my own podcasts didn’t work. Turns out that the reason for that was a combination of ngnix + WordPress Multi-User + one pesky rewrite rule. But this is not the root cause that some podcasts are having.

If you know how to read (and understand HTTP headers) let me know in the comments if you spot a possible explanation for this bug.

Filed as rdar://13490726 and on Open Radar.

iTunes 11.0.2: Skipping Ahead Broken in Some Podcasts

Summary

Skipping forward in mp3 podcasts is broken.

Steps to Reproduce

• In iTunes: File – Subscribe to Podcast, enter http://leoville.tv/podcasts/twit.xml
• double click on any older podcast episode, it will start to play at 00:00
• now click in the playing control progress track to try to skip to a later point

Expected Results

• playback should skip to the clicked position

Actual Results

• playback continues stubbornly, no HTTP ranged request for new position is sent

Regression

I checked 10 other podcasts and found a second one that has the same issue with iTunes. I can provide you with the list of my tests.

Notes

When you click on the track iTunes seems to be sending the Range: header to state the position requested on the podcasts that work. It does not make a difference whether or not the podcast uses m4a or mp3 format. Also Some do a redirect for tracking downloads, some don’t.

I also tested the same problematic podcasts with the iOS Podcasts app 1.2. There I cannot reproduce the problem.

It appears that some combination of redirection and/or headers in the response disable the random access functionality in iTunes for these specific podcasts and it no longer sends the range header.

The following examples are done with Charles debugging proxy.

Example of functioning communication

>>> request from start:

GET /audio/mbw/mbw0340/mbw0340.mp3 HTTP/1.1
Host: twit.cachefly.net
User-Agent: iTunes/11.0.2 (Macintosh; OS X 10.8.3) AppleWebKit/536.28.10
Accept: */*
Cache-Control: no-cache
Connection: close

<<< response:

HTTP/1.1 200 OK
Server	CFS 1228
Date	Sat, 23 Mar 2013 17:13:15 GMT
Content-Type	audio/mpeg
Connection	close
ETag	"7086e985aab6289a32b65ceec1ab6225"
X-CF1	dC.ams1:cf:cacheA.ams1-01
Content-Length	48421137
Last-Modified	Tue, 05 Mar 2013 23:08:26 GMT
X-CF2	L
Accept-Ranges	bytes

>>> skip ahead request

GET /audio/mbw/mbw0340/mbw0340.mp3 HTTP/1.1
Host: twit.cachefly.net
User-Agent: iTunes/11.0.2 (Macintosh; OS X 10.8.3) AppleWebKit/536.28.10
Accept: */*
Cache-Control: no-cache
Range: bytes=20236119-
Connection: close

<<< skip ahead response (OK)

HTTP/1.1 206 Partial Content
Server	CFS 1228
Date	Sat, 23 Mar 2013 17:13:19 GMT
Content-Type	audio/mpeg
Connection	close
ETag	"7086e985aab6289a32b65ceec1ab6225"
X-CF1	fC.iad2:cf:cacheB.iad2-01
Content-Length	28185018
Last-Modified	Tue, 05 Mar 2013 23:08:26 GMT
X-CF2	L
Content-Range	bytes 20236119-48421136/48421137

Example of non working skip ahead, different podcast

>>> Initial request from start

GET /twit/twit0393.mp3 HTTP/1.1
Host: aolradio.podcast.aol.com
User-Agent: iTunes/11.0.2 (Macintosh; OS X 10.8.3) AppleWebKit/536.28.10
Accept: */*
Cache-Control: no-cache
Connection: close

<<< Initial request response

HTTP/1.0 200 OK
Server: Apache
Last-Modified: Mon, 18 Feb 2013 04:50:23 GMT
ETag: "3e5e579-4d5f87677a1c0"
Accept-Ranges: bytes
Content-Length: 65398137
Content-Type: audio/mpeg
Cache-Control: max-age=7776000
Expires: Fri, 21 Jun 2013 19:52:23 GMT
Date: Sat, 23 Mar 2013 19:52:23 GMT
Connection: close

>>> at this point clicking in the progress bar does not send a new ranged request and skipping ahead does not work

Categories: Bug Reports