60GB Playstation 3, finally RIP

Back in this post I described how I’d followed some instructions from the Internet to fix my old PS3, which was exhibiting the “yellow light of death”. At the time it seemed to have been successful; the hot air gun heated up the soldered connections on the motherboard to the point where they became molten, allowing them to remake all the connections as the motherboard cooled down. The system started working again.

At this point, rather than celebrating my success, I should have taken a complete backup of the PS3. Unfortunately, I didn’t.

It now seems as though the fix wasn’t as permanent as I’d hoped, as the system went back into YLOD a few days later. After some thought I’ve bought a new PS3 slim to replace it – trying to fix it again seems like a waste of time and energy, though I’ve still had to disassemble the blueray drive anyway, just to extract the disc that was locked inside it.

I also extracted the 60GB disk, which is a standard 2.5″ SATA drive that seems to be working perfectly, but isn’t recognised under Linux. The PS3 is reported to use a UFS2 filesystem, but it appears that the actual filesystem itself (not just the data within it) is encrypted by the PS3, binding the drive to the specific PS3, and preventing any data from being read from the disk by any other system.

From a migration perspective, this is a dreadful decision by Sony, as it means it is completely impossible to extract the saved game information from the drive. This could represent many hours of game-play for some people, including my daughter. It would seem that a better design decision would have been to store the saved game information on a separate partition, using a well known filesystem like ext3, in the clear. But they obviously didn’t consider this a major issue.

Which is more than a little annoying.

Yellow light of death

My PS3 is one of the original 60GB launch systems; as such it’s getting a bit long in the tooth. But it still gets used every day for either streaming my movies, or playing the kids games. Or both.

Until Tuesday evening, when it suddenly beeped three times, and turned itself off, with the power light flashing red. Trying to turn it back on again didn’t work, and neither did power cycling it. At which point I did some research, and discovered that this is known as the “Yellow Light Of Death”, or YLOD for short. It’s the way the PS3 indicates a catch-all hardware problem, and basically means the console is dead, and needs to be sent back to Sony for repair

Which would be OK, but since mine is well out of warranty we’re talking a significant bill to repair it, and in all likelihood I wouldn’t get back my rather rare launch system, with all the additional hardware that helps with backwards compatibility for PS2 titles. Not good.

It transpires that early PS3 systems like mine used 90nm Cell B/E processors, which were very power-hungry hot-running processors, and Sony didn’t do a very good job mounting the heatsinks in the early systems. This resulted in the systems running hot, and eventually causing dry solder joints to form between the CPU & GPU and the motherboard, resulting in these YLOD hardware failures. These problems are much less common on the newer PS3 Slims, which user newer 45nm Cell B/E processors that generate much less heat (200w total system consumption, compared to nearly 400w in mine).

Fortunately some enterprising people have managed to find a way of fixing this by making their own hot-air reflow solder station out of a standard hot air paint stripper, and have been able to re-flow-solder all the surface-mounted components around the CPU/GPU, fixing the dry solder joints and restoring their PS3s to life. And better yet they’ve posted videos of how to do it, so others can repeat their success.

So I did.

Going slowly it took me about 3 hours to strip the PS3 down to it’s bare motherboard, heat up the components so their soldered connections re-flowed and remade themselves, and then to rebuild it afterwards. I must admit that I wasn’t expecting it to work – but then again I had nothing to lose beyond a spare evening and £5 of thermal compound to remount the heatsinks with.

But the result is that the PS3 is now working again, and in practice, probably better than it has for a long time; by resolving the poorly mounted heatsinks and using a better quality of thermal compound the fan can now run much more slowly, and still provide better cooling. So it’s much quieter while streaming movies. Which is perfect.

Except I rather fancy getting a second generation Apple TV and hacking XBMC onto it to produce a really smart media hub, and fixing the PS3 has just made justifying the expenditure on that a lot harder!

When is a USB charger *not* a USB charger?

