Re: [Freevo-users] WinTV-1800

2009-03-10 Thread Chris Thomas
I've had a HVR-1800 for almost a year now and have yet to get it
(standard cable tuning) working in Gentoo. From what I've read the
digital tuner works using mplayer. I haven't fiddled with it
recently this thread is helpful:

http://ubuntuforums.org/showthread.php?t=785476

-Chris


On Mon, Mar 9, 2009 at 11:59 PM, Davin Desborough
freevol...@desboroughs.net wrote:
 I have been happily using Freevo with my PVR-250 for several years now
 After taking the Freevo survey, however, I am inspired to upgrade my
 freevo box (both hardware and software). I am considering my options for
 digital cable solutions. Has anyone used a Hauppauge WINTV-HVR-1800? Are
 there other cards that are deemed to have better support in Linux? I've
 done some reading of the Freevo wiki (as well as some others), but I
 wanted to get some first-hand opinions from the list.

 Thanks,
 Davin

 --
 ___
 Freevo-users mailing list
 Freevo-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/freevo-users


--
___
Freevo-users mailing list
Freevo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freevo-users


Re: [Freevo-users] Problem watching live TV with mplayer

2009-03-10 Thread Duncan Webb
Art S R wrote:
 Hi Duncan,
 
 I tried 'v4l2-ctl --set-freq=187.250' but nothing changed on the Freevo
 window playing live TV -- it still displayed the ghosted random
 station.  I then issued 'v4l2-ctl --all' and noticed that the Video
 Standard is set to PAL even though it should have been NTSC as it was
 passed to the mplayer command in the 'norm=NTSC' parameter.  When I
 issued 'v4l2-ctl --set-standard=ntsc', then the correct station popped
 up in the Freevo TV window.  However, if I hit Esc to return to the
 Freevo TV guide and select any station, it displays the garbage screen
 again and 'v4l2-ctl --all' shows that Freevo had changed the Video
 Standard back to PAL.
 
 I even grabbed the svn version of mplayer.py, but it made no difference.
 
 Any ideas why the exact same command, when issued outside of Freevo,
 displays the station correctly but, when passed by Freevo to mplayer, 
 the video standard is changed from NTSC to PAL?

Would need to see what TV settings you have in your local_conf.py to see
what could be causing this problem. Will you post the TV_ settings from
you local_conf.py?

Duncan

--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
___
Freevo-users mailing list
Freevo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freevo-users


Re: [Freevo-users] SVN version 11339 is not working?

2009-03-10 Thread Duncan Webb
Han Hartgers wrote:
 Dear all,
 
 I tried to upgrade freevo from SVN but that did not work so well. (Can
 happen; is the general idea of unstable versions.)  I had first a
 working freevo 1.8.4 from SVN just after 1.8.3 was released and that
 version worked very well. But I wanted more and upgrades to a newer
 SVN version...
 
 The symptoms:
 
 First I got error messages in the log that a module has not the
 propperty connect; but that came from Kaa. After installing the
 latest SVN version of Kaa were those errors solved.
 
 But still is freevo not starting properly.
 
 freevo webserver start does not come back to the shell. It does
 start the webserver process. This is the same as Art S R mentions in
 his email of 4 March.

Try freevo webserver --daemon.

 Starting Freevo from a terminal (with freevo); gives the start
 screen, but does not go past the progress bar page.
 going back to the terminal and pressing ctrl-C stops some process and
 gives me the normal freevo menu screen.
 
 I have in my .xsession at the end the line exec freevo and that does
 start not freevo. I see only the basic screen of my window manager and
 main-1001.log is not made.
 Looks a bit as a similar problem as Joost Kop mentions in his email of
 17 February.
 http://sourceforge.net/mailarchive/message.php?msg_name=499B1139.5070806%40freevo.org

Try freevo --dry-run it will show but not execute the command that the
freevo script will execute.

