[annagel]

ack, I'll update the wiki, my previous apt-gets must already installed them.

Also not a bad idea for at least anyone doing ubuntu, dumping a disc image of the ubutu installer onto the drive before sending it off on its own so you can mount it to /media/cdrom when apt-get starts asking for it. Though I feel like there must be other ways around this as well, I just do not know what they are...

[davilla]

A distro is hard to do right now. Because of the console video assumptions that Ubuntu uses for it's installer, the installation has to be done on using normal PC hardware (I'm still working on solving this). A deb for after install could be created, I'm deb creation stupid right now so that will have to wait until either I learn more or someone else volunteers. It's looking like we will need the nvidia driver updated to the 169.xx series to get the gpu to underclock, analog audio needs a simple patch to the realtek module and that's part of linux-ubuntu-modules. IR support needs a simple patch to another kernel module but that in linux kernel image (it's only two lines of code). Both of these are loadable kernel modules so it possible to pre-create and manually patch but that's going to break if the kernel gets updated. Since Ubuntu (and MythBuntu) has strictly defined updates, it might be possible to pre-compile modules for all updates and use a deb to control. Just don't know that much about debs.

A generic preconfigured disk image could be created but I don't have the hosting space at googlecode and it's going to be big, about 1.5G or more extracted so maybe 600MB compressed.

IP is not an issue as only boot.efi is required and that can be extracted from Apple r1.1 update, the atv-bootloader wiki has instructions for this. Any image or dep cannot distribute this file so it will have to be fetched before or live during the install.

USB pen drives are possible but not really a usable solution. With only 256MB of ram, swap is required and swap on flash is very slow and will eventually kill the flash drive.

USB hard drive are quite usable, I do this right now for testing cases, it's much easer to plug/unplug USB than the internal ata. Little slower than using internal ata but not much. This also means that you could leave your original atv hard drive unchanged.

MythBuntu install is mostly debugged now. Ubuntu Gutsy install is in progress and should be firmed up in a few days.

For XBMC, I would choose an Ubuntu Gutsy install, it's going to be much closer to what the XBMC on Linux devs are using.

Tracking a boot failure issue using the internal ata disk with a small number of AppleTVs. Think I understand why and can fix this issue, don't know why it only affects a small number of AppleTV and not all of them.

[BLKMGK]

Well, my thought was an image so I guess distro was a poor choice of words - just a preinstalled already done up image that could be DD'd to a drive ready to roll. I understand about the disk space but I'll bet we could do a torrent easily enough. Find a good tracker and off you go, TPB for instance would work. The first upload would take awhile depending upon upload speed but once up and seeded it would roll - I'd help for sure.

The IP in it would be a problem but if it's just one file that could be worked around easily enough - just add a text file describing how to do it. If you get things to a point to try that by all means I'm onboard. I need to get my routers straight so my machine can be accessed to speed up seeding but that's already on my list I've got good upload speed to burn so lemme' know if you are ever to the point where you're comfortable doing that.

[annagel]

Is there any way to use a screen resolution but have Ubuntu just shrink itself by some amount? Basically just make itself slight amount smaller than the screen technically allows. I am using this screen entry in my xorg.conf file:

Code:

Section "Screen"
    Identifier    "Default Screen"
    Device        "Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller"
    Monitor        "mon1"
    Option        "NoLogo"    "True"
    Option        "Coolbits"    "1"
    Option        "UseEDID"    "False"    
    Option        "ConnectedMonitor"    "TV"
    Option        "TvOutFormat"    "Component"
       #------------480p Group-----------------------------
#       Option     "TVStandard" "HD480p"
#       Option     "metamodes" "CRT: 720x480 +0+0"
       #------------720p Group-----------------------------
       #Option     "TVStandard" "HD720p"
       #Option     "metamodes" "CRT: 1280x720 +0+0"
       #------------1080i Group-----------------------------
       Option     "metamodes" "CRT: 1920x1080 +0+0"
      #    Option    "metamodes" "CRT: 1388x768 +0+0"
    Option     "TVStandard" "HD1080i"
    Option        "AddARGBGLXVisuals"    "True"
SubSection "Display"
                         Depth     24
             Modes    "720x480" "1280x720" "1920x1018"
    EndSubSection
EndSection

If I combine this with System->Prefs->Screen Res->1920x1080 I get a slight amount of overflow on the screen but I am at least filling the screen...so it seems like it should be easier to get the desktop to be not quite as big as it could be right?

[davilla]

overscan?


Option "TVOverScan" "0.6"


into xorg. It's a nvidia option.

[davilla]

Yes, one tester reported back that a second internal build fixed the error with boot.efi loading mach_kernel.