Answer: When you want to charge an original PS3 SixAxis controller.

I’ve had an original first-release PS3 since 2007, and it’s a fine piece of kit. Given that it was designed many years ago, it’s lasting extremely well. In my case I mostly use it for streaming my video collection from my (DNLA-enabled) home server, where I store my digitised DVD collection, to the main TV, which is attached to the PS3 by HDMI.

My only problem with this arrangement is that I’ll often find that when I want to use the PS3, the rechargeable wireless controller is flat, thanks to extended movie-watching by my kids. The only way to recharge the controller is to plug it into the USB port of the running PS3, which charges it up again reasonably quickly.

So I decided it would be worth spending the £5 or so to get a mains-powered USB-charger, so the controller can be left permanently on charge when not in use, so it’s always fully charged when needed. A fine idea.

Except in practice my PS3 controller fails to charge when plugged into the mains charger. It charges when connected to the PS3. Or my laptop. But it also fails to charge on my old mains-powered Blackberry USB charger. Something is definitely odd.

There are now extensive specifications for how you must go about powering (and especially charging) devices via USB, but back when the PS3 was designed (2003-2005) this was something of a new and grey area, so it’s not at all clear that Sony would be following the current specifications. And so it transpires.

Unlike almost every other device out there, which either just draws current from the USB port without asking, or follows the specifications and passively checks for fixed voltages on the USB data lines, my PS3 controller will only start charging after it has been both connected to, and enumerated by, a host USB port.

What this means in practice is that my PS3 controller can only charge from a real USB port on a computer that is capable of intelligently communicating with it. Modern mains-powered USB chargers which describe their capabilities according to the USB specifications using voltages and simple resistances between the data lines will never persuade it to start charging. Which is very annoying.

So, the question is, will newer PS3 controllers follow the new USB specifications, or will they also require enumeration before they can be charged? I have a suspicion that the newer controllers will follow the new USB charging specifications; this would account for the number of very mixed reviews of “mains powered PS3 controller docking stations” on places like Amazon. Anyone with an old original controller like mine, and a new docking station designed to the USB standard will find it doesn’t work. Whereas people with newer controllers will see it work perfectly, and not understand the poor reviews from the owners of original controllers.

I’ll find out soon enough, as I’ve ordered myself a Dualshock controller for Christmas to allow my kids and I to play some games head to head.

If that follows the recent USB specifications then I think my low-tech solution will be to leave the original controller connected to the PS3 USB port, and predominantly use the new controller. The original will charge whenever we use the PS3, and the new one can be plugged into the mains-powered USB charger and charge when the PS3 is switched off, and so also always be ready for use.

If the new controllers do not follow the new USB specifications then there is a solution to the problem – build a charging circuit that is capable of supplying power from the mains that can follow enough of the USB specifications to properly enumerate the controller. Fortunately, someone has already done all the hard work for a single controller, and published the information. I’ll need to modify it to support (at least) two controllers, which will need some simple circuit changes to add more USB ports, and some more extensive changes to the microcode to provide support for them.

Since I’ve not played with micro-controllers yet, I’m going to hold off from attempting this until I definitely know I need it!

My new DualShock3 controller arrived today. It also refuses to charge on a standards-compliant USB charger. Options are to build something to resolve it, as detailed earlier, or pay the outrageous markup that Sony demand for their charger, which can enumerate the controller. I suspect I won’t be able to build a charger for less than the cost of Sonys commercial charger, so I may as well just go and buy it. But I do feel cheated by this. Sony ought to have fixed their controllers by now.

Digitising DVD’s with Linux to stream to PS3

Having posted about converting the format of video files to suit streaming to a PS3, I got an email asking me how I actually convert a DVD into a digital file, and how my network is set up to stream videos to the PS3.

