Just added latest .mp3 files to site and found that:
1. Using Firefox - when .m3u link is clicked,
2. the window switches from Firefox to iTunes but does not load the .mp3 file
3. the .m3u file end up on the desktop
4. iTunes does nothing with the .m3u file
All worked fine until iTunes 7.6.
(older version of iTunes on PC works fine on same web files.)
Any ideas? Thanks!!
12" PowerBook,
Mac OS X (10.4.11),
Mostly Mac, some Win
Safari on the PowerBook also just drops the .m3u file on the Desktop. I'm in the process (slow) of updating Windows XP on one of my Win machines and will be installing Safari's new beta on that to see what happens.
iTunes 7.6 no longer plays m3u files. Your choices are to downgrade back to v7.5 assuming you have backups of the app & library files.
Failing that, your next choice is to configure Quicktime to launch when you click on a m3u file.
The following suggestion comes from emusic's forum posted by user "mrbuzzbozz":
Just got an email from eMusic on the issue and able to use Quicktime within the browser. For anyone else struggling with the technology, here are instructions for using Quicktime, within Firefox, using a Mac.
To set QuickTime to be your default M3U player
(our 30 second samples are M3U files):
1. Go to System Preferences (for your Mac)
2. Click on QuickTime
3. Make sure the Plug-In tab is highlighted at the top and
click on the "MIME settings..." button.
4. Expand the MP3 section and place a check mark in the
box for MP3 Playlist File.
5. Click the OK button and then close the System Prefs.
I haven't upgraded iTunes yet to 7.6, but witnessed this behaviour on a friend's machine.
When I looked into trying to figure it out, my first thought was that it might be a line terminator issue, which it appears not to be. I clicked and saved the same .m3u from eMusic in Safari (1), Firefox (2), and via curl (3) to see what I could discover.
First off, all three files have CRLF terminators, so that doesn't seem to be the issue.
% file 16079502*.m3u
16079502(1).m3u: ASCII English text, with CRLF line terminators
16079502(2).m3u: ASCII English text, with CRLF line terminators
16079502(3).m3u: ASCII English text, with CRLF line terminators
Next, I thought I'd compare the files using md5...
...which ended up showing me that every .m3u downloaded from eMusic is different anyhow, because they create a unique URL each time you make the download request. I proved this to myself by running the same curl command repeatedly and watching the sum change every time, and then running it and just plain looking at the URL change each time. So, that became and invalid test.
Moving on with Taxinator's approach, I checked out the metadata for each of the files.
Yep, Firefox's file is the only one that has a non-zero value in the metadata.
Why would this be happening, and to be really blunt, why would simply reading and writing the same text file via Applescript (the file un fcker script mentioned all over the net) actually fix this?
How does this meta data get set, and reset?
I find it difficult to believe that this is an issue caused by Firefox, since the symptom arose with an update to iTunes, not Firefox. Needless to say, Firefox's behaviour had not changed at that moment.
So, did iTunes suddenly become incredibly strict about metadata where it had not been before?
Anyone fine a more reasonable fix for this issue other than to force using Quicktime or recreating every .m3u file downloaded via Firefox?