The fix actually makes perfect sense now that I see what was happening. Duh -- the error propagates from the original bootloader. Details will get it's own wiki page later. Basically a base load address error, boot.efi say "I can't load you there, I have reserved memory in that location". The reserved address location wiggles around depending which efi firmware mode is running. There are at least three and I suspect more. So, sometimes there is a load address conflict, sometimes not.

I'm waiting on one more response back for verification then I'll post an update to recovery.tar.gz and update svn. svn commits are also changing to only have source now that builds are in the download section. svn commits are eating up my 100MB allocation with googlecode.

Thanks for everyones help in tracking this down.

[annagel]

davilla,
When you upgraded the nvidia driver to 169.x did you just use the installer from the nvidia site or an alternate method?

Andrew

[davilla]

First time I used "Envy". That worked but I don't like how it did every thing, seems really complicated.

Second time, I removed the restricted driver and installed from the nvidia download. It worked fine until I rebooted, then it broke, X11 could not find a screen. Something stupid somewhere. It was late last night so I'll take another stab at it tonight.

I updated the MythBuntu install docs to include the update of the nvidia driver but it's not complete yet.

[rasmusth]

First I'd like to honor you guys, davilla in particular for this wonderful idea. I'm currently running xbmc on my old xbox, packed away in a drawer under my tv. I'm a total mac-fanatic, so the idea of my beloved XBMC running on an AppleTV is absolutely gorgeous.

The only thing I wonder is if the AppleTV is indeed strong enough on the hardware front to perform playback on 720p in the x264 format?

Thanks again, Rasmus TH.

[davilla]

First I'd like to honor you guys, davilla in particular for this wonderful idea. I'm currently running xbmc on my old xbox, packed away in a drawer under my tv. I'm a total mac-fanatic, so the idea of my beloved XBMC running on an AppleTV is absolutely gorgeous.

The only thing I wonder is if the AppleTV is indeed strong enough on the hardware front to perform playback on 720p in the x264 format?

Thanks again, Rasmus TH.

Some bit rates of x264 720p will be possible, high bit rate maybe not. No one does gpu accelerated x264 under Linux so have to do software decode which means ffmpeg. This area has not been fully explored as to the absolute limits, there a lot of testing with different ffmpeg params and ffmpeg is a moving target with respect to x264.

The AppleTV has a 1GHz pentium-m which is pertty fast for its clock rate but it does not compare to say a 2.5GHz Core2 Duo2.

If you have sample files (less than 50MBs) of 720p x264 that you want tried, post a link and I will try them when I get time.

[annagel]

Second time, I removed the restricted driver and installed from the nvidia download. It worked fine until I rebooted, then it broke, X11 could not find a screen. Something stupid somewhere. It was late last night so I'll take another stab at it tonight.

This was my experience as well with the nvidia installer, install went easy enough but then no go once I restarted.

Andrew

[davilla]

This was my experience as well with the nvidia installer, install went easy enough but then no go once I restarted.

Andrew

Check these links, there's more to remove/add it seems.

http://darpanetwork.blogspot.com/2008/02...gutsy.html

http://www.karoliinasalminen.com/blog/?p=265

[annagel]

Some info I wish I had before I tried to upgrade:

http://www.nvnews.net/vbulletin/showthread.php?t=72490

Looks like having any old nvidia drivers installed is going to cause issues with getting a successful install of the 169.x driver according to this post at least.

[davilla]

I hear your pain, I'm headed that way too. I understand the whole restricted drives approach but why did they make it so difficult to just download the standard nvidia installer and use it to install.

Maybe another approach is to get the source for the restricted drivers deb and patch that to install the 169.xx driver instead of the 100.14.19 version.

[annagel]

169.x is working these are the steps I followed from a clean install following the steps on the wiki minus

Code:

sudo apt-get install nvidia-glx-new
sudo nvidia-glx-config enable
sudo nvidia-xconfig --cool-bits=1 --no-composite --no-logo

and with the sshd install which is commented out

booted and logged in via ssh, though I don't think there is any reason you couldn't do all this from chroot

Code:

sudo apt-get install linux-headers-`uname -r` build-essential gcc gcc-3.4 xserver-xorg-dev
sudo apt-get --purge remove nvidia-glx nvidia-settings nvidia-kernel-common

#ran this because it was on the instructions I found
#but it did nothing, can't hurt
sudo rm /etc/init.d/nvidia-*

sudo vi /etc/default/linux-restricted-modules-common
#change to DISABLED_MODULES="nv"
#might need to add nvidia_new if you had that installes
#would be DISABLED_MODULES="nv nvidia_new"

#download the installer
wget http://us.download.nvidia.com/XFree86/Linux-x86/169.12/NVIDIA-Linux-x86-169.12-pkg1.run

#not needed if you were running from chroot
sudo /etc/init.d/gdm stop

#run installer
sudo sh NVIDIA-Linux-x86-169.12-pkg1.run

sudo reboot

booted right to graphical login, running on HDMI at the moment component and the GPU under-clock next