So, a little more explanation. I have a small, very low-power server that runs 24×7 in my house, and is connected to my 100mbps ethernet network. On that server I have quite a lot of disk storage, and run Mediatomb, which is a DNLA-compliant UPnP media server. It serves my collection of video and audio files to any device on my network that wants to access them.

In the case of the video files, that device is my PS3, which is also connected to my ethernet network, and also has an HDMI connection to my LCD TV. With this configuration I can start the PS3, which automatically detects the Mediatomb media server and puts an icon on its GUI interface. I can then select that icon, get a list of the available video files, and by clicking on one, have it played on my TV for me.

The only configuration involved in this solution is of Mediatomb, which involves a couple of documented changes to its configuration file, and specifying where my media files are via its web interface. All very simple.

To create the media files from a DVD, I do the following:

1. Extract the content of the DVD onto my hard drive using a program called vobcopy.
2. Use ffmpeg to convert that content into a more compact form, better suited to streaming over a network.
3. Copy the resulting file to my server where Mediatomb can access it.

Now lets look at the first two steps in more detail:

DVD’s actually store their content as a series of VOB‘s; these contain the actual video that you see when you play back a DVD. In general there are separate VOB’s for the main movie, any adverts, trailers, bonus features, etc etc. And just to make life a little more complex, some DVDs store the main movie in more than one VOB, though fortunately vobcopy can hide that from us.

To make things a little more difficult, the movie industry have then encrypted the DVD to make it harder to do what we are about to do. To get around this, you must have installed libdvdcss2, which is a DVD decryption library that is available from the Medibuntu repository.

To find which VOB to extract from the DVD, simply run “vobcopy –info”. This will produce some output like:

richard@t60p:~$ vobcopy –info
Vobcopy 1.1.0 – GPL Copyright (c) 2001 – 2007 robos@muon.de
[Hint] All lines starting with “libdvdread:” are not from vobcopy but from the libdvdread-library

[Info] Path to dvd: /dev/sr0
libdvdread: Using libdvdcss version 1.2.10 for DVD access
[Info] Name of the dvd: STARWARS2UK_D1_2_PAL
[Info] There are 21 titles on this DVD.
[Info] There are 103 chapters on the dvd.
[Info] Most chapters has title 1 with 51 chapters.
[Info] All titles:
[Info] Title 1 has 51 chapters.
[Info] Title 2 has 1 chapter.
[Info] Title 3 has 2 chapters.
[Info] Title 4 has 1 chapter.
[Info] Title 5 has 1 chapter.
[Info] Title 6 has 1 chapter.
[Info] Title 7 has 1 chapter.
[Info] Title 8 has 1 chapter.
[Info] Title 9 has 1 chapter.
[Info] Title 10 has 2 chapters.
[Info] Title 11 has 10 chapters.
[Info] Title 12 has 14 chapters.
[Info] Title 13 has 1 chapter.
[Info] Title 14 has 1 chapter.
[Info] Title 15 has 2 chapters.
[Info] Title 16 has 1 chapter.
[Info] Title 17 has 4 chapters.
[Info] Title 18 has 2 chapters.
[Info] Title 19 has 2 chapters.
[Info] Title 20 has 1 chapter.
[Info] Title 21 has 3 chapters.

[Info] There are 21 angles on this dvd.
[Info] All titles:
[Info] Title 1 has 1 angle.
[Info] Title 2 has 1 angle.
[Info] Title 3 has 1 angle.
[Info] Title 4 has 1 angle.
[Info] Title 5 has 1 angle.
[Info] Title 6 has 1 angle.
[Info] Title 7 has 1 angle.
[Info] Title 8 has 1 angle.
[Info] Title 9 has 1 angle.
[Info] Title 10 has 1 angle.
[Info] Title 11 has 1 angle.
[Info] Title 12 has 1 angle.
[Info] Title 13 has 1 angle.
[Info] Title 14 has 1 angle.
[Info] Title 15 has 1 angle.
[Info] Title 16 has 1 angle.
[Info] Title 17 has 1 angle.
[Info] Title 18 has 1 angle.
[Info] Title 19 has 1 angle.
[Info] Title 20 has 1 angle.
[Info] Title 21 has 1 angle.
[Info] Using Title: 1
[Info] Title has 51 chapters and 1 angles
[Info] Using Chapter: 1
[Info] Using Angle: 1

