Openshot, an open source non-linear video editor, has received a lot of positive reviews especially for its simple and user-friendly interface. There is no official Gentoo ebuild for Openshot but I have been installing and testing the luman overlay (Openshot 1.4.3) over the last two days which seems to work fine.
Together, Linux NLE video editors provide a very powerful capability although each one tends to have unique features meaning it's sometimes necessary to use more than one piece of software to achieve a desired end. Cinelerra is particularly powerful and flexible, but I spotted recently that it can't generate a wipe transition with a softened edge (as noted in this rather dated review). This led me back to Kdenlive (an excellent program in its own right) and then Openshot for this feature. Initial impressions of Openshot are that it is similar to Kdenlive but with the ability to generate 3d titling through a simple-to-use interface to Blender. Note that the luman overlay does not install Blender, you have to install it separately and it has to be a very recent version. At the time of writing this is Blender 2.63 in Portage (Openshot requires 2.62 or later). Blender looks very complex to use (I am not familiar with it) but the Openshot interface to Blender is straightforward, offering a range of effects such as dissolving or exploding text and a few parameters to adjust for each effect (such as the colour of the text). The rendering of these effects is very processor-intensive, I gave up waiting on a single-core machine and ssh'd to a triple-core machine on my home network. The time waiting for Openshot to render is a reminder that Cinelerra's render farm is a great feature.
Sunday, 11 November 2012
Sunday, 16 September 2012
Using a render farm with the Cinelerra video editor
Cinelerra is an advanced Linux non-linear video editor. Cinelerra provides a timeline-based editing interface similar to Kdenlive and other non-linear video editors. It also provides a wide range of video effects but only a limited number of ready-made transitions. Many interesting transitions can, however, be created from the functionality in Cinelerra.
This blog post focusses on a very useful feature of Cinelerra, the render farm. These notes are based on Cinelerra 2.2CV on Gentoo.
A render farm enables multiple machines on a network to contribute to video rendering, speeding up this memory- and processor-intensive operation. Cinelerra enables the render farm to be used for both "background rendering" and for rendering of the final video.
Background rendering is a feature of Cinelerra whereby the video is rendered in the background for preview purposes. This is far superior to viewing a preview where frames are skipped to reduce the burden on the CPU (in which case the preview will be jerky and not representative of the final rendered video). The render farm speeds up background rendering significantly. In my own case, using an AMD XP4000 single-core processor for background rendering is, well, like watching paint dry. Since I have another machine with an AMD triple-core processor on the network, this can be pressed into service.
As far as I can tell from the documentation, the render farm needs to be set up so that the output directory of the video rendering is the same on all machines on the render farm (which Cinelerra calls "nodes"). I achieve this by logging on with the same username on the master node and the client node (nfs server and nfs client). Assume that the output of the video rendering is this directory on the machine you are using (the master node):
/home/media_user/videos
then all the machines must have this directory, including the same path. Here is an example of how the NFS share would be mounted on the client node:
192.168.1.95:/home/media_user/videos /home/media_user/videos nfs rw,user 0 0
Obviously with NFS you need to make the usual checks that the video output directory is contained in /etc/exports, that the directory is exported rw (read + write) and that the uid and gid (respectively for the user and user's group) match up.
The render farm also needs to be configured in Cinelerra. Below is a screenshot of my own configuration with some notes on the configuration underneath.
Cinelerra's documentation covers the configuration options fairly well, but there are a few things to watch out for. The option "Output for background rendering" must include the directory and the prefix of the rendered files. In our case, it's not enough to enter "/home/media_user/videos". That would be interpreted by Cinelerra as the directory "/home/media_user" and the prefix for the rendered files as "brender" (with the individual files being named by Cinelerra as brender + number, e.g. brender001035).
I changed the default option for "Frames per background rendering job" to the uppermost value recommended by the documentation, which seems to work fine. I also changed "Frames to preroll background" from 0 to 3. The documentation recommends 0 but I found this failed to work properly on video where I was using the Ken Burns effect (zooming in or out). With a value of 0, the interpolation engine didn't work properly with the rendered video switching between a full size image and the size specified by the x y z projector values.
Cinelerra must be installed on all client machines. The syntax for initiating the daemon is:
cinelerra -d [port number]
In our case this would be:
cinelerra -d 1055
Note the high number used for the port. A port number greater than 400 must be used in Linux if you want the Cinelerra daemon on the client node to be started as a non-root-user. If root is initiating the process, the default note can be used (i.e. cinelerra -d without the port number will default to 400).
Once your Cinelerra installations are set up as described, all background rendering and final video rendering will use the render farm. The best way to check whether the render farm is working is to run some background rendering on an extended section of your video timeline. When you play back the rendered video, Cinelerra will complain about missing frames if the render farm isn't working correctly. You can also check in Settings => Preferences to see whether the framerate is greater than zero for the client node.
In conclusion, the render farm is a great feature of a great piece of open source software.
This blog post focusses on a very useful feature of Cinelerra, the render farm. These notes are based on Cinelerra 2.2CV on Gentoo.
A render farm enables multiple machines on a network to contribute to video rendering, speeding up this memory- and processor-intensive operation. Cinelerra enables the render farm to be used for both "background rendering" and for rendering of the final video.
Background rendering is a feature of Cinelerra whereby the video is rendered in the background for preview purposes. This is far superior to viewing a preview where frames are skipped to reduce the burden on the CPU (in which case the preview will be jerky and not representative of the final rendered video). The render farm speeds up background rendering significantly. In my own case, using an AMD XP4000 single-core processor for background rendering is, well, like watching paint dry. Since I have another machine with an AMD triple-core processor on the network, this can be pressed into service.
As far as I can tell from the documentation, the render farm needs to be set up so that the output directory of the video rendering is the same on all machines on the render farm (which Cinelerra calls "nodes"). I achieve this by logging on with the same username on the master node and the client node (nfs server and nfs client). Assume that the output of the video rendering is this directory on the machine you are using (the master node):
/home/media_user/videos
then all the machines must have this directory, including the same path. Here is an example of how the NFS share would be mounted on the client node:
192.168.1.95:/home/media_user/videos /home/media_user/videos nfs rw,user 0 0
Obviously with NFS you need to make the usual checks that the video output directory is contained in /etc/exports, that the directory is exported rw (read + write) and that the uid and gid (respectively for the user and user's group) match up.
The render farm also needs to be configured in Cinelerra. Below is a screenshot of my own configuration with some notes on the configuration underneath.
Cinelerra's documentation covers the configuration options fairly well, but there are a few things to watch out for. The option "Output for background rendering" must include the directory and the prefix of the rendered files. In our case, it's not enough to enter "/home/media_user/videos". That would be interpreted by Cinelerra as the directory "/home/media_user" and the prefix for the rendered files as "brender" (with the individual files being named by Cinelerra as brender + number, e.g. brender001035).
I changed the default option for "Frames per background rendering job" to the uppermost value recommended by the documentation, which seems to work fine. I also changed "Frames to preroll background" from 0 to 3. The documentation recommends 0 but I found this failed to work properly on video where I was using the Ken Burns effect (zooming in or out). With a value of 0, the interpolation engine didn't work properly with the rendered video switching between a full size image and the size specified by the x y z projector values.
Cinelerra must be installed on all client machines. The syntax for initiating the daemon is:
cinelerra -d [port number]
In our case this would be:
cinelerra -d 1055
Note the high number used for the port. A port number greater than 400 must be used in Linux if you want the Cinelerra daemon on the client node to be started as a non-root-user. If root is initiating the process, the default note can be used (i.e. cinelerra -d without the port number will default to 400).
Once your Cinelerra installations are set up as described, all background rendering and final video rendering will use the render farm. The best way to check whether the render farm is working is to run some background rendering on an extended section of your video timeline. When you play back the rendered video, Cinelerra will complain about missing frames if the render farm isn't working correctly. You can also check in Settings => Preferences to see whether the framerate is greater than zero for the client node.
In conclusion, the render farm is a great feature of a great piece of open source software.
Wednesday, 5 September 2012
Why Gentoo is a great Linux distrubution
I have been using Linux as a desktop system at home for a number years, with my usage focusing on academic work and multimedia tasks such as music scoring and video.
Until very recently I used a well-known rpm-based distribution, which was a good introduction to Linux and had the advantage of a user-friendly installation process. The difficult with this, and a number of similar, distributions is the focus on periodic releases where the update process can be unreliable. A major attraction of Gentoo is the ability to do a once-only installation of the base system and then be able to customise and upgrade this base system indefinitely.
As an IT-literate amateur (with a little bit of very dated formal training in programming), it is a revelation to use Gentoo and I think it shows the flexibility and reliability of Linux at its best. The initial installation and configuration certainly requires time and patience, so it's wise to keep a working system running during the initial setup, for instance on a separate partition. Probably the main hurdle is acquiring a good understanding of your hardware for the initial kernel configuration. In my case, I found that a well-known network card driver was present on the Gentoo live disk but not in Gentoo's default Genkernel so it took a bit of research on the Internet to troubleshoot this particular issue. Configuring the kernel was otherwise surprisingly straightforward.
Once set up, using Gentoo is a real pleasure. Available official and user-generated documentation is very helpful and extensive while the portage software repository is huge and well-maintained. The requirement to compile software from scratch adds an element of complexity, but I often found the apparent simplicity of my previous rpm distribution a bit illusory -- I frequently ended up with versioning issues which were hard to resolve. I also found that the vendor-specific configuration files on my former system made the configuration of Linux much more complex than it actually needed to be. There was something of an uneasy mix between GUI-based configuration and the inevitable manual editing of text files once the GUI options had proved to be inadequate.
I have been particularly impressed by the ease with which complex software like Cinelerra can be installed on Gentoo. The installation process is no easier or harder than with a binary distribution but much more flexible. My initial installation of Cinelerra without the OpenGL compile flag was easily corrected with a short line of text in the Gentoo package.use configuration file. It is interesting to compare this straightforward solution to some of the issues which are evident when users try to grapple with an rpm-based system where the vendor has decided not to include a particular compile flag.
In the usual manner of the IT press, Gentoo is often compared with other distributions in terms of performance and ease of use. Sometimes it's a bit like comparing apples and pears. Some Linux distributions appear to be taking their users more towards a one-size-fits-all Windows-like experience whereas Gentoo offers complete configurability and flexibility -- the ability to build a unique system which optimises the use of system hardware. It demands a bit more technical knowledge which can be readily acquired but the effort is worthwhile in my view.
I haven't mentioned any other Linux distributions by name because they all have their strengths. I am a strong advocate of Linux, particularly the underlying values of freedom and collaboration which are evident across much of the GNU/Linux community. I think the Gentoo approach embodies these values in a particularly successful way.
Until very recently I used a well-known rpm-based distribution, which was a good introduction to Linux and had the advantage of a user-friendly installation process. The difficult with this, and a number of similar, distributions is the focus on periodic releases where the update process can be unreliable. A major attraction of Gentoo is the ability to do a once-only installation of the base system and then be able to customise and upgrade this base system indefinitely.
As an IT-literate amateur (with a little bit of very dated formal training in programming), it is a revelation to use Gentoo and I think it shows the flexibility and reliability of Linux at its best. The initial installation and configuration certainly requires time and patience, so it's wise to keep a working system running during the initial setup, for instance on a separate partition. Probably the main hurdle is acquiring a good understanding of your hardware for the initial kernel configuration. In my case, I found that a well-known network card driver was present on the Gentoo live disk but not in Gentoo's default Genkernel so it took a bit of research on the Internet to troubleshoot this particular issue. Configuring the kernel was otherwise surprisingly straightforward.
Once set up, using Gentoo is a real pleasure. Available official and user-generated documentation is very helpful and extensive while the portage software repository is huge and well-maintained. The requirement to compile software from scratch adds an element of complexity, but I often found the apparent simplicity of my previous rpm distribution a bit illusory -- I frequently ended up with versioning issues which were hard to resolve. I also found that the vendor-specific configuration files on my former system made the configuration of Linux much more complex than it actually needed to be. There was something of an uneasy mix between GUI-based configuration and the inevitable manual editing of text files once the GUI options had proved to be inadequate.
I have been particularly impressed by the ease with which complex software like Cinelerra can be installed on Gentoo. The installation process is no easier or harder than with a binary distribution but much more flexible. My initial installation of Cinelerra without the OpenGL compile flag was easily corrected with a short line of text in the Gentoo package.use configuration file. It is interesting to compare this straightforward solution to some of the issues which are evident when users try to grapple with an rpm-based system where the vendor has decided not to include a particular compile flag.
In the usual manner of the IT press, Gentoo is often compared with other distributions in terms of performance and ease of use. Sometimes it's a bit like comparing apples and pears. Some Linux distributions appear to be taking their users more towards a one-size-fits-all Windows-like experience whereas Gentoo offers complete configurability and flexibility -- the ability to build a unique system which optimises the use of system hardware. It demands a bit more technical knowledge which can be readily acquired but the effort is worthwhile in my view.
I haven't mentioned any other Linux distributions by name because they all have their strengths. I am a strong advocate of Linux, particularly the underlying values of freedom and collaboration which are evident across much of the GNU/Linux community. I think the Gentoo approach embodies these values in a particularly successful way.
Saturday, 19 November 2011
Creating m3u playlists on the Sansa clip+ player in Linux
The Sansa clip+ player is an excellent audio player which works very well under Linux. m3u playlists can easily be created and this blog post describes some simple ways of doing this. All that's required is to create a list of audio files which is saved to the Clip's MUSIC directory in a file with an .m3u extension.
The first technique uses a custom action in the Thunar file manager. The player needs to be in MSC mode which is set on the player itself: Settings => System settings => USB mode => MSC). Now you need to configure a custom action in Thunar. From the Edit menu in Thunar select Configure custom actions... Click on the + icon to add a new action and in the Name field enter Create a Sansa clip playlist. Don't worry about the Description field but in the command field enter:
The first technique uses a custom action in the Thunar file manager. The player needs to be in MSC mode which is set on the player itself: Settings => System settings => USB mode => MSC). Now you need to configure a custom action in Thunar. From the Edit menu in Thunar select Configure custom actions... Click on the + icon to add a new action and in the Name field enter Create a Sansa clip playlist. Don't worry about the Description field but in the command field enter:
ls %N > playlist.m3u
Now select the Appearance conditions tab, make sure there is an asterisk (*) in the File pattern field and that Audio files is checked.
Now select the Appearance conditions tab, make sure there is an asterisk (*) in the File pattern field and that Audio files is checked.
To create a playlist, the player needs to be mounted in Linux. Under Gnome this happens automatically on my system (currently OpenSuse 11.4) but I prefer the Fluxbox window manager and use the wmvolman dockapp to mount the player manually. In Thunar, navigate to the MUSIC directory (on my system for the Sansa clip's internal memory this is /media/0123-4567/MUSIC) and CTRL+Click to select the files which will make up the playlist. Next, right click and you should see an option to use your custom action: Create a Sansa clip playlist. Select this menu, and a file called playlist.m3u will appear in the same directory. This is an m3u playlist which should be usable on your Sansa Clip+. It's useful to rename the file, since it will be overwritten next time you run the script.
I ran into problems when I tried to delete playlists in Thunar, because it places the files in a Trash folder which I couldn't delete permanently. I therefore delete the playlists from the command line but Nautilus works as well.
Another (and more flexible) way to create playlists on the Sansa Clip+ is to use the kid3 KDE ID3 tag editor. Under Suse, install the package using: sudo zypper install kid3-qt. With the Sansa clip mounted, open the MUSIC directory on the player in kid3 (File => open directory) and CNTRL+click to select multiple files. Now click on the Create playlist item. In the Format field you can use any name for the playlist as well as ID3 tags. Make sure you use the following options:
%{file} contains "Elgar"
You can now create a playlist which contains only those files.
I ran into problems when I tried to delete playlists in Thunar, because it places the files in a Trash folder which I couldn't delete permanently. I therefore delete the playlists from the command line but Nautilus works as well.
Another (and more flexible) way to create playlists on the Sansa Clip+ is to use the kid3 KDE ID3 tag editor. Under Suse, install the package using: sudo zypper install kid3-qt. With the Sansa clip mounted, open the MUSIC directory on the player in kid3 (File => open directory) and CNTRL+click to select multiple files. Now click on the Create playlist item. In the Format field you can use any name for the playlist as well as ID3 tags. Make sure you use the following options:
- Create in: current directory
- Format: m3u
- Include only the selected files
- Use relative path for files in playlist
- Write only list of files
%{file} contains "Elgar"
You can now create a playlist which contains only those files.
Sunday, 15 May 2011
Relacing a bootable disk which has a root partition (Suse Linux)
This weekend I replace an old IDE bootable hard disk containing a Suse Linux partition with a new Sata disk.
First stage was to clone the old disk using dd:
Where /dev/sdb is my old hard disk (the input file) and /dev/sda (the output file) is the new hard disk. This took a few hours on a 120GB disk but is reported to be faster if you specify the block size in the dd options. However, the clone operation worked fine.
Having rebooted, I didn't initially realise that the Grub bootloader configuration would now be out of date and that the machine would continue to boot from the old hard disk. It is not possible to reassign the root partition in Yast, but there are some useful instructions on this site on how to do a fresh install of Grub onto a new disk.
Following these instructions, I first created a directory where the cloned root partition on the new disk could be mounted:
Next I mounted the cloned root partition:
Next, to bind /dev to the cloned partition:
and then chroot into the new partition:
Now for a fresh install of Grub onto the cloned disk:
grub-install.unsupported /dev/sda
The grub-install.unsupported command has to be used (rather than just grub-install) because Suse prefers you to use Yast for bootloader configuration. However, when I tried this, neither yast2 (the graphical interface) or yast (the character-based interface) worked within the chroot jail.
A reboot still gave the original result (i.e. the machine booted from the old disk) so the next stage was to edit the Grub bootloader configuration files.
First (and working within the chroot jail on the cloned partition), the new disk has to be entered into the /boot/grub/device.map file. Since I had two old IDE disks in the PC, there were two existing lines in the device.map file:
I added a third line for the next hard disk starting (hd2). If you don't know the disk ID, you can check it in the Yast2 bootloader configuration to copy the disk ID from there.
A reboot confirmed that Grub was happy with the new disk in the device.map file, so I created a new menu entry in the /boot/grub/menu.lst file. My original menu.lst file looked like this:
Using the first menu option as a model, I created a new menu option to boot from the new hard disk:
A reboot confirmed that this new option worked fine.
Th final stage was to comment out the lines in the /boot/grub/device.map file for the old disks, and assign(hd 0) to the new hard disk. Next, I edited the /boot/menu.lst file, commenting out the menu options for the old hard disk and retaining the menu option for the new hard disk, ensuring that the line beginning root now pointed to (hd0,5) since this hd0 was now the hard disk number for the new disk in device.map.
I disconnected the old disks, rebooted and then selected the new menu option, but for some reason/etc/fstab now had a line for a root partition on one of the old drives (the drive which didn't actually have a root partition...) so the reboot failed. Changing /etc/fstab fixed this.
First stage was to clone the old disk using dd:
dd if=/dev/sdb of=/dev/sda
Where /dev/sdb is my old hard disk (the input file) and /dev/sda (the output file) is the new hard disk. This took a few hours on a 120GB disk but is reported to be faster if you specify the block size in the dd options. However, the clone operation worked fine.
Having rebooted, I didn't initially realise that the Grub bootloader configuration would now be out of date and that the machine would continue to boot from the old hard disk. It is not possible to reassign the root partition in Yast, but there are some useful instructions on this site on how to do a fresh install of Grub onto a new disk.
Following these instructions, I first created a directory where the cloned root partition on the new disk could be mounted:
mkdir /mnt/new
Next I mounted the cloned root partition:
/mount /dev/sda6 /mnt/new
Next, to bind /dev to the cloned partition:
mount --bind /dev /mnt/new/dev
and then chroot into the new partition:
chroot /mnt/new
Now for a fresh install of Grub onto the cloned disk:
grub-install.unsupported /dev/sda
The grub-install.unsupported command has to be used (rather than just grub-install) because Suse prefers you to use Yast for bootloader configuration. However, when I tried this, neither yast2 (the graphical interface) or yast (the character-based interface) worked within the chroot jail.
A reboot still gave the original result (i.e. the machine booted from the old disk) so the next stage was to edit the Grub bootloader configuration files.
First (and working within the chroot jail on the cloned partition), the new disk has to be entered into the /boot/grub/device.map file. Since I had two old IDE disks in the PC, there were two existing lines in the device.map file:
(hd0) /dev/disk/by-id/ata-[device_ID of first hard disk]
(hd1) /dev/disk/by-id/ata-[device_ID of second hard disk]
I added a third line for the next hard disk starting (hd2). If you don't know the disk ID, you can check it in the Yast2 bootloader configuration to copy the disk ID from there.
A reboot confirmed that Grub was happy with the new disk in the device.map file, so I created a new menu entry in the /boot/grub/menu.lst file. My original menu.lst file looked like this:
# Modified by YaST2. Last modification on Tue Mar 1 15:19:29\
# GMT 2011
# GMT 2011
# THIS FILE WILL BE PARTIALLY OVERWRITTEN by perl-Bootloader
# Configure custom boot parameters for updated kernels in
# /etc/sysconfig/bootloader
# /etc/sysconfig/bootloader
default 0
timeout 8
##YaST - generic_mbr
gfxmenu (hd0,5)/boot/message
##YaST - activate
###Don't change this comment - YaST2 identifier: Original
###name: linux
###name: linux
title Desktop -- openSUSE 11.3 - 2.6.34.7-0.7
root (hd0,5)
kernel /boot/vmlinuz-2.6.34.7-0.7-desktop \
root=/dev/disk/by-id/ata-[old disk_ID]-part[partition no.]\
resume=/dev/disk/by-id/ata-[old disk_ID-part[partition no.]\
splash=silent quiet showopts vga=0x31a
root=/dev/disk/by-id/ata-[old disk_ID]-part[partition no.]\
resume=/dev/disk/by-id/ata-[old disk_ID-part[partition no.]\
splash=silent quiet showopts vga=0x31a
initrd /boot/initrd-2.6.34.7-0.7-desktop
###Don't change this comment - YaST2 identifier: Original
###name: failsafe
###name: failsafe
title Failsafe -- openSUSE 11.3 - 2.6.34.7-0.7
root (hd0,5)
kernel /boot/vmlinuz-2.6.34.7-0.7-desktop \
root=/dev/disk/by-id/ata-[old disk_ID]-part[partition no.]\ showopts apm=off noresume nosmp maxcpus=0 edd=off \
powersaved=off nohz=off highres=off \
processor.max_cstate=1 nomodeset x11failsafe vga=0x31a
root=/dev/disk/by-id/ata-[old disk_ID]-part[partition no.]\ showopts apm=off noresume nosmp maxcpus=0 edd=off \
powersaved=off nohz=off highres=off \
processor.max_cstate=1 nomodeset x11failsafe vga=0x31a
initrd /boot/initrd-2.6.34.7-0.7-desktop
Using the first menu option as a model, I created a new menu option to boot from the new hard disk:
###New menu option###
title Suse linux 11.3
root (hd2,5)
# Note: hd1 was still the 2nd old hard disk at this stage
# Note: hd1 was still the 2nd old hard disk at this stage
kernel /boot/vmlinuz-2.6.34.7-0.7-desktop \
root=/dev/disk/by-id/ata-[new disk_ID]-part[partition no.]\ resume=/dev/disk/by-id/ata-[new disk_ID]_ID-part\
[partition no.]splash=silent quiet showopts vga=0x31a
root=/dev/disk/by-id/ata-[new disk_ID]-part[partition no.]\ resume=/dev/disk/by-id/ata-[new disk_ID]_ID-part\
[partition no.]splash=silent quiet showopts vga=0x31a
initrd /boot/initrd-2.6.34.7-0.7-desktop
A reboot confirmed that this new option worked fine.
Th final stage was to comment out the lines in the /boot/grub/device.map file for the old disks, and assign(hd 0) to the new hard disk. Next, I edited the /boot/menu.lst file, commenting out the menu options for the old hard disk and retaining the menu option for the new hard disk, ensuring that the line beginning root now pointed to (hd0,5) since this hd0 was now the hard disk number for the new disk in device.map.
I disconnected the old disks, rebooted and then selected the new menu option, but for some reason/etc/fstab now had a line for a root partition on one of the old drives (the drive which didn't actually have a root partition...) so the reboot failed. Changing /etc/fstab fixed this.
Monday, 2 May 2011
Building a silent PC for MythTV
I started using MythTV a few years ago as an experiment. My main intention was to access foreign-language TV and radio broadcasts on my lounge TV but I was amazed at the power and flexibility of this open-source PVR when I gave it a trial run.
My original MythTV PC recently hit the buffers, so I've built a new box with the following components:
I am currently running MythTV 0.24 under Suse Linux. A few Mythtv users have reported that the video runs in "slow motion" under this version, something which I managed to fix (on the basis of a forum post) by setting the audio output to ALSA:pulse.
High-definition Freeview has just arrived in my area. This is progressively being rolled out across the UK and uses the DVB-T2 standard. PC hardware to decode this signal is very new although the PCTV systems nanoStick T2 290e DVB-T2 USB tuner is available which I am currently running under Windows 7. This works fine under PCTV's own software but under Windows Media Center the audio drifts out of sync with the video. This seems be a common problem with Windows Media Center (which doesn't occur with MythTV) and there doesn't seem to be a solution. The use of Windows 7 for high definition Freeview is a stopgap as far as I am concerned so I am watching with interest the development of a Linux driver.
Update: driver for the nanoStick T2 now built into the Linux Kernel.
My original MythTV PC recently hit the buffers, so I've built a new box with the following components:
- Antec Fusion NSK-2480 case
- Scythe mini-ninja (eBay)
- AMD Athlon II X3 400E Triple Core CPU
- LiteOn IHOS104-32 4x Internal Blu-Ray BD-ROM
- Seasonic X-460FL 460W ATX Fanless PSU
- CORSAIR 4GB 1333MHz CL9 DDR3 Memory Kit
- ASUS M4A78LT-M LE motherboard
- 2 x Western Digital WD10EARS 1TB Hard Drive SATAII 5400rpm 64MB
- Noctua NF-S12B 120mm case fan
- Sparkle GT220 coolpipe graphics card (passively cooled)
I am currently running MythTV 0.24 under Suse Linux. A few Mythtv users have reported that the video runs in "slow motion" under this version, something which I managed to fix (on the basis of a forum post) by setting the audio output to ALSA:pulse.
High-definition Freeview has just arrived in my area. This is progressively being rolled out across the UK and uses the DVB-T2 standard. PC hardware to decode this signal is very new although the PCTV systems nanoStick T2 290e DVB-T2 USB tuner is available which I am currently running under Windows 7. This works fine under PCTV's own software but under Windows Media Center the audio drifts out of sync with the video. This seems be a common problem with Windows Media Center (which doesn't occur with MythTV) and there doesn't seem to be a solution. The use of Windows 7 for high definition Freeview is a stopgap as far as I am concerned so I am watching with interest the development of a Linux driver.
Update: driver for the nanoStick T2 now built into the Linux Kernel.
BT Infinity on Linux
I recently upgraded to BT infinity and being a Linux user didn't know whether the new BT Home Hub 3 router would offer the same flexibility as my previous router, a Linksys Wireless-G ADSL Home Gateway.
Fortunately the functionality I required under Linux from the Linksys router is largely replicated on the BT Home Hub 3. You don't need a Windows or Mac disk to install anything, everything can be configured under a Linux-enabled browser such as Opera.
Dynamic DNS is supported, currently the router offers DynDNS, NoIP and DtDNS.
The Infinity router also allows port forwarding, although the way it is implemented is a bit awkward. You can't assign the same port to more than one device. Say, for instance, you exchange files with a smartphone using FTP on port 21, you can't assign 21 to another device (e.g. the PC from which you access the router). If you try, the Home Hub 3 will throw up an error. Fortunately there is a workaround. The router has a number of pre-configured port settings for games and applications including FTP and SSH. Under the "supported applications" tab within "port forwarding" (all under "advanced settings") you can Add a new game or application, so for the smartphone example you could add an entry for "FTP smartphone" and assign a port such as 2121 to the device. This can create additional work on Linux because you may have to change configuration files in order to associate a port number with a service, for instance you have to change /etc/ssh/sshd_config on SUSE for SSH. A custom rule may also be required for the firewall. This is irksome but manageable, and once the port settings are configured the router seems to forward the relevant ports OK.
On balance the Home Hub seems a decent upgrade in terms of speed, about 22 MB/sec download where I am and around 4 MB/sec upload, an enormous improvement on copper-based ADSL where I could only scrape 2MB/sec download. From a Linux perspective, I haven't found any major issues with it although it's always worth bearing in mind that BT expect customers using Linux to set up their own Internet connections (as BT's own Web site makes clear). Some Linux users seem to have difficulty, particularly with certain distributions. I have always found knetworkmanager a user-friendly way of managing wireless connections under Linux.
Fortunately the functionality I required under Linux from the Linksys router is largely replicated on the BT Home Hub 3. You don't need a Windows or Mac disk to install anything, everything can be configured under a Linux-enabled browser such as Opera.
Dynamic DNS is supported, currently the router offers DynDNS, NoIP and DtDNS.
The Infinity router also allows port forwarding, although the way it is implemented is a bit awkward. You can't assign the same port to more than one device. Say, for instance, you exchange files with a smartphone using FTP on port 21, you can't assign 21 to another device (e.g. the PC from which you access the router). If you try, the Home Hub 3 will throw up an error. Fortunately there is a workaround. The router has a number of pre-configured port settings for games and applications including FTP and SSH. Under the "supported applications" tab within "port forwarding" (all under "advanced settings") you can Add a new game or application, so for the smartphone example you could add an entry for "FTP smartphone" and assign a port such as 2121 to the device. This can create additional work on Linux because you may have to change configuration files in order to associate a port number with a service, for instance you have to change /etc/ssh/sshd_config on SUSE for SSH. A custom rule may also be required for the firewall. This is irksome but manageable, and once the port settings are configured the router seems to forward the relevant ports OK.
On balance the Home Hub seems a decent upgrade in terms of speed, about 22 MB/sec download where I am and around 4 MB/sec upload, an enormous improvement on copper-based ADSL where I could only scrape 2MB/sec download. From a Linux perspective, I haven't found any major issues with it although it's always worth bearing in mind that BT expect customers using Linux to set up their own Internet connections (as BT's own Web site makes clear). Some Linux users seem to have difficulty, particularly with certain distributions. I have always found knetworkmanager a user-friendly way of managing wireless connections under Linux.
Subscribe to:
Posts (Atom)