Tag: AppleTV

Some new notes about AppleTV

Another braindump so I can actually put in public what I’ve been doing in my spare time lately, given that most likely a lot of that won’t continue in the next months, as I’m trying to find more stable, solid jobs than what I’ve been doing as of lately.

If you follow me for a long time you might remember that a few years ago I bought an AppleTV (don’t laugh) for two main reasons: because I actually wanted something in my bedroom to watch Anime and listen to music and was curious about the implementation of it from a multimedia geek point of view. Now, a lot of what I have seen with the AppleTV is negative, and I’m pretty sure Apple noticed it just as well as I have. Indeed they learn from a lot of their previous mistakes with the release of the new AppleTV. Some of the “mistakes they learnt from” would probably not be shared by Free Software activists and hackers, as they were designed to keep people out of their platform, but that’s beside the point now.

The obvious problems (bulkiness, heat, power) were mostly fixed in hardware by moving from a mobile i686-class CPU to an ARM-based embedded system; the main way around their locks (the fact that the USB port is a standard host one, not a gadget one, and it only gets disabled by the lack of the Darwin kernel driver for USB) is also dropped, but only to be replaced with the same jailbreak situation they ahve on iPhone and other devices. So basically while they tried to make things lot more difficult, the result is simply that they hacked it in a different way. While it definitely looks sleeker to keep near your TV, I’m not sure I would have bought it if it was released the first time around this way.

At any rate, the one I have here is in its last months, and as soon as I can find something that fits into its space and on which I can run XBMC (fetching videos out of a Samba share on Yamato), I’ll probably simply get rid of it, or sell it to some poor fellow who can’t be bothered with getting something trickier but more useful. But while I want the device to actually accept the data as I have it already for what concerns Anime and TV series (assuming I can’t get them under decent terms legally), some months ago I decided that at least the music can bend over to the Apple formats — for the simple reason that they are quite reasonable, as long as I can play them just fine in Europe.

Beside a number of original music CDs (Metal music isn’t really flattered by the compression most online music stores apply!), I also have (fewer) music DVDs with videos and concerts; plus I sometime “procure” myself Japanese music videos that haven’t been published in the western world (I’m pretty much a lover of the genre, but they don’t make it too easy to get much of it here; I have almost all of Hikaru Utada’s discography in original forms though). For the formers, Handbrake (on OS X) did a pretty good job, but for the new music videos, which are usually in High Definition, it did a pretty bad job.

Let’s cue back FFmpeg, which, since last time I ranted actually gained a support for the mov/mp4 format that is finally able to keep up with Apple (I have reported some of the problems about it myself, so while I didn’t have a direct bearing in getting it to work, I can say that at least I feel more confident of what it does now). To be honest, I have tried doing the conversion with FFmpeg a few times already; main problem was to find a proper preset for x264 that didn’t enable features that AppleTV failed to work with (funnily enough, since Handbrake also uses x264, I know that sometimes even though iTunes does allow the files to be copied over the AppleTV, they don’t play straight). Well, this time I was able to find the correct preset on the AwkwardTV wiki so after saving it to ~/.ffmpeg/libx264-appletv.ffpreset the conversion process seemed almost immediate.

A few tests afterward, I can tell it’s neither immediate in procedure, nor in time required to complete. First of all, iTunes enforces a frame size limits on the file; while this is never a problem for content in standard definition, like the stuff I ripped from my DVDs, this can be a problem with High-Definition content. So I wrote a simple script (that I have pasted online earlier tonight but I’ll publish once polished a bit more) that through ffprobe, grep and awk could maintain the correct aspect ratio of the original file but resize it to a frame size that AppleTV is compatible with (720p maximum). This worked file for a few videoclips, but then it started to fail again.

