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
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
- playback should skip to the clicked position
- playback continues stubbornly, no HTTP ranged request for new position is sent
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.
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
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