I'm in love with my Sonos set-up. It's one of the easiest music systems I have ever installed and it finally gives Ellen and me access to our entire CD collection AND much, much more. This weekend I even purchased a second Play5 unit to have music in our Library. It all started more than a year ago when I dug into the different solutions for a centralized music library. I selected three potential candidates to get our relatively large music library in the "home cloud". Our requirements were relatively simple:
At that moment in time I couldn't find anything that fitted those requirements. The biggest hurdle was the "easy access" requirement. Every solution required some kind of controller, be it a smart phone, a general purpose tablet or a dedicated controller. One year later, our requirements changed as we now have enough smart devices that can double as controllers. iTunes combined with Airport Express
A general purpose Media Tank:
SONOS:
More than a year ago, SONOS wasn't the solution as we were running short in the controller department. Since then Ellen and I have both an Android smartphone which removed the last hurdle for creating our SONOS-powered musical "home cloud". Fixing cover art issuesI imported our music collection of 600+ CDs into iTunes over the years. iTunes did a great job at adding covers where it could and those covers iTunes couldn't find, were added later using CoverScout. iTunes sampled everything using Apple lossless compression, resulting in thousands of *.m4a files. *.m4a files allow inclusion of cover art, yet Apple decided to optimize this by storing cover art in a centralized folder. As a result when I copied my *.m4a files to my NAS I noticed that not all albums had cover art. As of a certain version of iTunes, cover art was no longer part of the *.m4a file but stored in a hashed directory. Moreover, some cover art that was added using CoverScout didn't show up on mobile devices, yet it did show up on the standalone SONOS applications. Below is an example of this... note the missing "At the Ryman", "Faith no More" and "Bach" covers. Cover art that was available in iTunes, but didn't show up in any of the controller applications was added by using a nifty little tool called "Save Album Art to Album Folder" which basically extracts cover art from iTunes, regardless how it was added to the library. You end up with a folder full of *.jpg files which need to be copied to the NAS where your SONOS library resides. Simply copy them in the right album folder and rename the file to folder.jpg and the SONOS controller apps will pick up the cover art. I have some *.m4a files with cover art, which the SONOS application on mobile devices doesn't want to display. The trick here is to remove the embedded cover art and replace it with a folder.jpg file. I found a toolkit on Linux that works perfectly to list, add and remove covert art from mp4-files. You can find it here (MP4v2). Follow the instructions to install the toolkit, some Linux distributions contain the toolkit in their standard repositories. You might first try to add it with "yum install" or "apt-get install". Below are some screenshots that show there is actually cover art in the Emmylou Harris files: Removing and adding cover art is done respectively with mp4art --remove and mp4art --add. Check the man-pages for detailed information on all options. I removed the cover art as shown below: I looked for a suitable cover via Google, copied it to the NAS and renamed it to folder.jpg. Let's see if this actually worked and the mobile SONOS application shows the cover now: Getting your covers peachy on your SONOS cloud takes some manual fiddling around, especially when you digitize your CDs with a recent version of iTunes. As the more recent iTunes no longer stores cover art in the *.m4a files, you'll need to extract them from iTunes and copy/rename them manually to the appropriate folder on your NAS.
It might be a bit of extra work, but in the end it's worth it.
3 Comments
Remember my "happy eyeballs" post? Well, it looks like it's causing issues with YouTube clips both on MacOS X (Mountain Lion) as IOS (6). The symptoms? Clips that refuse to launch and result in a black screen filled with pseudo static and a "An error has occurred. Please try again later." Even worse, some clips actually start to play and stop after a while. BTW, the error message is very helpful Google, thanks. The issue exists on Safari and Firefox; Chrome seems to immune. I was quite sure it had to do something with the dual stacked IPv4/IPv6 set-up we use at home as disabling IPv6 on my MBP made the issue disappear. But what is causing the problem? And is there a fix? Googling quickly pointed to "happy eyeballs", which confirmed my findings after some observations and a good deal of TCPdumping. But why would this happen as "happy eyeballs" was created to prevent bad user experience on IPv6 in the first place. To understand what happens while viewing a YouTube clip, I used HTTPfox on Firefox. HTTPfox is basically a local proxy which shows all the requests generated by the page you're visiting. The following screenshot shows a clip I was viewing and that stopped halfway... Digging into the output of HTTPfox one can easily retrieve the URLs that deliver the actual video stream. Google has its own Content Delivery Network (CDN), which presumably tries to deliver data as close as possible to the end user.
In the above example the content cache was:
And now it becomes interesting as this host resolves to:
How and where the actual caching node is defined in the HTTP exchange is not really clear to me, but typically this is "somewhere" defined through geoIP lookups of the source IP of the requester. The obvious issue here is that my geo-location is completely different over IPv4 and IPv6 as I use a Hurricane Electric tunnel for my IPv6 connectivity. And even if my provider would deliver native IPv6 connectivity, it will still show a very different routing path. While one is looking at a YouTube clip, multiple HTTP GETs are send out to the content cache to retrieve gradually the content. And here lives the culprit! As "happy eyeballs" kicks in and tries to deliver connectivity over the "best path", it might actually change its decision during the session. In other words, one HTTP GET can go out over IPv4 but seconds later, the next HTTP GET would go over IPv6. In theory this shouldn't be a problem if all caches are equal, but it depends heavily on how the caches actually operate and the application works. If sessions are involved i.e., are we sure that the IPv4 and IPv6 are actually the same machine(s); if not how is the system supposed to stitch the IPv4 and IPv6 session together? I believe this is exactly what happens with Safari and Firefox on YouTube. The fact that my IPv4 and IPv6 routing is completely different and the likelihood that the IPv4 and IPv6 infrastructure is not the same on the CDN side, might very well result in lost, unknown and zombie sessions. For a pseudo streaming application like HTTP-based QuickTime streams or YouTube clips, "happy eyeballs" is very dangerous. Pseudo streaming applications send chunks of media data and rely on the fact that the network is faster than the realtime stream. For this specific clip it sends packets of 1,6 MB according to the HTTPfox output. Conclusion: the browser should not only rely on the OS implementation of "happy eyeballs" as it could change IP stacks during a session or HTTP conversation with potential undesired side effects. It should stick to one IP stack after the initial decision handler to preserve session integrity. As to view YouTube clips, I think I'll stick with Chrome until Apple and Mozilla engineers have figured out a way to fix this issue. |
About this BlogIT Technology, networking, Apple, iDevices, Android, IPv6, DNS. Archives
November 2015
Categories
All
|