Turns out, 1280×720 which is the 720p “HD Ready” resolution, is too much for AppleTV. Indeed, if you use those parameters to encode a video, iTunes will refuse to sync it over to the device. A quick check around pointed me at a possible reasoning/solution. Turns out that while all the video files have a Source Aspect-Ratio of 16:9, their Pixel Aspect-Ratio is sometimes 1:1, sometimes 4:3 (see Wikipedia’s Anamorphic Widescreen article for the details and links to the description of SAR and PAR). While Bluray and most other Full HD systems are designed to work fine with a 1:1 PAR (non-anamorphic), AppleTV doesn’t, probably because it’s just HD Ready.

So a quick way to get the AppleTV to accept the content is simply to scale it back to anamorphic widescreen, and you’re done. Unfortunately that doesn’t seem to cut it just yet; I have at least one video that doesn’t work even though the size is the same as before. Plus another has 5.1 (6-channels) audio, and FFmpeg seems to be unable to scale it back to stereo (from and to AAC).

Rygel; replacing MediaTomb?

I’ve ranted about overlays leaving notes about Gnome overlay I had to fight with that because of Rygel which reportedly needed the new (testing) version of Gtk+.

Now, my interest in Rygel is so that we can rid of MediaTomb in Portage; I added it myself, when I tried to make use of my PlayStation 3 for streaming video (mostly anime and Real Time with Bill Maher). It actually never worked as well as I itnended for very long; it needed proper transcode support, and what was there was incomplete. Also, the code itself was messy and hacky, with commented-out code still there, and bundled libraries. When I replaced my Samsung TV with a Sony Bravia last year, I was also hoping MediaTomb worked with that (because it actually supports UPnP by itself alone), but that wasn’t the case.

At any rate, with MediaTomb failing to keep up with releases, cleanup code, and so on so forth, I gave up vastly on the UPnP idea; even using the XBMC instance on my AppleTV, the best seems to be using Samba instead. This until a couple of weeks ago when I started worrying about my bedroom’s media outlets. I have three UPnP-enabled devices (Bravia TV, PlayStation 3 and XBox 360), but I use an always-on AppleTV to play my stuff; that really wounds like a waste.

Even more so given that the AppleTV doesn’t really play Full HD content, not with XBMC at least; and my hopes for it to become useful, actually trusting in Apple’s declaration that they would have brought TV series to the iTunes Store in Europe vanished quite a long time ago. And to reinforce the fact that I made a totally shitty deal when I bought this AppleTV, rumors have that the new version of it will be a totally different product, cheaper and with no on-board storage… now I can guess the reason for that; as I said I stream my video from my main storage (Yamato itself), but I actually am glad that the AppleTV I have has 160GB storage so I can keep a copy of my photos, and of all the music I have, in lossless format (ALAC).

At any rate, I wanted to give UPnP/PlayStation 3 another chance; and the current way to do that is using Rygel, developed by the Gnome community and tied to GStreamer (even though I have a number of personal reserves against it). Now, thankfully, most of the needed code was already around in Portage, and Petteri had a partial ebuild for an older Rygel version, so I spent a night trying to work it out. It needs the GUPnP stack that is developed together with it obviously, and it relies on Vala for a big part of it including the GUI.

The “stable’ version is from quite a long time ago; and if you know software enough, you know that ”stable” means “unmaintained” when its release version ends with a “.0”. So I went for the development series, 0.7. And updating the dependencies, it turned out to need Gtk+ 2.21, with all the related trouble. Funnily, Arun notified me that the configure.ac script actually outright lies, it requires 2.21 just because it can, but it does not need it, and works fine with 2.20; I haven’t had much time to update the ebuilds so that they ignore the dependency, but I was able to test it for a little while with 2.21.

I’m sincerely not excessively impressed with it; of course it works definitely better than MediaTomb, and I guess that UPnP/DLNA are messed up enough that they have trouble to actually get them working properly, but… it seems like for the European version of the Bravia TV they always transcode to mpeg2/mp3 (which I’ll tell you, is crappy quality; the TV can do DVB-T HD out of the box, I guess it has support for decoding H.264/AAC), and even the PlayStation3 has trouble identifying some files, even when they should play correctly on local storage; and PS3 is declared to be their platform of choice.