Then try freevo --debug and this will create a script that will run
main.py with the pdb module loaded. Skips the freevo script that is a
wrapper for main module.

 I get the impression that spawning the different process/applications
 is not working correctly anymore.

This is possible, it does work for me with both X and DirectFB, but
can't check all possible combinations.

Duncan

--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
___
Freevo-users mailing list
Freevo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freevo-users


Re: [Freevo-users] Recording start time is late (Freevo 1.8.3)

2009-03-10 Thread Duncan Webb
Art S R wrote:
 I checked my Freevo 1.7.x installation (where recordings start at the
 correct time) and see that recordserver.py (revision 9844) has some code
 to check for the top of the minute in startMinuteCheck(self) and
 minuteCheck(self).  These aren't in recordserver.py for Freevo 1.8.3. 
 Is there some other routine in the current version that syncs
 recordserver to start recordings at the beginning of the minute (0
 seconds) instead of 45 seconds later?

It is quite unusual for a broadcaster to be so punctual with their
broadcast times. The default should start recording 15 seconds before
the program is due to start recording, this is intended so that the TV
card will be fully operational when the program starts. The IVTV cards
take a few seconds to get the MPEG stream steady.

It is quite possible that the code is incorrect and starts recording 45
seconds late. Need to test the code for the problem that you have described.

The way I get round this is to use the VPS signal (PAL only?) which
tells a VCR when a programme is really starting and finishing; then
start recording from this point and stop it when the programme has
finished. There may well be a similar process to for NTSC.

