5. I don't think the "new" squeezebox radio is branded as such, but it looks almost the same.

It's called the Smart Radio UE, and runs a different firmware for their streaming services. A "downgrade-able" firmware is available to restore compatibility with the Logitech Media Server (aka Squeezebox Server). More info can be found in the Squeezebox Radio forum http://forums.slimdevices.com/forumdisplay.php?32-Squeezebox-Radio

I thought about getting one, but decided to just go with Raspberry Pi's. That way, I can use them for Airplay and as Squeezeslaves, and add home automation to the mix using AgoControl (as sensor platforms as well as maybe running LED lights via OpenDMX). Still playing with it at this stage.

What's happening is the jumbo frames are having to be broken down when routed through the core, re-transmitted, and the received traffic will have to be chunked together to make new jumbo frames to send back to the MD's (incurring significant latency). Needless to say, performance will suck royally (especially on commodity hardware).

You may wish to reconsider your usage strategy for jumbo frames...

If you choose to keep using them, you may wish to investigate/verify that your MD's are using the Apt-proxy and a http caching proxy, and you'll likely need to do some serious Kernel network performance tuning...

net.core.rmem_max = 16777216net.core.wmem_max = 16777216net.core.rmem_default = 16777216net.core.wmem_default = 16777216net.core.optmem_max = 16777216net.ipv4.tcp_rmem = 4096 87380 16777216net.ipv4.tcp_wmem = 4096 87380 16777216The above is a place to start, and can be used on both core and MD's (even without jumbo frames). It sets 16M buffers for the network, presuming 1Gbe network adapters. I run those settings on my network without issues. The kernel defaults to 1M and 4M buffers, which are more suitable to 100M network adapters.

Just keep in mind, you won't be able to avoid the fragmentation issues; you may just be able to mitigate them to a tolerable extent. It looks like you like to play, so I figured I'd point you towards some places to start...

HTH!

/Mike

N.B. The IBM wiki page above also has tuning parameters for 'ib', which are Infiniband adapters. Disregard unless you actually have an Infiniband fabric in your house...

Speaking as a server guy, your "free" server may end up costing you in the long run. It's a circa 2001 Dual-processor Pentium 3, with 133MHz (not GHz) RAM, Ultra SCSI 3 drives, 100M ethernet, and PCI/PCI-X slots all in a 7 RU chassis. No offense intended, but these days we call that a 13 year old space heater. The amount of compute capability vs the amount of power being used is quite disproportionate compared to even inexpensive modern hardware. To be perfectly honest, most modern smartphones have more horsepower...

I don't want to dissuade you from using it, but you may want to set your expectations appropriately... Also, keep in mind that if you start to use it for "production" purposes at home, you are running a higher level of risk. Your likelihood of getting spare parts is slim, and those disks are around 13 years old. In the enterprise space, 3-5 years is considered old for disks, and 5-7 is considered old for server hardware. New hardware uses less power and has on-average double the performance of two years previous.

Just wanted to set your expectations relative to your hardware's capabilities...

Not to hijack the thread; is the web orbiter code also used for the Proxy Orbiters (like for Roaming Orb)? I have problems with those just dying, and having to reboot the core to get them to work. Happens in both 10.04 and 12.04.

I use MythTV 0.25 on my Debian host, and 5 MiniMyth diskless systems booted on my "external" network. I'm using Schedules direct for the listing data, and have a mixture of Analog cable and Rogers Digital STB (PVR-150's on slave backend, PVR-1600 on host) as well as Digital OTA (HDHR-3-US on it's own network segment and NIC).

That's production for now, as I work on migrating to LMCE at some point in the (hopefully) near future.

I want to use mythtv but don't consider it usable within lmce. I long for schedulesdirect and myth scheduling... it's SO much better than my satellite providers interface and capabilities!

Phenigma, I'm curious as to why you don't consider MythTV usable within LMCE. Cutting over to it was going to be one of the activities I was going to work on in the next couple of months, so I'm interested in knowing what I'm in store for...

MKBrown - sounds as if you have some idea there but please liase with possy before applying anything. The original problem that I noted above has definitely been resolved by his latest snapshot but there may still be some work to do. When I get a moment I'll read what you've written and try to understand it all.

Jamo,

I don't have commit rights to SVN, and to be quite honest, I don't want commit rights. I'll plug away fixing stuff I'm capable of, usually SysAdmin type stuff 'cause that's what I do, do up patches and stuff them into Trac. Someone more knowledgable than I about LMCE internals can take 'em, leave 'em, tweak 'em, whatever. I'll just do what I can do, and let others do what they're good at.

I've been looking into the DNS issues as well as the management of resolv.conf. In 12.04, /etc/resolv.conf is now managed dynamically by the glibc resolver and resolvconf. This is so that network mangler can dynamically manage Network configuration (and thus DNS lookups) on say a laptop that roams onto different Wi-Fi networks. Historically, LMCE has been more like a server in trying to manage DNS settings statically, and now the two are conflicting to some extent.

I just finished working up a patch for Network_Setup.sh to add DNS settings into the /etc/network/interfaces file for the internal network, and when LMCE is running, the bind forwarders file handles outgoing DNS. I haven't quite figured out exactly what to do about resolv.conf management, and at what stage to transfer the info obtained from Kubuntu's boot-up network config in resolv.conf over to the bind forwarders file.

There won't be any DNS info in the external NIC (unless I add code for it; the challenge is again when to transfer it). External DNS is handled by the servers listed in /etc/bind/named.conf.forwarders, which is also setup in Network_Bind.sh, which is called from Network_Setup.sh.

To make it interesting, the following scripts all backup or touch resolv.conf:

And the diskless setup scripts copy the core's resolv.conf to the moon directory, which won't work too well when the core is running properly, as resolv.conf will be set up to use localhost to hit bind on the same system. The diskless code will need a version of my patch to add the DNS settings to the interfaces file, or write the core's internal IP to resolv.conf.

I'll post my interface DNS patch into Trac shortly, so at least one issue gets addressed while we figure out the resolv.conf one.

Ok, if you're running VirtualBox, you don't need 32-bit libraries on the host. VirtualBox provides hardware virtualization, so all you need to do is create the VM "container" with at least a 50GB "virtual hard drive", attach the LMCE ISO to it as a CDROM, and configure the boot order to boot from CDROM first.

You can use VBox as a test bed, but I wouldn't recommend it for "production" use, at least not with LMCE. Unless you really know your way around virtualization products and configuration, it's best to just install LMCE one bare metal.

Will do. I try to understand how things work and why, before I dive in (which means things take a while ;-). I'll look into the resolv.conf stuff shortly. I've submitted patches for 12.04 (which I'm now running) against ticket 1769 which should fix the local DNS updates from dhcpd.

What's the host & hypervisor? I do virtualization for a living, and short of architecture or endian issues, I have yet to see a 64-bit CPU that won't run 32-bit code (with the correct libraries of course); and that's talking Sparc, Power, and x86.

I run KVM on a Phenom II host with a 64-bit Kernel, 32-bit user land, and LMCE 32-bit running as a VM. Before anyone thinks I'm crazy (hmmm, maybe? ;-). The host OS started life as a 32-bit Debian 3 install on an over-clocked Pentium 233 MHz, and has been through a number of in-place OS and hardware upgrades over the years, now currently Debian 7.1. Multi-arch may let me finally go all 64-bit, or I may bite the bullet and re-install. So much to do, so little time...