The interface itself is quite difficult to work on, it has no way to monitor the scan status; it also only index files if the extension is one of those they recognize and…. funnily enough they recognize .mp4 files but not .m4v files, which are just the same thing; rename the latter to the former, and voiltà, it works… so you got a possible bug there. I haven’t reported it but on IRC, where I was suggested to check the config files that… are quite a bit messed up.

I’ll fix up in tree some ebuilds for Rygel at some point this weekend if I can get the time to, it’s still a pretty good replacement for MediaTomb, it’s just something I’d probably use rather than XBMC-over-Samba.

Of course this is still not solving my problem with video playback; especially since it does not work with softsub that are overly common with J-Drama…

Playing subtitles nicely with Boxee (and XBMC) on AppleTV

I have written yesterday that I had some issues with Boxee and subtitles . It turns out that my Matroska muxing was not needed and indeed it plays .srt subtitles just fine, but the default install of Boxee selects a font that is not installed by the AppleTV OS. At least not in the 2.3.1 software I’m running; probably this is quite the same problem I encountered with XBMC, which disappeared after tinkering with the settings.

There are two ways to solve the issue properly? Well, the AppleTV software provides the Times New Roman font, but I don’t really like serif fonts, in general. I tend not to use them at all, finding sans-serif much more readable. None of my systems have serif as default font. Since copying over the Microsoft fonts is not something I’m likely to do (I don’t like them that much that I’d go as far as breaking an EULA to have them), I just took the latest tarball of DejaVu fonts and copied over the DejaVuSans.ttf file in my AppleTV’s /Library/Fonts (scp’d over; luckily the OpenSSH installed by the new patchsticks support that; I remember the first patchsticks for software 1.1 used the copy from Tiger and only supported protocol version 1), and then changed the configuration file.

If you’re interested in what the change consists, the file you need is AppleTV.local:~/Library/Application' 'Support/BOXEE/UserData/guisettings.xml (remember to quote the space twice, since it needs to be quoted on both command-line and remote server), replacing BOXEE with XBMC if you’re using the latter. You can download the file on a different box and then the value to change, using XPath to represent the path (because it makes sense to humans too) is /settings/subtitles/font . Set it to the name of the .ttf file (without extension) you uploaded in /Library/Fonts and the trick is done.

Now, while Boxee has some proprietary stuff and I don’t really like that tremendously, it still is based upon XBMC which seems quite nice; also, it seems to be more oriented toward the six buttons interface of the Apple Remote that the AppleTV uses, which is a nice thing since I run it there. The subtitles’ fonts problem is probably the only one that is very bad; the skin I don’t like but I guess that’s not much of a problem by itself; the fact that it still does not start up and stop together with the AppleTV is nitpicking…

Altogether, I’m quite happy since it actually allows me to watch my stuff on the TV almost flawlessly!

The mad muxer

I have expressed my preference for the MP4 format some time ago, which was to be meant mostly over the Ogg format from Xiph, most of the custom audio container formats like FLAC and WavPack (to a point; WV’s format could be much worse), and of course the AVI format. Although I do find quite a few advantages of MP4 over Matroska, I don’t despise that format at all.

The main problem I see with Matroska, actually, is the not so widely available implementation; I cannot play a Matroska video on either my cellphone (which, if somewhere were to think about it, is a Nokia E71 right now, not an iPhone, and will probably never be, I have my limits!), the PlayStation3 or the PSP. Up to last month, I couldn’t play it with my AppleTV either, which was quite a bit of a problem. Especially considering a lot of Anime fansubbers use that.

