This happened to me as well. It was my own fault, however. I'm running Tiger on a ridiculously slow old iBook, so I decided to get rid of any trace of Spotlight. I renamed the/System/CoreServices/Search.bundle folder, which is responsible for the Spotlight icon in the upper right of the screen. Apparently, the 10.4.2 update placed several updated files back in this folder, but not enough to constitute a valid bundle. So, SystemUIServer, the process responsible for the clock and the other things in that corner, choked when trying to read it. I just renamed the new Search.bundle to something else, and all is well.
If this wasn't your problem, you may want to try disabling any third-party MenuExtras, if you're running any.
(My version numbers on this may be wrong. I just entered the situation with the Windows version.)
In the days of iTunes 4.0.0, there was no attempt at encrypting or otherwise protecting streaming data. The streaming itself is accomplished using a combination of Rendezvous (aka ZeroConf) and a modified HTTP server. This spawned programs like iLeech, iSlurp and various other wittily-named iPrograms.
However, with the next incarnation of iTunes, 4.0.1, Apple got smart. Likely fearing the wrath of the RIAA, a new header was added to all the requests posted to the iTunes serving the music. This value, called Client-DAAP-Validation, looks, smells, and tastes like an MD5 sum. Without the proper DAAP-Validation, iTunes refuses to serve up any content.
Obviously, this broke iSlurp and iLeech. And since there's no easy (read: DMCA-compliant) way to find the source of this value, programs that run separately from iTunes and provide download capabilities are, well, screwed.
Enter myTunes. It's a two-pronged solution to this problem. Behind the scenes, there's a packet scanner watching for requests on the Rendezvous port (3689). When it comes across a request to stream a file, it notes the "URL" and proper DAAP-Validation.
However, all files accessed via the modified iTunes HTTP server are represented via numeric IDs. To get the proper information about the file, myTunes uses a bastardization of the iTunes for Windows Visual Plug-in SDK. For some reason, all visual plug-ins receive notification when the currently playing song in iTunes changes. The myTunes plugin writes this value to the registry, where it is later read by the myTunes GUI and displayed for downloading via libcurl.
This approach raises some interesting DMCA questions. Since the generation of the DAAP-Validation value has not been reverse-engineered, only captured, has anything been circumvented? In effect, myTunes is only a packet replayer.
To counter some of the ill-informed people above, the original file is saved in original format without bitrate modifications. The response to a stream request is the file itself.
Slashdot Mirror
This happened to me as well. It was my own fault, however. I'm running Tiger on a ridiculously slow old iBook, so I decided to get rid of any trace of Spotlight. I renamed the /System/CoreServices/Search.bundle folder, which is responsible for the Spotlight icon in the upper right of the screen. Apparently, the 10.4.2 update placed several updated files back in this folder, but not enough to constitute a valid bundle. So, SystemUIServer, the process responsible for the clock and the other things in that corner, choked when trying to read it. I just renamed the new Search.bundle to something else, and all is well.
If this wasn't your problem, you may want to try disabling any third-party MenuExtras, if you're running any.
Good luck.
(My version numbers on this may be wrong. I just entered the situation with the Windows version.)
In the days of iTunes 4.0.0, there was no attempt at encrypting or otherwise protecting streaming data. The streaming itself is accomplished using a combination of Rendezvous (aka ZeroConf) and a modified HTTP server. This spawned programs like iLeech, iSlurp and various other wittily-named iPrograms.
However, with the next incarnation of iTunes, 4.0.1, Apple got smart. Likely fearing the wrath of the RIAA, a new header was added to all the requests posted to the iTunes serving the music. This value, called Client-DAAP-Validation, looks, smells, and tastes like an MD5 sum. Without the proper DAAP-Validation, iTunes refuses to serve up any content.
Obviously, this broke iSlurp and iLeech. And since there's no easy (read: DMCA-compliant) way to find the source of this value, programs that run separately from iTunes and provide download capabilities are, well, screwed.
Enter myTunes. It's a two-pronged solution to this problem. Behind the scenes, there's a packet scanner watching for requests on the Rendezvous port (3689). When it comes across a request to stream a file, it notes the "URL" and proper DAAP-Validation.
However, all files accessed via the modified iTunes HTTP server are represented via numeric IDs. To get the proper information about the file, myTunes uses a bastardization of the iTunes for Windows Visual Plug-in SDK. For some reason, all visual plug-ins receive notification when the currently playing song in iTunes changes. The myTunes plugin writes this value to the registry, where it is later read by the myTunes GUI and displayed for downloading via libcurl.
This approach raises some interesting DMCA questions. Since the generation of the DAAP-Validation value has not been reverse-engineered, only captured, has anything been circumvented? In effect, myTunes is only a packet replayer.
To counter some of the ill-informed people above, the original file is saved in original format without bitrate modifications. The response to a stream request is the file itself.
General DAAP info