| FrequentlyAskedQuestions |
UserPreferences |
| Freevo Wiki | FrontPage | RecentChanges | TitleIndex | WordIndex | SiteNavigation | HelpContents |
Please add new questions (and possibly answers) here if something is missing!
As of Freevo 1.5, the recommended python version is Python 2.3 for providing proper Unicode (non-English language) support. However, presently (June 19, 2004) the freevo-runtime 0.3.1 is still based on python 2.2, so instead of using freevo-runtime, you'll need to install all system dependencies in addition to having a system-installed freevo in order for it to work properly.
WARNING: Don't mix a freevo-runtime based installation with the system-installation method, it'll probably result in unexpected errors.
For earlier versions of freevo (1.4.x), try using the freevo-runtime instead. Development and testing was done using that. Report the problem if it still occurs.
To run Freevo 1.4.x without the runtime you need Python 2.2 with a number of additional libraries installed. Just use the runtime unless you want to spend a significant amount of time installing and patching stuff. There's some docs (INSTALL.deps) about doing it, but we put together the runtime just so that people wouldn't have to struggle with it (and us spending too much time answering the same questions over and over)...
You're missing a required library that is required by Freevo.
You need to install Python XML. You should either get the package for your distribution or fetch the upstream version and build it yourself.
You can get it from:
![[WWW]](/wiki/img/moin-www.gif){kind=small}
http://www.python.org/sigs/xml-sig/
You're missing a library required for Freevo. Despite it's name, pygame isn't just for games but provides an interface to the SDL layer which Freevo uses to draw the interface. You should either get the package for your distribution or fetch the upstream version and build it yourself.
You can get it from:
http://www.pygame.org
Make sure local_conf.py is properly setup (MPLAYER_ARGS_VCD). Test the same commandline from the shell to make sure it can be played. Use "VCD" in Freevo to play it. You need to use the Freevo function for opening and closing the tray to mount the disk.
Freevo should autodetect your CD devices depending on the structure of your /etc/fstab. If it doesn't find one, add an entry like this to your local_conf.
ROM_DRIVES = [ ('/mnt/cdrom','/dev/cdrom','CD')]
If you have problems with stuttering audio, make sure you have your hdparm settings set up correctly. I had to do the following to get acceptable audio playing on my machine:
hdparm -d1 -a8 -u1 -c1 /dev/cdrom
In freevo config, your ROM_DRIVES setting will look something like:
ROM_DRIVES = [ ('/mnt/dvd', '/dev/hdc', 'DVD') ] }
Thats 'mountpoint', 'device name', 'what we call it'. In order for freevo to recognize the dvd it mounts it, looks at the files on it, then unmounts it. It uses the mountpoint that you tell it in ROM_DRIVES to do this.
From the shell type: mount /mnt/dvd }
now ls /mnt/dvd (if the mount was successful). If you see files there you are halfway there. If the mount failed then you need to setup your /etc/fstab to have an entry for your dvd drive, like:
/dev/hdc /mnt/dvd iso9660 defaults,user,noauto,ro 0 0
Ok, unmount it, umount /mnt/dvd.
Now before you try to play the dvd in freevo make sure you can play it with your copy of mplayer. Do: "mplayer dvd://" ("mplayer -dvd 1" in older versions) if that worked you are almost there. If it didn't work then you may need to build your own mplayer binary or download an rpm from somewhere, you need dvd support.
Try all this stuff first, and if that works hopefully you can play your dvd from freevo.
If all of this fails, try creating the file freevo-rebuild-database in your Freevo cache directory. On Debian, the command: touch /var/cache/freevo/freevo-rebuild-database should work, if run with sufficient privileges.
No. The core application will work on slower machines, as well as image viewing and MP3 playback. But video/DVD playback and recording requires around 400 MHz, and simultaneous video record and playback requires an even faster machine, especially for higher resolutions. We'd recommend something over 1 Ghz if you want to use that feature when it comes out (based on the hardware needs of mythtv). If you only want video playback, less than 400 Mhz may be enough, please check the mplayer doc about this (http://www.mplayerhq.hu/DOCS/).
Most distributions should work with freevo. The freevo_runtime and freevo_apps packages contains all the external dependencies for Freevo (Python, SDL, Freetype, MPlayer, etc). You might have to get a different version of MPlayer depending on your system (for instance, the freevo_apps MPlayer doesn't support Alsa).
Freevo is distributed both as RPMs and ".tar.gz" files. The RPMs do not always work on all systems, so please try the ".tar.gz" files before asking for help on the mailing list. The main webpage and the Wiki DocumentationPage documents how to do the installation.
The SDL library that Freevo uses resets the framebuffer settings. This is fixed by re-running the "fbset" command, which is done using the scripts in matrox_g400/mga_[ntsc|pal]_*. There is an option to run a script like this automatically after startup, see OSD_SDL_EXEC_AFTER_STARTUP in local_conf.py.
This is a known problem with the X11/Xv display in MPlayer, hopefully this will be fixed later. UPDATE: This info is misleading, or perhaps just outdated. In the local_conf.py file (/usr/local/freevo/local_conf.py) change the option from MPLAYER_USE_WID = 1 to MPLAYER_USE_WID = 0 that should fix the problem. I don't know the advantage for using window mode, but disabling it fixes the "window at the top" problem.
Try setting AUDIO_DEVICE in local_conf.py to '/dev/dsp1' instead. You may also find that /dev/dsp is being used by artsdsp (you can find out by typing "fuser -v /dev/dsp", assuming you have fuser installed in your distro). If this is the case, then type "killall -9 artsdsp" and then try running freevo. If freevo then works, then you can choose to either no longer use arts, or see if one of the other sound devices might work for you instead eg "ls /dev/ds*". If you're lucky, your sound card might be able to use a digital interface to talk to the video capture card - you can find out which by typing "dmesg|grep dsp" - note that even if you do see a digital device, it might not work with your sound card. Further to this, you might want to check out what I did at GentooInstallation....
The Hauppauge WinTV works great, at least the Analog PCI-ones. Radio works great too! There is currently no support in linux for hardware mpeg-encoding which comes with the more expansive cards. However software encoding works fine for CPUs faster than 400Mhz. Check http://www.hauppauge.com
Note: The latest haupauge Cards use the newer chipset conexant 2388x, which is not fully supported yet. http://bytesex.org/cx88/
The newest Pinnacle PCTV Cards have a bttv 878 chip but their MT2053 tuner is not supported yet.
I had good results with the Terratec Cinergy 600 TV it has a saa7134 chip which is supported by v4l http://bytesex.org/saa7134
(see Video for Linux resources http://www.exploits.org/v4l/ for more)
Yes, see G400Notes for information on adjusting the card's registers for optimum picture quality.
Please see the DocumentationPage.
Have a look at the main documentation.
This is a shortcoming in SDL. Try setting the environment variable "SDL_NOMOUSE" to 1 before starting Freevo. A full set of SDL enviroment variables can be found at ftp://ptah.lnf.kth.se/pub/misc/sdl-env-vars
TV Out: Matrox G400, DXR3 / Hollywood+, nVidia (roughly in that order, nvidia does not have very good signal quality) Video In: Any BTTV Based Card will do. IE. Hauppauge WinTV
Freevo has its' own keybindings. You can see the list of keys if you press 'h' in X11 mode.
EVENTS['video']['PREV'] = Event(VIDEO_SEND_MPLAYER_CMD, arg='seek -600') EVENTS['video']['NEXT'] = Event(VIDEO_SEND_MPLAYER_CMD, arg='seek 600')That way we let freevo know what to send to mplayer to do what we want and assign the commands to the names PREV and NEXT. Now, we need to modify /etc/freevo/lircrc to use the commands PREV and NEXT. Example:
begin
prog = freevo
button = 7
config = PREV
end
begin
prog = freevo
button = 9
config = NEXT
end
With these two sections we assign the buttons "7" to skip 10 minutes backward and "9" to skip 10 minutes forward.
http://mplayerhq.hu/DOCS/documentation.html#commands is a list of the commands mplayer supports. You can use these to make further customizations or get detailed descriptions. UPDATE: Above link seems broken...is the this one meant? http://mplayerhq.hu/DOCS/HTML/en/control.html#ctrl-cfg-commands
The Linux kernel has a built in screen blanking routine, which is enabled by default. You can disable the kernel's blanking by using the 'setterm' application. Freevo also includes a script called 'blanking' in the helpers directory. You can run it like this:
su root -c "./blanking"from within the Freevo helpers directory. It will disable screen blanking in the kernel for all the virtual terminals.
If you continue having the same problems in X you may find you can fix it with xset
xset s blanking xset s off xset -dpms
For watching tv in linux using a tv-tuner card the most common way of getting the tv sound input is by using a short audio cable that connects on one end to the tv card and the other end to the line-in jack on a sound card. This way there is always audio data being pumped to the sound card's line-in. The most common problem is that the tv-tuner audio output is not connected correctly to the sound card input (usually line-in). Alternatively, the line-in has been muted, or the volume turned all the way down.
Note that freevo upon startup will mute the line-in and set the volume to zero. You should make sure that TV audio is indeed working properly outside of freevo before attempting to debug it within freevo.
In order to verify that tv audio is indeed being received by your sound card, use a mixer program (e.g., aumix, alsactl) and manually unmute and set the volume for the line-in. Then try viewing the TV channel from outside of freevo using either mplayer (you'll need to figure out the command line parameters), tvtime or xawtv / fbtv (for framebuffer mode) and determine if the sound works correctly. Alternatively, connect the tv audio output from the tv-card directly to the speakers (be careful about the volume!) if nothing else seems to be working.
Now that you've managed to view TV programs correctly from within freevo, the next step is to try and record it. However, a common problem with recordings is that there's video, but the audio is silent. The line-in levels are set to a high value, and everything seems fine, right?
Unfortunately, in order for the recording program to actually record the sound you're hearing so well via the speakers, you also need to set another parameter: the "Capture Input". This is toggled using the space-bar from within the mixer program. In alsamixer, it appears in Red as "CAPTUR" above the audio input that you want to capture ("- - - - - -" otherwise). In aumix, it toggles between a Red "R" (capturing) and a green "P" (not capturing).
You MUST enable the capture input even though you can hear the audio clearly through your speakers.
As an aside, Capture and Muting are two separate things. Mute refers to output to the speakers, while Capture refers to input that's sent to /dev/dsp (or whichever device is used in your system) in order for the audio recording to work. The Level determine the loudness of the audio that's captured or sent to the speakers.
You should try recording manually from the command line to verify that the mixer settings are set correctly before trying to debug it in freevo. The most common problem is that freevo resets the input levels automatically, causing the recording to be silent. Please read the RecordingInfo section for more details on controlling the mixer input levels for scheduled recordings.
Note: There's a variable in local_config.py "CONTROL_ALL_AUDIO" that can be set to zero to prevent freevo from muting and resetting input levels automatically. However, this will cause the tv audio to be heard via the speakers during a recording (which is probably not what you want).
For watching tv in linux using a tv-tuner card the most common way of getting the tv sound input is by using a short audio cable that connects on one end to the tv card and the other end to the line-in jack on a sound card. This way there is always audio data being pumped to the sound card's line-in. Any programs used to play or record this audio must be configured to get the stream from the line-in channel of the sound card's DSP resource (ie: /dev/dsp0).
The btaudio kernel module provides an alternate method of recording or playing sound from bt878 tv-tuner cards directly via the PCI bus, bypassing the sound card input and potentially results in better A/V sync. This is termed 'DMA Audio'.
For tv-tuner cards using other chipsets (e.g., Phillips SAA7134, Conextant cx88) there are equivalent capabilities available.
SAA7134-based cards do not need any additional kernel modules, an insmod option 'oss=1' will enable the DMA audio capture capability. This maps the DMA audio to the next available /dev/dsp? device (and may reorder the device numbering if the sound card module is loaded after the saa7134 module has loaded). It is advisable to load the saa7134 module only after the sound card modules are loaded to avoid this problem, as well as to specify the device number using mixer_nr and dsp_nr options. Go to http://bytesex.org for more information.
Note that SAA7130-based cards do not have this capability and can only capture audio via the sound-card.
From the linux kernel documentation:
Audio DMA support for bt878 based grabber boards. As you might have
already noticed, bt878 is listed with two functions in /proc/pci.
Function 0 does the video stuff (bt848 compatible), function 1 does
the same for audio data. This is a driver for the audio part of
the chip. If you say 'Y' here you get a oss-compatible dsp device
where you can record from.
Please also read Documentation/sound/btaudio from the linux kernel source! It has some valuable information.
So, if you think your tv card has this capability then try it out. You will probably have to build your own kernel / this module yourself but may be lucky enough to have it included in your linux distribution. There is another module that is called tvmixer which provides access to the sound mixer capabilities of these cards as well. Both of these modules can be found in the sound section of the linux kernel configuration.
Once you have these modules compiled it is time to try them out. The btaudio module has some important options. If you read 'Documentation/sound/btaudio from the linux kernel source' you will see that btaudio may provide access to both a digital and analog audio source. My tv card is capable of 16 bit stereo sound so I use the digital one. For the record I am using an ATI TV-Wonder (regular edition) as my tv card. Btaudio also has a 'rate' option which defaults to 32kHz so you will most likely not need to change this option but you should be aware of it.
To load btaudio I do the following:
# modprobe btaudio analog=0 digital=1If I then type 'dmesg' to display the kernel messages I see:
btaudio: driver version 0.7 loaded [digital] PCI: Found IRQ 5 for device 00:0b.1 PCI: Sharing IRQ 5 with 00:01.1 PCI: Sharing IRQ 5 with 00:0b.0 btaudio: Bt878 (rev 17) at 00:0b.1, irq: 5, latency: 32, mmio: 0xe9026000 btaudio: using card config "default" btaudio: registered device dsp1 [digital]For tvmixer (needed by btaudio only, not necessary for saa7134-based cards) you probably do not need to use any options so simply:
# modprobe tvmixerLikewise:
i2c-core.o: driver tv card mixer driver registered. tvmixer: debug: MSP3445G-B8 tvmixer: MSP3445G-B8 (bt848 #0) registered with minor 16 tvmixer: debug: Philips NTSC_M (MK2)
Ok, with any luck you now have these modules loaded. It is time to try them out. If you have a silly audio patch cable going from your tv card to your sound card remove now because you won't be needing it! But first please read caveat below.
Not all programs are capable of capturing audio using DMA audio via the PCI bus. Notably, most TV viewing programs (such as tvtime, mplayer, xawtv 3.x) are not able to use the DMA audio input for live viewing. This situation may change in future as DVB (digital video broadcast) capture cards become more common.
The tvtime FAQ notes a workaround for live TV viewing without the audio patch cable. See http://tvtime.sourceforge.net/help.html#noaudio
Hence, DMA audio capture is currently limited to recording TV programs for later viewing. A few requirements come to mind. You must be able to tell the program to capture at a sample rate equal to what btaudio is providing. The default for btaudio is a rate of 32000 Hz. Most programs will try to capture at a rate of 44100 Hz so if you can't tell them otherwise what you hear will sound like Alvin and the Chipmunks :). For saa7134-based TV-capture cards, the audio rate must be set to 32000 Hz or you won't get any sound!
Also you will need to specify which DSP resource to capture from, and sometimes which channel (line-in). For me the DSP for my digital btaudio device is /dev/dsp1 as shown in the above kernel messages. There are also some other problems that occur when it comes to programs using a btaudio device. Programs use functions called ioctls to control hardware and the btaudio device does not have all of the same functions that an OSS or ALSA driver will provide. Therefore some programs will simply 'break' while attempting to access a btaudio device. Some of the time this can be worked around by patching or editing the source code of the offending program.
Current versions of mencoder (1.0preX) has support for DMA audio. Another program that needs some help is mp1e. There is a quick patch that can be applied to mp1e and it can be found in Aubin's freevo WIP directory, 'freevo/WIP/Aubin/mp1e_btaudio.diff'.
For encoding I am quite fond of the nvrec tools, http://nvrec.sf.net and find that ffmpegrec and divx4rec both work great for use with btaudio. My command lines for each of these programs is as follows:
mp1e: mp1e -v -m3 -p/dev/dsp1 -r14,100 -S32 -a0 -c/dev/video0 -s640x480 \
-b3 -o file.mpeg
key parameters: -p/dev/dsp1, the btaudio device
-r14,100, the line and volume %. 14 is line-in
-S32, the audio sample rate in kHz.
-a0, Audio mode 0 = stereo
ffmpegrec: ffmpegrec -input Television -norm NTSC -vb 1500 -vq 100 -w 640 \
-h 480 -vp 1 -d /dev/dsp1 -r 32000 -b 16 -s -ac mp2 \
-ab 128 -ap 1 -ff mpeg -o file.mpeg
key parameters: -d /dev/dsp1, the btaudio device
-r 32000, the sample rate
-b 16, 16-bit sound
-s, stereo sound
divx4rec: divx4rec -d /dev/dsp1 -r 32000 -b 16 -s -ab 128 -input Television \
-vb 1400 -vq 100 -w 480 -h 360 -o file.avi
key parameters: -d /dev/dsp1, the btaudio device
-r 32000, the sample rate
-b 16, 16-bit sound
-s, stereo sound
mencoder -tv on:driver=v4l:input=0:norm=NTSC:channel=2:chanlist=us-cable:\
width=320:height=240:outfmt=yv12:device=/dev/video0:adevice=/dev/dsp2:\
audiorate=32000:buffersize=64:forceaudio:forcechan=1 -ovc lavc -lavcopts vcodec=mpeg4:\
vbitrate=1200:keyint=30 -oac mp3lame -lameopts br=128:cbr:mode=3 -ffourcc divx \
-o /mnt/video/06-08_07:30_-_Seinfeld.avi
key parameters: adevice=/dev/dsp2 - analog btaudio
audiorate=32000 - proper sampling rate
forceaudio - needed for mencoder to force recording of audio
forcechan=1 - try 2 for stereo mode if your capture card supports it
There is since 1.0.0rc2 an equivalent of btaudio for alsa: snd-bt87x module. I use the following /etc/asound.conf:
pcm.emu10k1 {
type hw
card 0
}
ctl.emu10k1 {
type hw
card 0
}
pcm.bt87x {
type hw
card 1
}
ctl.bt87x {
type hw
card 1
}
For using mencoder with ALSA, you must specfy the option 'alsa' and as device try 'bt87x' or 'emu10k1'.
bt87x doesn't work for me (just like btaudio didn't), but emu10k1 works fine. Not using OSS has the advantage for me that I can record from line-in with volume control muted, hence ENABLING timeshift recording.
My record script, this is for a creative labs Soundblaster Live 5.1 :
#!/bin/bash
# use with this VCR_CMD:
# VCR_CMD = ('/usr/local/freevo_data/tvrecord/tvrecord %(channel)s %(seconds)s "%(filename)s"')
CHAN=$1
TIME=$2
NAME=$3
WIDTH=320
HEIGHT=240
MENCODER=/usr/local/bin/mencoder
AMIXER=/usr/bin/amixer
NICE="nice -n -20"
AUDIO="-oac mp3lame -lameopts cbr:br=128:mode=3"
VIDEO="-ovc lavc -lavcopts vcodec=mpeg4:vbitrate=1200:keyint=30"
DSP="alsa:adevice=emu10k1"
TV=" -tv driver=v4l:width=$WIDTH:height=$HEIGHT:outfmt=yuy2:input=0:device=/dev/video0:norm=PAL:chanlist=europe-west:channel=$CHAN:$DSP:forceaudio:forcechan=1:buffersize=64"
$AMIXER -q sset Line 87% mute
$AMIXER -q sset Capture 87%
$AMIXER -q cset numid=63 4 # select capture source, 63 is capture source control, 1 = CD and 4 = line
$AMIXER -q cset numid=64 1 # set capture source switch to 1 (= on)
$NICE $MENCODER tv:// $TV $VIDEO $AUDIO -endpos $TIME -ffourcc divx -o "$NAME.avi"
$AMIXER -q sset Line 87% unmute # unmute cd again to hear sound when using watching tv after recording
For saa7134-based cards, the command for recording is a bit simpler. The v4lctl program which comes with xawtv is used to set the audio input level, since the saa7134 mixer device is OSS only and aumix doesn't provide sufficient control over the volume.
The following is placed in the /etc/freevo/local_config.py file under the VCR commands section (for freevo 1.5.x). Note that I'm using /dev/dsp1 for my AUDIO_INPUT_DEVICE. I left the mixer settings alone since the default works fine. If you're inclined to change the mixer settings, use 'aumix -d /dev/mixer1 [...] (saa7134 options mixer_nr=1 used to specify mixer number). Note that 'v4lctl volume XX' only affects the analog audio level for input via the audio patch cable into your soundcard, and is not needed for DMA audio recording.
VCR_AUDIO = (':adevice=%s' % AUDIO_INPUT_DEVICE +
':audiorate=32000' + # 44100 for better sound
':forceaudio:forcechan=2:amode=1' + # Forced stereo for bug in my driver
':buffersize=64') # 64MB capture buffer, change?
VCR_PRE_REC = ('')
VCR_POST_REC = ('')
VCR_CMD = (CONF.mencoder + ' ' +
'tv:// ' + # New mplayer requires this.
'-tv driver=%s:input=%d' % (TV_DRIVER, TV_INPUT) +
':norm=%s' % CONF.tv +
':channel=%(channel)s' + # Filled in by Freevo
':chanlist=%s' % CONF.chanlist +
':width=%d:height=%d' % (TV_REC_SIZE[0], TV_REC_SIZE[1]) +
':outfmt=%s' % TV_REC_OUTFMT +
':device=%s' % TV_DEVICE +
VCR_AUDIO + # set above
' -ovc lavc -lavcopts ' + # Mencoder lavcodec video codec
'vcodec=mpeg4' + # lavcodec mpeg-4
':vbitrate=1200:' + # Change lower/higher, bitrate
'keyint=30 ' + # Keyframe every 10 secs, change?
'-oac mp3lame -lameopts ' + # Use Lame for MP3 encoding, must be enabled in mencoder!
'br=128:cbr:mode=3 ' + # MP3 const. bitrate, 128 kbit/s
'-ffourcc divx ' + # Force 'divx' ident, better compat.
'-endpos %(seconds)s ' + # only mencoder uses this so do it here.
'-o %(filename)s') # Filled in by Freevo
If someone has btaudio working with mplayer and/or mencoder please add your information to this document.
The next step is to play the resulting mpeg or avi and see if you get correct sound. If it doesn't work you may get no sound at all or chipmunks sound. Good luck!!
Use 'Movies on data' instead of 'Movies on /data' otherwise the python interpreter will fail.
The latest pre-release of Freevo uses plugins for all kind of things. The tv item is also a plugin, which can be removed by putting plugin.remove(plugin_tv) in your local_config.py.
try these Instructions
The simplest answer is any card with v4l or v4l2 drivers. The developers have had good experiences with the BTTV family of cards, produced by Hauppauge and Aver. They are typically the best supported under Linux, though the WinTV PVR cards from Hauppauge are not completely supported yet. Keep an eye on ivtv.sf.net if you're interested in hardware MPEG-2 encoding via those cards.
Digital Cable in the United States has not been standardized. There are currently no support for tuning digital tv natively in freevo at the moment. Depending on your hardware (whether you have a serial or a port for recieving IR signals (looks like a headphone jack)) you might be able to use scripts to tune your digital cable box but these scripts will unfortuneately be hardware specific. Another option maybe an IR signal sender like IRblaster but again custom scripting will be required. Digital Cable users in Europe might be able to use linuxtv.org.
The problem is to do with how mplayer grabs video, versus audio for playing television. Mplayer grabs the video from the TV card and runs it through it's own layer before putting it on the screen, the audio, on the other hand, is passed through a cable from the TV card to your sound card (in most cases) and thus there is a delay, depending on the speed of your machine between the audio, and the video showing up the screen since the video must pass through mplayer first.
A number of solutions for this are being examined; if you have a fast machine, this probably won't occur, but for slower machines, we should have a workaround shortly.
One error that prevents scheduled recordings from actually recording is as follows, check for this in the logfiles in /var/log/freevo/ NOTE: dont bother, add the fix anyways if it doesn't record. the errors sometimes never show up.
sh: relocation error: ./runtime/dll/libc.so.6: symbol _dl_debug_files, version GLIBC_2.2 not defined in file ld-linux.so.2 with link time reference
The fix for this error is adding the following inside of src/tv/record_daemon.py. Add the following line after "import os".
import os os.environ['LD_PRELOAD'] = '' # Add this line to stop GLIBC_2.X preload errors
This is a very hard question. There are 3 main factors here. Your CPU power, how much video acceleration hardware is available and what kind of video capture card you have (if any). The best thing to do is searching the freevo-user mailing list. Freevo users are quite fond of small/silent machines and much of the generally available "minihardware" has been tried & tested. You probably will find an answer there.
The Epia M10000 Mainboard is a good way to start, powerfull, and quiet. It can play DVD's and DivX using software only, but the M10000 features a hardware decoder wich can increase DVD performance further. For a complete guide to set up your Epia box go here EpiaWiki
You can have multiple capture cards in order to watch tv and record simultaneously. Recording simultaniously is not implemented (yet?).
No need to duck. This can be answered without shotguns
.Theoretically the answer is "it should be possible". All main components of Freevo (python, sdl, mplayer) have windows ports in some form or another. SDL and Python for windows is no problem, mplayer & probably some python modules will be much more of a problem. Mplayer will require at least Cygwin, and is far from as mature as its linux version. So somebody with insane patience and good knowledge of freevo, it's components, and the windows opensource ports could do it i think. Even if it would ever run on windows, you would miss out on the community and general knowledge of the freevo user/developper base.
Practically : it's way faster, better, easier and cooler to install linux and run freevo like it was intended to run.
I got a new machine and installed Linux and Freevo, but my MP3s and videos are shared on my Windows box and I want to keep them there. How do I get Freevo to connect to the share?
You need to install and configure Samba (sometimes known as SMB). Most Linux distributions support this and come ready out of the box. Check that you have Samba installed and that your kernel has support for the smbfs module. If not, you may need to install Samba and/or recompile the kernel. Next, create a mount point. As root, type in mkdir /mnt/computername where "computername" is the name of the Windows machine. Next, tell your Linux box that the share is available and should be grafted into your filesystem at /mnt/computername by editing (also as root) the file /etc/fstab and appending the following line:
//computername/sharename /mnt/computername smbfs username=toto,password=tutu,owner,user,_netdev 0 0
If the share does not require a username and password, change the "username=blah,password=blah" to "guest". The share should now be automatically mounted next time the machine is booted, or can be manually mounted with mount /mnt/computername
Finally, add the mountpoint to freevo_conf.py to make Freevo aware of it.
Be advised that audio will stream over a Samba share pretty well, but video files might be a little choppy, depending on the speed of your network and how your other machines are using it. It is highly advised to upgrade to a fast (100 megabit) ethernet and turn off bandwidth-hogging applications (P2P file sharing) if you will be watching large, high-quality, movies over a file share.
please remove /var/cache/freevo/TV.xml-0.pickled or /tmp/freevo/cache/TV.xml-0.pickled after chaning TV_CHANNELS
first you need to cd to /etc/X11/gdm/Sessions. then create a file called Freevo with the contents:
#!/bin/bash cd /usr/local/freevo exec ./freevo
you can then select this from the sessions menu when you login.
I'm running Freevo in 800x600 fullscreen but my desktop has a resolution of 1280x1024. When playing a movie in Mplayer that is scaled and black borders are applied to the video to fit the screen there is only one big black border at the bottom of the screen.
The following steps fixed that problem:
Now when opening a video, resolution is changed back to normal and MPlayer plays centered fullscreen video.
If the error looks similar to:
# ./freevo setup ./runtime/apps/freevo_python: error while loading shared libraries: libpng.so.3: cannot open shared object file: No such file or directory
Then you need to install libpng 3. The problem here is that libSDL is trying to load a library and ignoring our LD_PRELOAD. This will hopefully be fixed by SDL in a future release
Some windowmangers cause that kind of problems. To avoid it, use Freevo as windowmanger. Start Freevo with the option -fs and you get a new X-Window and the problems should be gone.
This may cause troubles with started application because there is no windowmanager. A different solution is to set MPLAYER_VO_DEV to 'sdl'. Different SDL applications seem to work with sharing fullscreen. Yet another solution is to tell your windowmanager to grab focus on all new windows. <TODO: what are the settings for tvtime, xine, etc. to do that>
Debian doesn't let us start up a new X-server by default from inside X (e.g. from Eterm). To allow
that, the file /etc/X11/Xwrapper.config has to contain the following: allowed_users=anybody
It must be readable by everybody as well. (to be continued)
If your recorded TV show is jumping a little bit up and down, when you are using the dxr3 card as output device, you have to add :norm=4 to MPLAYER_VO_DEV_OPTS in your freevo_config.py. The 4 behind the norm= is for PAL60 output. Other options are: 5 = NTSC 3 = PAL 2 = Autodetect between PAL and PAL60
You need to update mmpython to the current version. Basically this means freevo tried to use a function that doesn't exist in older versions of mmpython.
The DVD menu navigation requires xine to be installed. Also, not just any xine, one need xine-lib >= 1.0 and xine-ui (Or just called xine) >= 0.9.22. Note for RedHat 8 users. xine-lib 1.0rc2 and higher will not compile with your gcc compiler so you will want to get rc1 or update your compiler or try later versions of the lib...
You did not properly install the libsdl_ttf package prior to installing pygame. Uninstall pygame, install libsdl_ttf and then re-install pygame.
This error appears in the main log, and the text for larger TV listings will not appear. If this happens you are most likely missing the python numeric package. Install it and this error should go away.
Are you getting the following error message for tv_grab_na? Upgrade to XMLTV 5.23 or higher.
checking provider information for postal/zip code 87123, be patient.. zap2it gave us a page with no service provider options check postal/zip code or www site (maybe they're down)
You may want to look at this page http://freevo.sourceforge.net/cgi-bin/moin.cgi/NvidiaPage
or this one http://sourceforge.net/projects/nv-tv-out/
This means that the compiled runtime that is distributed with freevo does not match your system. Unfortuneately since we can not make a runtime that works everywhere users who get this message will have to install freevo dependancies using their distro version of the dependancy packages or install them from source.
The newer versions of mplayer have replaced the underscore '_' in options with a dash '-'. Change the options in your MPLAYER_ARGS_DEF in freevo_config.py to reflect this (i.e. change '-stop_xscreensaver' to '-stop-xscreensaver'). Talk about nitpicky....
Not offically however there is a patch in the TipsAndTricks section
If you make your own VCD BINs with GNU VCD Imager and then burn them to CDs using cdrdao it is possible that all of your VCDs will have the same creation date and label. (Apparently the creation date of the BIN file is used by cdrdao and if the BIN file is overwritten rather than created new each time every CD you burn would have the same creation date.) Unfortunately, freevo uses the creation date and label to name files holding metadata about the CD, so it assumes that every CD with the same creation date/time and label is the same CD and it will not bother creating new metadata for it. However, there is a way to work around this. In local_conf.py set MMPYTHON_CREATE_MD5_ID = 1. This will cause the filename of the metadata to include an md5 of the first byte of the disc and should make it more difficult for two CDs to share the same metadata file. It would also be a good idea to delete old BIN files (rather than overlay them) and create unique labels for VCDs that you burn.