Now, since I was actually quite bored by the fact that, even though I was transcoding them, a lot of subtitles didn’t appear properly, I decided to try out XBMC; it was quite a pleasing experience actually, the Linux-based patch stick works like a charm, without going too much in the way of infringing Apple’s license as far as I can see, and the installation is quite quick. Unfortunately the latest software update on AppleTV (2.3.1) seems to have broken xbmc, which now starts no longer in fullscreen but rather in a Quartz window in the upper half of the screen.

So I ditched also XBMC (for now) for a derivative, boxee which, while being partially proprietaryware, seems to be a little more fine-tuned for AppleTV; it’s still more free software than the original operating system. Both XBMC and Boxee solve my subtitles problem since they both have a video calibration setup that allows to tell the software how much overscan the LCD panel is doing, and which pixel size ratio it has. Quite cool, Apple should really have done that too.

Also, I started using MediaTomb to serve my content without having to copy it on the AppleTV itself; this is working fine since I’m using ethernet-over-powerline adapters to connect the office with my bedroom, and thus there is enough bandwidth to stream it over. Unfortunately, here starts the first problem: while I was able somehow to get XBMC to play AVI files with external .srt subtitles, it fails on Boxee. Since the whole thing is bothersome anyway, I wanted to try an alternative: remux the content without re-encoding it, in Matroska Video files, with the subtitles embedded in them as a third track.

This seems to work fine from an AVI file, but fails badly when the source is an MP4 file, the resulting file seems corrupted with MPlayer and crashes Totem/GStreamer (that’s no news, my dmesg output fills easily with Totem’s thumbnailer’s crashes when I open my video library). Also, I have been yet unable to properly set the language of the tracks, which would help me to have the jap-sub-eng setup automatic on XBMC. If somebody knows how to do that properly, I’d be glad.

Anyway, there it goes another remuxing of the video library…

Can you make it?

After my post about AppleTV conversion with FFmpeg I’ve been working on trying to streamline my conversion procedure even further. The low-quality of the conversion is rarely an issue for me since what I’m uploading in there is usually something I watch before I can get to the DVDs. I have sometimes to add borders or subtitles would disappear over the edge of the TV, but not always since the content might not be subtitled.

Unfortunately it seems like GNU make has issues where paths with spaces are involved, and there are some other things that are clumsy and require me to write the same rule twice to get it to properly work. At the end it doesn’t seem like GNU make is the right tool for the job, so I gone looking for something different.

The rake option was discarded right away since rake does not parallel-execute, so I went on looking for something. I just needed a make-workalike, rather than a build system, or even a scripting language with proper support for parallelising, something like bash’s for construct but having a number of concurrent jobs applicable to it.

Looking for that in Google I came through an article about Make alternatives on freshmeat. It looked promising at the start but then committed the mistake of confusing make itself and higher level build systems, and went on for most of the time to speak about alternative build system. It still had a few names, among which I took out cook that at first looked interesting.

The syntax seems to be similar enough to make to be easy to grasp, and still allows much more flexibility than the standard make. So what’s the catch? Well, the catch begins with it using yet another strange SCM (like Pidgin’s monotone wasn’t annoying enough), but it doesn’t stop here.

Out of habit I check the ebuilds when I want to try new software, it helps to know whether the original code is so messy that we have to patch the hell out of it; in addition to this for buildsystems, having complex ebuilds means that the build system architects themselves don’t have very clear ideas on what it’s needed. Seems like this was a good idea:

src_compile() {
        econf || die "./configure failed"
        # doesn't seem to like parallel
        emake -j1 || die
}

src_install() {
        # we'll hijack the RPM_BUILD_ROOT variable which is intended for a
        # similiar purpose anyway
        make RPM_BUILD_ROOT="${D}" install || die
}