[Info] DVD-name: STARWARS2UK_D1_2_PAL
[Info] Disk free: 74104.160156 MB
[Info] Vobs size: 5733.919922 MB

It’s highly likely that the VOB with the most chapters is the main movie; in this case title 1. We can check that by running the command “mplayer dvd://[vob_number]”. If we see the main movie playing then we can extract that VOB to our hard disk by running the command “vobcopy –title-number [vob_number]”. vobcopy will then proceed to decrypt and copy that VOB to your hard disk (as STARWARS2UK_D1_2_PAL3-1.vob in this case).

Now we can convert that (very large) file into something smaller and more easy to stream. This uses exactly the same command as the last post; ffmpeg. This time however, we need to make sensible guesses for the bitrates that we want to use for the video and audio streams. Personally I go with 2000k for the video, and 192k for the audio. It’s good enough in terms of quality, and produces a file ~1/3rd the size of the original VOB, which is much more amenable to being streamed over a 100mbps ethernet network. If you’re hoping to do this over wireless, then you’ll probably need to compress even more and sacrifice quality … wireless just doesn’t have the bandwidth to do good quality video streaming.

So, the command to convert that VOB to a .mp4 file is:

ffmpeg -i STARWARS2UK_D1_2_PAL3-1.vob -vcodec libx264 -b 2000k -acodec libfaac -ab 192k STARWARS2UK_D1_2_PAL3-1.mp4

That command will take at least as long to execute as the movie would have taken to play. But once completed, the resulting file can then be copied to my server and be available for instant access in the future.

(Re)encoding video under Linux to stream to a PS3

I’ve recently moved to storing my video collection on my home server as a series of .mp4 files, and streaming them (with Mediatomb) to my PS3, which displays them on my TV. This means I can watch any of my DVD’s without having to find the disc, which is very convenient.

However, I started digitising many years ago, so my collection contains a few older “.avi” files that contain video in early Divx and Xvid formats. Normally these “.avi” files can be streamed directly to the PS3 too, but sometimes the PS3 complains of Unsupported data, error 800288bf, or Corrupted data. I’ve failed to discover exactly what causes these problems, but they’re clearly related to the combination of the codecs used for the audio and video streams and the use of the avi container.

To resolve this, I simply convert (re-encode) these unsupported “.avi” videos into the newer more standards-based .mp4 format. This approach will work equally well for video in the many other formats that the PS3 doesn’t understand. To do this, I use ffmpeg, which is the swiss army knife of video & audio conversion for Linux.

If you intend to replicate this, you need to use a recent and full version of ffmpeg; the version in the standard Ubuntu repositories isn’t sufficient, as it doesn’t include support for patent-encumbered codecs, which you will need. Instead, you can get the version you need from the Medibuntu repository.

First find out what bitrates your existing video is using for it’s video and audio streams. Enter “ffmpeg -i video.avi”. Output will be something like:

richard@t60p:~/Data$ ffmpeg -i video.avi
FFmpeg version SVN-r19352-4:0.5+svn20090706-2ubuntu2, Copyright (c) 2000-2009 Fabrice Bellard, et al.
configuration: –extra-version=4:0.5+svn20090706-2ubuntu2 –prefix=/usr –enable-avfilter –enable-avfilter-lavf –enable-vdpau –enable-bzlib –enable-libgsm –enable-libschroedinger –enable-libspeex –enable-libtheora –enable-libvorbis –enable-pthreads –enable-zlib –disable-stripping –disable-vhook –enable-gpl –enable-postproc –enable-swscale –enable-x11grab –enable-libdc1394 –extra-cflags=-I/build/buildd/ffmpeg-0.5+svn20090706/debian/include –enable-shared –disable-static
libavutil 49.15. 0 / 49.15. 0
libavcodec 52.20. 0 / 52.20. 0
libavformat 52.31. 0 / 52.31. 0
libavdevice 52. 1. 0 / 52. 1. 0
libavfilter 0. 4. 0 / 0. 4. 0
libswscale 0. 7. 1 / 0. 7. 1
libpostproc 51. 2. 0 / 51. 2. 0
built on Oct 13 2009 22:15:16, gcc: 4.4.1
Input #0, avi, from ‘video.avi’:
Duration: 01:24:57.64, start: 0.000000, bitrate: 2281 kb/s
Stream #0.0: Video: mpeg4, yuv420p, 720×304 [PAR 1:1 DAR 45:19], 25 tbr, 25 tbn, 25 tbc
Stream #0.1: Audio: mp3, 44100 Hz, stereo, s16, 192 kb/s
At least one output file must be specified

I’ve highlighted the interesting parts; the average bitrate for the whole file, and the average bitrate of the audio stream. Take one from the other and you have the average bitrate for the video stream.

Now we need to re-encode the video into a format the PS3 likes. We’ll use H.264 video, AAC audio, in an MP4 container, which the PS3 supports well. I’ve just reused the same bitrates as the input file, but in practice you can probably reduce both a little without affecting quality, as H264 and AAC encoding is more efficient than older encoders:

ffmpeg -i video.avi -vcodec libx264 -sameq -b 2089k -acodec libfaac -ab 192k -t “00:05:00” video.mp4

Notes

• -sameq keeps video quality the same
• -b 2089k specifies the output video bitrate
• -ab 192k specifies the output audio bitrate
• -t “00:05:00” optionally produces only 5 minutes of output – ideal for testing your settings before you convert a long video
• Encoding time on my dual core laptop is about 1 second for each second of video. So expect a long wait.

Internet TV

A colleague pointed me at get_iplayer the other day, and I spent a couple of hours this weekend playing with it. Without a doubt it is the easiest way I have come across for getting hold of content from the various UK “play it again” services for TV and Radio.

BBC TV programme downloads are in H264 video and AAC audio, and although they are not high definition – more like good VHS quality – the convenience is spectacular. I sucked down a couple of programmes from the BBC; an episode of Being Human, and an episode of Doctor Who, which took about 15 minutes each (on my current 2Mbit connection). Both were downloaded as Quicktime .mov files because the feed that get_iplayer uses is designed for the iPhone.

I then converted them to .mp4 containers (using the command ffmpeg -i input.mov -vcodec copy -acodec copy output.mp4) and stored them on my NAS. From there, they were streamed (using the Mediatomb DNLA server) to my PS3 over my wireless network, which was able to play them back onto my flatscreen TV. And it worked beautifully.

Except for the stuttering. And the occasional unexpected pause. Turns out that despite my PS3 seeing 85% WiFi signal strength, it can’t consistently transfer more than about 0.5Mbit/s over my home wireless network. Which is not enough for video streaming. A quick check with a long Cat5e cable shows no signs of stuttering or pausing, so this is clearly a problem with the wireless drivers in the PS3. So it looks like I will need to hurry along my plan to drop some more ethernet lines to the back of the TV area of the lounge. Except of course, that isn’t going to happen for a few months now 🙂

However, notwithstanding the networking issues, the potential here is great. I can write some webpages on my NAS that I can access from my PS3, on the flatscreen TV in the lounge. That will run get_iplayer and return a list of available programmes, which I can select to download and have stored on my NAS, where they will then be converted to .mp4 format which I can stream to the PS3, so I can watch them. When my fast connection comes online (hopefully tomorrow!) that should take no more than 2 or 3 minutes for an hour-long TV programme.

Internet TV … almost on demand.