Duncan

 I noticed that the beginnings of my recorded TV programs were
 truncated, so I looked in recordserver-1000.log and saw that
 recordserver was starting all recordings 45 seconds *after* the
 scheduled start time for each program:
 
 2009-03-04 17:30:45,001 INFO recordserver.py (944): going to
 record: Wed Mar 04 17:30-18:00 (17:30)  I9.28458213.microsoft.com
 http://I9.28458213.microsoft.com BBC World News
 2009-03-04 17:30:45,004 INFO recordserver.py (962): start
 recording: Wed Mar 04 17:30-18:00 (17:30) 
 I9.28458213.microsoft.com http://I9.28458213.microsoft.com BBC
 World News
 2009-03-04 17:30:45,516 INFO recordserver.py (1329):
 RECORD_START Wed Mar 04 17:30-18:00 (17:30) 
 I9.28458213.microsoft.com http://I9.28458213.microsoft.com BBC
 World News
 2009-03-04 17:59:51,116 INFO recordserver.py (1337): RECORD_STOP
 Wed Mar 04 17:30-18:00 (17:30)  I9.28458213.microsoft.com
 http://I9.28458213.microsoft.com BBC World News
 
 In the sample above, the recording should have started at 17:30:00,
 but it started at 17:30:45 instead.  My local_conf.py has
 'TV_RECORD_PADDING_PRE = 0', so the recordings should be starting at
 the designated time.  Anyway, I decided to compensate by changing
 this value to 'TV_RECORD_PADDING_PRE = 45'.  However, this resulted
 in the recordings starting 15 seconds *before* the scheduled start
 time, as shown below (17:59:45 instead of the expected 18:00:00):
 
 2009-03-05 17:59:45,003 INFO recordserver.py (944): going to
 record: Thu Mar 05 18:00-18:30 (18:00)  I28.28460456.microsoft.com
 http://I28.28460456.microsoft.com BBC World News
 2009-03-05 17:59:45,006 INFO recordserver.py (962): start
 recording: Thu Mar 05 18:00-18:30 (18:00) 
 I28.28460456.microsoft.com http://I28.28460456.microsoft.com BBC
 World News
 2009-03-05 17:59:45,520 INFO recordserver.py (1329):
 RECORD_START Thu Mar 05 18:00-18:30 (18:00) 
 I28.28460456.microsoft.com http://I28.28460456.microsoft.com BBC
 World News
 2009-03-05 18:29:59,563 INFO recordserver.py (1337): RECORD_STOP
 Thu Mar 05 18:00-18:30 (18:00)  I28.28460456.microsoft.com
 http://I28.28460456.microsoft.com BBC World News
 
 I played around with various values for TV_RECORD_PADDING_PRE and
 found that if the value is 15 to 45, recordings will start 15
 seconds too early.  If the value is less than 15, then recordings
 will start 45 seconds too late.  I see that there's in comment in
 local_conf.py that, although the padding time is designated in
 seconds, precision is only at the minute level.  This could explain
 why I couldn't set a start time in between 15 seconds too early or
 45 seconds too late (-15 secs to +45 secs = 60 secs).  However, I am
 able to set TV_RECORD_PADDING_POST to sub-minute precision.  In the
 first set of log entries above, note that the stop time for the
 program was at 51 seconds (9 seconds before the scheduled stop
 time).  I added some seconds to TV_RECORD_PADDING_POST and you'll
 note in the second set of log entries that stop time was at 59
 seconds (1 second before the scheduled stop time).  In other words,
 I was able to tweak the stop time by a few seconds via
 TV_RECORD_PADDING_POST, but a similar action with
 TV_RECORD_PADDING_PRE did not yield any change less than 60 seconds
 (1 minute).
 
 Anyway, I can accept the inprecision of TV_RECORD_PADDING_PRE, but
 how can I get my recordings to start exactly at the scheduled start
 time without trying to compensate via TV_RECORD_PADDING_PRE (which
 doesn't yield good results anyway -- 15 

Re: [Freevo-users] Recording start time is late (Freevo 1.8.3)

2009-03-10 Thread Art S R
Hi Duncan,

Unfortunately, many US cable stations run their programs back-to-back with
no commercial breaks in-between programs.  Indeed, the closing scene and
narrative are broadcast simultaneously with the closing credits.  As soon as
the credits end, the next program starts.  They put their commercials
(adverts) elsewhere during the program.

Anyway, I found that recordserver.py has the following code to delay the
start of recording until 45 seconds into the minute, so I changed it to
sec=0:
kaa.AtTimer(recordserver.handleAtTimer).start(sec=45)
Now, recording starts at the top of the minute.

The one remaining problem is that, if I have consecutive recordings, the
second program's start time is delayed by 1 minute.  This occurs even when
using all the default settings (sec=45 in recordserver.py and no PRE/POST
recording padding values in local_conf.py).  In the recordserver log, it
shows overlap_duration=0, yet the second recording doesn't start
immediately even though the previous program has already ended:

2009-03-09 22:29:50,898 INFO recordserver.py (1337): RECORD_STOP Mon Mar
09 22:00-22:30 (22:00)  I6.28455235.microsoft.com Frasier
2009-03-09 22:30:45,002 INFO recordserver.py (910): overlap_duration=0
2009-03-09 22:30:45,004 INFO recordserver.py (924): CALLED RECORD STOP
1: Mon Mar 09 22:00-22:30 (22:00)  I6.28455235.microsoft.com Frasier
2009-03-09 22:30:45,005 INFO recordserver.py (942): delaying: Mon Mar 09
22:30-23:00 (22:30)  I12.28456406.microsoft.com Family Guy
2009-03-09 22:31:45,002 INFO recordserver.py (944): going to record: Mon
Mar 09 22:30-23:00 (22:30)  I12.28456406.microsoft.com Family Guy
2009-03-09 22:31:45,005 INFO recordserver.py (962): start recording: Mon
Mar 09 22:30-23:00 (22:30)  I12.28456406.microsoft.com Family Guy

In my Freevo 1.7.3 installation, the second program starts immediately after
the first program ends, without the 1 minute delay.

Art S R


On Tue, Mar 10, 2009 at 1:40 PM, Duncan Webb dun...@freevo.org wrote:

 Art S R wrote:
  I checked my Freevo 1.7.x installation (where recordings start at the
  correct time) and see that recordserver.py (revision 9844) has some code
  to check for the top of the minute in startMinuteCheck(self) and
  minuteCheck(self).  These aren't in recordserver.py for Freevo 1.8.3.
  Is there some other routine in the current version that syncs
  recordserver to start recordings at the beginning of the minute (0
  seconds) instead of 45 seconds later?

 It is quite unusual for a broadcaster to be so punctual with their
 broadcast times. The default should start recording 15 seconds before
 the program is due to start recording, this is intended so that the TV
 card will be fully operational when the program starts. The IVTV cards
 take a few seconds to get the MPEG stream steady.

 It is quite possible that the code is incorrect and starts recording 45
 seconds late. Need to test the code for the problem that you have
 described.

 The way I get round this is to use the VPS signal (PAL only?) which
 tells a VCR when a programme is really starting and finishing; then
 start recording from this point and stop it when the programme has
 finished. There may well be a similar process to for NTSC.

 Duncan

  I noticed that the beginnings of my recorded TV programs were
  truncated, so I looked in recordserver-1000.log and saw that
  recordserver was starting all recordings 45 seconds *after* the
  scheduled start time for each program:
 
  2009-03-04 17:30:45,001 INFO recordserver.py (944): going to
  record: Wed Mar 04 17:30-18:00 (17:30)  I9.28458213.microsoft.com
  http://I9.28458213.microsoft.com BBC World News
  2009-03-04 17:30:45,004 INFO recordserver.py (962): start
  recording: Wed Mar 04 17:30-18:00 (17:30)
  I9.28458213.microsoft.com http://I9.28458213.microsoft.com BBC
  World News
  2009-03-04 17:30:45,516 INFO recordserver.py (1329):
  RECORD_START Wed Mar 04 17:30-18:00 (17:30)
  I9.28458213.microsoft.com http://I9.28458213.microsoft.com BBC
  World News
  2009-03-04 17:59:51,116 INFO recordserver.py (1337): RECORD_STOP
  Wed Mar 04 17:30-18:00 (17:30)  I9.28458213.microsoft.com
  http://I9.28458213.microsoft.com BBC World News
 
  In the sample above, the recording should have started at 17:30:00,
  but it started at 17:30:45 instead.  My local_conf.py has
  'TV_RECORD_PADDING_PRE = 0', so the recordings should be starting at
  the designated time.  Anyway, I decided to compensate by changing
  this value to 'TV_RECORD_PADDING_PRE = 45'.  However, this resulted
  in the recordings starting 15 seconds *before* the scheduled start
  time, as shown below (17:59:45 instead of the expected 18:00:00):
 
  2009-03-05 17:59:45,003 INFO recordserver.py (944): going to
  record: Thu Mar 05 18:00-18:30 (18:00)  I28.28460456.microsoft.com
  http://I28.28460456.microsoft.com BBC 

[Freevo-users] Fwd: Problem watching live TV with mplayer

2009-03-10 Thread Art S R
-- Forwarded message --
From: Art S R arty94...@gmail.com
Date: Tue, Mar 10, 2009 at 2:58 PM
Subject: Re: [Freevo-users] Problem watching live TV with mplayer
To: dun...@freevo.org


Hi Duncan,

Here are the relevant lines from my local_conf.py:

NORM = 'ntsc'
INPUT = 'television'
CHANLIST = 'us-cable'
TV_DRIVER = 'v4l2'
TV_DEVICE = '/dev/video0'
TV_INPUT = 0
TV_SETTINGS = 'NORM INPUT CHANLIST DEVICE'

I used the same values in my previous Freevo installations (1.6.x, 1.7.x)
and did not have problems watching live TV with the mplayer plugin.

Thanks,

Art SR


On Tue, Mar 10, 2009 at 1:08 PM, Duncan Webb dun...@freevo.org wrote:

 Art S R wrote:
  Hi Duncan,
 
  I tried 'v4l2-ctl --set-freq=187.250' but nothing changed on the Freevo
  window playing live TV -- it still displayed the ghosted random
  station.  I then issued 'v4l2-ctl --all' and noticed that the Video
  Standard is set to PAL even though it should have been NTSC as it was
  passed to the mplayer command in the 'norm=NTSC' parameter.  When I
  issued 'v4l2-ctl --set-standard=ntsc', then the correct station popped
  up in the Freevo TV window.  However, if I hit Esc to return to the
  Freevo TV guide and select any station, it displays the garbage screen
  again and 'v4l2-ctl --all' shows that Freevo had changed the Video
  Standard back to PAL.
 
  I even grabbed the svn version of mplayer.py, but it made no difference.
 
  Any ideas why the exact same command, when issued outside of Freevo,
  displays the station correctly but, when passed by Freevo to mplayer,
  the video standard is changed from NTSC to PAL?

 Would need to see what TV settings you have in your local_conf.py to see
 what could be causing this problem. Will you post the TV_ settings from
 you local_conf.py?

 Duncan

--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com___
Freevo-users mailing list
Freevo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freevo-users


Re: [Freevo-users] SVN version 11339 is not working?

2009-03-10 Thread Han Hartgers
 freevo webserver start does not come back to the shell. It does
 start the webserver process. This is the same as Art S R mentions in
 his email of 4 March.

 Try freevo webserver --daemon.

 Starting Freevo from a terminal (with freevo); gives the start
 screen, but does not go past the progress bar page.
 going back to the terminal and pressing ctrl-C stops some process and
 gives me the normal freevo menu screen.

 I have in my .xsession at the end the line exec freevo and that does
 start not freevo. I see only the basic screen of my window manager and
 main-1001.log is not made.
 Looks a bit as a similar problem as Joost Kop mentions in his email of
 17 February.
 http://sourceforge.net/mailarchive/message.php?msg_name=499B1139.5070806%40freevo.org

 Try freevo --dry-run it will show but not execute the command that the
 freevo script will execute.

 Then try freevo --debug and this will create a script that will run
 main.py with the pdb module loaded. Skips the freevo script that is a
 wrapper for main module.

 I get the impression that spawning the different process/applications
 is not working correctly anymore.

 This is possible, it does work for me with both X and DirectFB, but
 can't check all possible combinations.

 Duncan

Hi Duncan,

Thanks for your response. Good to know that the latest SVN versions of
Freevo and KAA are working. I will try them this evening and use them
as base to debug what is going wrong in my configuration.

I did for sure not use the correct options on the command line. And I
did see a lot of changes too the KAA system and the process handling.
Maybe that there is somewhere the reason of my troubles.

Greetings,

Han

--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
___
Freevo-users mailing list
Freevo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freevo-users


[Freevo-users] can't control via tcp remote

2009-03-10 Thread Wookjin, Na
hi , 

I have a question. It makes me dizzy. please help me...

I used to remote control the freevo via tcp. 

but this control not work when I played a movie with xine. 

just only volume up,down and mute works well.

I checked text control message with print received via TCP.

I do not have any idea why freevo remote control is not working when I used to 
TCP remote.

but UDP works well, I tried to work with remote.py (in helper's folder)


by the way, when I first start a freevo, tcp port is settup twice so It made 
error message of port is occupied 

that's not important i think . because I made it port number increasing. so It 
just passed.


thanks in advance.

--
 Wook-Jin, Na (wookj...@mewtel.com)
 Research Engineer, F/W team, Wireless SoC Division, MewTel Technology Inc.
 Phone : 070-7097-4991  Mobile : 010-7920-0997  FAX : 02-468-0257
 [H/Q] 27F, Prime Center, 546-4, Guui-dong, Gwangjin-gu, Seoul, Korea
 [RD] #1004, KwangGaeTo Bldg. Sejong Univ. 98, Kunja-dong, Gwangjin-gu, Seoul, 
Korea
 ; man proposes, God disposes

Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com___
Freevo-users mailing list
Freevo-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freevo-users