So a make-replacement that on its homepage declares to be able to build in parallel… has a build system that does not build in parallel? Indeed the makefile is an absolute mess; while it’s true that you don’t need to know one tool to write a replacement for it (that is not a drop-in replacement), it still would help. I could understand the mistake with multiple output rules since the cook syntax diverges from make’s in that regard; I started understanding much less the mistakes about temporary file creation, but I was really put off by the fact that it does not even know how to use the -o switch at the compiler to get it to output to a filename that is different from basename.o.

Let me say one thing: before you decide to write a tool that is better than $something, try at least to know $something well enough so that you don’t reinvent the wheel, squared.

FFmpeg, AppleTV and conversions

Last year, a few months before ending up in the hospital, I bought a LCD TV and an AppleTV device, to watch my animes before sleeping, in my bedroom, relaxing down. After the hospital I ended up not watching much anime anyway, but before that I noticed one nasty thing: my LCD TV “eats” away around 16-20 pixel around the borders with the result that the subtitles for the japanese anime were unreadable. Which was very nasty in my opinion.

After AppleTV Take 2 software was released I also didn’t have much time to play with it to modify it again to install extra codecs, nor I had time to watch much anime, even though I bought a PlayStation 3 to relax. Now, I also considered the idea of selling away the AppleTV, getting a bigger harddrive for the PlayStation 3 and live with that. But since I have already spent enough time in the hospital, having mobile access to my anime is still a feature I’d like to keep, and since I can easily make AppleTV and iPod use the same video files, while PS3 and PSP (which I don’t own, my sister does though) would require different copies, I finally decided to keep it.

I have already tried converting video files but FFmpeg failed, while VisualDub let me do some of the conversions; unfortunately I never had the time to finish the conversion before I ended up in the hospital again. Geez, you really have some trouble when you can count eras based on when you ended up in the hospital. Anyway, since now I got a new box, I decided to try doing the conversion once again with FFmpeg, with all the improvements that arrived up to now.

Before trying that, though, I wanted to be able to do one thing: try to remove data duplication between my workstation (Yamato) and the laptop (Intrepid). My easy way out of this is to make sure that they use the same partition for music and video, which is what they share. Linux and OSX can share mainly two filesystems: FAT32 (nasty) and HFS+. The problem is that HFS+, Apple’s filesystem, can have multiple variants: it may or may not be case-sensitive, and it might be journaled. Linux cannot write to journaled HFS+, and I dislike case insensitivity, so I set up a HFS+ case-sensitive non-journaled partition beside the Time Machine partition on the external hard drive, and connect the drive to Yamato.

Moving the music and video files off Yamato’s drives also helped me to reduce the amount of data I have on the internal drives, which in turn should reduce at least a little the stress on them until I can get a new setup. And Linux HFS+ support is not that bad after all, once you disable journaling. The problem is that I wanted to make sure I could use the same disk both connected to Yamato with network attached, and directly connected to Intrepid. A tried way to do this was to export the partitions via iSCSI, but that would have given exclusive access to the partition to the laptop, and thus caused me once again not to be able to share the data.

The other solution was to export the filesystem via NFS when connected to Yamato, which is what I tried, unfortunately, as I’ve written before, Linux does not support NFS export of HFS+ partitions; or at least it doesn’t right now. I love Free Software just for this reason: if a feature does not exist, I make it up; now I just have to hope that it gets applied upstream in a decent timeframe.

Now that the filesystem problem is mostly behind me (mostly because I still see some failures; I don’t know exactly what they relates to yet), I wanted to make sure I could get a way to convert my content with FFmpeg directly; Yamato is an 8-core system so it should be faster than the laptop to do the work. So I got the latest FFmpeg version out of FFmpeg, and tried.

