Hi,
Should this happen? (i.e., is it a bug?)
I tried pointing my browser to the freevo recordserver port 18001, and
get the following errors (from /var/log/freevo/recordserver*):
2004/06/18 12:31 MYT [HTTPChannel,0,127.0.0.1] 127.0.0.1 - - [18/Jun/2004:04:31:27
+] GET / HTTP/1.1 500 10924
Lewis Thompson wrote:
This patch just adds some FreeBSD-specific stuff that does some
brute-force checking instead of using s = ioctl(fd, CDIO... (which
doesn't work). I've tested this on my machine and it works fine. It
would be nice if somebody could fix the ioctl stuff but unfortunately
I'm adding some further observations below:
On Fri, 18 Jun 2004, Wan Tat Chee wrote:
Hi,
I'm finally trying to get TV recording working on my config.
Found out that freevo after viewing TV, would set all input volumes to 0
and mute them. This causes scheduled recordings to fail since the
Wan Tat Chee wrote:
Should this happen? (i.e., is it a bug?)
I tried pointing my browser to the freevo recordserver port 18001, and
Recordserver is not meant to speak to a web browser, it only talks
XML-RPC over HTTP.
-Rob
---
This SF.Net email
Hi Brian,
I've merged your patch into CVS. I think I've seen this type of
behaviour before, especially if you leave the recordserver running for
weeks at a time.
It looks like it's safe to use even if your system doesn't suffer from
this type of drift.
Thanks,
Aubin
On Wed, Jun 16, 2004 at
On Fri, 2004-06-18 at 08:13 -0400, Aubin Paul wrote:
Hi Brian,
Hi Aubin,
I've merged your patch into CVS.
Great!
I think I've seen this type of
behaviour before, especially if you leave the recordserver running for
weeks at a time.
Which I do. Once Freevo is up, it doesn't usually come
Hi,
(Patch attached)
I've made some changes to the VCR_CMD configuration in freevo_config.py to
include the mixer control commands using information on the RecordingInfo
page in the Wiki. I would think it's applicable to all users except those
recording via DMA audio capture. (The Wiki page