So the first issue is getting the right container format, while ISO Media, QuickTime, iPod video files, and so on are all based on more or less the same idea, to the point that xine can easily use a single demuxer for all of them, as well as libavformat, there are some tricky issues with having those files working on QuickTime, iTunes and AppleTV. Luckily, FFmpeg has an ipod preset that does the job, mostly, which is very good. The problem is the “mostly”: these formats are based upon elements called atoms, atoms can have versions; the common version 0 that is supported by Apple’s software has 32-bit values for timescales, offsets and stuff like that; alternatively there exist a version 1 that uses 64-bit values instead; xine supports both, but Apple’s software does not. The intersting bit here is that FFmpeg produces version 1 atoms whenever the time scale does not fit as it is in the 32-bit values, without warning even when asking for the iPod container format. The trick here is to force a timescale conversion; most of the content I got is encoded with approximately 29.97 fps, but using a timescale in AVI files that does not fit into version 0 atoms; changing the timescale to basically the same through -r 29.97 fixes the problem for me.

Now, time to get correct video and audio codecs. If you have ever tried to do this you know you have to use H.264 for video and AAC for audio; I used 800kbit/s for video and 128kbit/s for audio; just make sure you pass the parameters before the output filename, otherwise they won’t be picked up. To make sure to enable the proper features for the x264 encoder, I used the presets that are in FFmpeg’s repository; I chosen to skip the -max version since that was giving me less than one frame per second, which was very very bad, I used -hq instead, which gave me good enough results. The problem is the default version enables 8×8 DCT and B-Pyramids, which QuickTime does not properly support. Files encoded with these two features enabled were synced properly to the AppleTV but crashed it down once played. Not so nice. To fix this, just replace the + symbol with a - in front of the two features dct8x8 and bpyramids. Problem solved, and the files play.

For some reason, FFmpeg’s MS-Mpeg4 decoder dies when enabling more than 8 threads, and with so many threads, only about four cores get used on Yamato; I’m not sure why the limit is imposed by the video decoder, since I would expect at least a thread to be able to handle audio, but anyway, since that’s the deal, I decided to convert two files at a time, and to do that, well we have GNU make don’t we?

I wrote this Makefile:

VPATH = $(ORIG)

SRCS = $(notdir $(wildcard $(ORIG)/*.avi $(ORIG)/*.mp4))
all: $(patsubst %.mp4,%.m4v,$(patsubst %.avi,%.m4v,$(SRCS)))

%.m4v: $(filter %.avi,$(SRCS)) $(filter %.mp4,$(SRCS))
    ffmpeg -threads 8 -i lt; -vpre libx264-appletv-hq.ffpreset -b 800k -ab 128k -acodec libfaac -padcolor 000000 -padtop 16 -padbottom 16 -padleft 16 -padright 16 -r 29.97 -f ipod "$@"

As you can see, I’m padding 16 pixels around the video for the subtitles to appear on my TV, thanks to FFmpeg, doing the padding is very quick and does not degrade quality.

I just run make -f ~/makefle.convert -j2 ORIG=/directory and there it goes, the conversion is running, and it’ll be done in… a few hours.

I bought a software license

I finally decided to convert my video library to Mpeg4 containers, H.264 video and AAC audio, rather than mixing and matching what I had before that. This is due to the fact that I hardly use Enterprise to watch video anymore. Not only because my office is tremendously hot during the summer, but more because I have a 32” TV set in my bedroom. Nicer to use.

Attached to that TV set there is an Apple TV (running unmodified software 2.0.2 at the moment) and a PS3. If you add to that all the other hardware that can play video I own, the only common denominator is H.264/AAC in MP4 container. (I also said before that I like the MP4 format more than AVI or Ogg). It might be because I do have a few Apple products (iPod and AppleTV), but also Linux handle this format pretty well, so I don’t feel bad about the choice. Beside, new content I get from youtube (like videos from Beppe Grillo’s blog) are also in this format — you can get them with youtube-dl -b.

Unfortunately, as I discussed before with Joshua, and as I tried last year before the hospital already, converting video to this format with Linux is a bit of a mess. While mencoder has very good results for the audio/video stream conversions, producing a good MP4 container is a big issue. I tried fixing a few corner cases in FFmpeg before, but it’s a real mess to produce a file that QuickTime (thus iTunes, and thus the Apple TV) can accept.

After spending a couple more days on the issue I decided my time is worth more than what I’ve been doing, and finally gave up to buy a tool that I have been told does the job, VisualHub for OSX. It was less than €20, and that is usually what I’m paid by the hour for my boring jobs.

I got the software, tried it out, the result was nice. Video and audio quality on par with mencoder’s but a properly working MP4 container that QuickTime, iTunes, AppleTV, iPod and even more importantly xine can play nicely. But the log showed a reference to “libavutil”, which is FFmpeg. Did I just pay for Free Software?

I looked at the Bundle, it includes a COPYING.txt file which is, as you might have already suspected, the text of GPL version 2. Okay, so there is free software in here indeed. And I can see a lot of well-known command line utilities: lsdvd, mkisofs, and so on. One nice thing to see is, though, an FFmpeg SVN diff. A little hidden, but it’s there. Good.

The doubt then was if they were hiding the stuff or if it was shown and I did just miss it. Plus it has to have the sources of everything, not just a diff of FFmpeg’s. And indeed in the last page of the documentation provided there is a link to this that contains all the sources of the Free software used. Which is actually quite a lot. They didn’t limit themselves to take the software as it is though, I see at least some patches to taglib that I’d very much like to take a look to later — I’m not sharing confidential registered-users-only information by the way, the documentation is present in the downloadable package that acts as a demo too.

I thought about this a bit. They took a lot of Free Software, adapted it, written a frontend and sold licenses for it. Do I have a problem with this? My conclusion is that I don’t. While I would have preferred is they made it more clear on the webpage that they are selling a Free Software-based package, and that they would have made the frontend Free Software too, I think they are not doing anything evil with this. They are playing well by the rules, and they are providing a working software.

They are not trying to exploit Free Software without giving anything back (the sources are there) and they did something more than just package Free Software together, they tested and prepared presets to use for encoding for various targets, included Apple TV which is my main target. They are, to an extent, selling a service (their testing and presets choices), and their license is also quite acceptable to me (it’s like a family license, usable on all the household’s computers as well as a work computer in an eventual office).

At the end of the day, I’m happy of spending this money as I suppose it’s also going to further develop the Free Software part of the software too, although I would have been happier to chip in a bit more if it was fully Free Software.

And most importantly, it worked out of the tarball solving me a problem I was having for more than an year now. Which means, for me, a lot less time spent trying to get the whole thing working. Of course if one day I could just do everything with simply FFmpeg I’ll be very happy, and I’ll dedicate myself a bit more on MP4 container support, both in writing and parsing, in the future, but at least now I can just feed it the stuff I need converted and dedicate my time and energy toward more useful goals (for me, as in paid jobs, and for the users with Gentoo).

Migrating from iPhoto to DigiKam

For my photos I’ve been using, up to now, iPhoto. The reason for this is that the big part of my photo collection is actually composed of my sister’s photos, which I downloaded directly with the MacBookPro when she asked me.

On the other hand, I use way more often my Linux box, and while iPhoto is a nice tool, DigiKam is not bad either, so I’d gladly move everything on Enterprise, as the mobility option for the photos is lost already once I moved everything on the external harddrive (as I now have more than 10GB of photos).

Unfortunately this migration is not going to be painless I’m afraid, especially because there are a few features I might be losing, unless I can spend some time writing stuff on my own.

The first problem would be having a way to save the photos from risks of losing data; the quick way would be to put them in raid. At the moment the photos are backed up by TimeMachine too, so I don’t risk losing them. I don’t think putting them in my /home directory will be a good idea: it’s just 14GB and the photos will soon be over that quota. I wonder if LVM can mirror partitions easily.

Then there’s the cleanness of storing the photos on the iPod, I don’t think Amarok can load them, can it? I have to check that out. And having them on the AppleTV too.

On the Wiki there are instructions on how to set up a DPAP (Digital Photo Access Protocol, I suppose it’s a relative of DAAP) server to share the photos with iPhoto, and AppleTV. I have to check that out, maybe writing an ebuild.

Of course the easiest way to handle this would be to have DigiKam actually providing DPAP support ;)

Another point I’d like to address is Flickr uploading. To upload to Flickr at the moment I’m using the FlickrUploadr, as the only plugin to allow that in iPhoto is proprietary commercial software. kFlickr is better than FlickrUploadr, but still isn’t well integrated (can’t just select an Album and say “upload to Flickr”).

Probably some of these concerns will be addressed with the KDE 4 version of DigiKam, I expect that to happen, but now I’m wondering if I should migrate already or wait for those to be done…

On the other hand, I wonder if there is anybody working on reverse engineering the protocol with which iTunes talks to AppleTV, it would be nice to be able to just command it through Amarok or DigiKam.

/me adds stuff to his TODO, which is probably way too big for this to ever happen.

But I certainly hope someone will write this stuff for me :) After all we all do our parts in the greater Free Software plan!

About my break

So, I said before I wanted to take a one week break, and just relax, watch TV Series, Movies, Anime, read some books. There’s a huge ocean between what you hope and what happens most of the times, this time I found a galaxy between them.

So, Monday I’m first woke up by my UPSes beeping, because the power company started having problems (as usual, in Italy during summer), I slept about four hours, and I couldn’t sleep in the afternoon, as I was called to be explained the new job I’m currently doing (data entry, sigh). Tuesday I was waiting for receiving my AppleTV (with HDMI cable) – I needed something to give me back control of my laptop, and this was the most straightforward alternative to watch Anime and TV series on my TV – so I woke up early, but the courier (UPS) did not came till 16, just half an hour after I did go to sleep in the afternoon, as I slept about four hours that day too, and my data entry job was paused because of problems with the application I should have been using. Wednesday, I was waked up by my parents who forgot I was sleeping, just three hours of sleep, and I got an urgent – different, albeit for the same company – data entry job to complete in just one day; twelve hours to sleep. Yesterday, the data entry job resumed, so up again with little sleep.

And let me say something about UPS. They are one of the most expensive express couriers, they previously had a perfect record with me, although one of their drivers once whined about he having to come to my house (that is outside city) too often. This time they screwed up quite a bit. When you order an AppleTV with an HDMI cable from the Apple Store, they send you two boxes, one for the AppleTV itself, and one for the cable (probably to make it easier to the storage to handle the shipments), the invoice is also printed and attached outside the box rather than inside. The AppleTV box came to my house Tuesday afternoon as expected, but the HDMI cable wasn’t there. It was shipped, by mistake, to Madrid, Spain, and came the day after. For Google Maps, there are 1.829 km between Mestre and Madrid, and the only things they have in common are the M and the r letters in the name.

Anyway, the AppleTV is a nice gadget and works quite well, even if the Samsung TV is giving me a heartache: the image coming from the HDMI cable at 1280x720p (or 1960x1080i if you prefer) is displayed with a slightly different resolution and not scaled. The result is that a border of the whole image is missing. This is probably not a problem for most users, it’s still a problem for fansubbed Anime when the subtitles appear too close to the border. And I can’t find a way to contact Samsung Italy without calling them (and I didn’t of course have time to call them).

The data entry job is being quite stressful, it’s taking a lot of my time, and is making my break hell; in particular, the web application used to type in the data uses PDF forms rather than standard web forms, but this wouldn’t be that much of a problem, if the designers of the PDF forms used the wrong order for tab switching of the inputs (what the heck were they thinking? were they drunk?) so I need to use Acrobat Reader 6.0, that does not support the tab order embedded in PDF files and creates its own (correct) order; if I use Adobe Reader 7 or 8, pressing tab moves you around the page like crazy. And these people get paid a lot more than I am.

*sigh*