Re: [Freevo-devel] Re: skin and gui interaction
Dishi, you win :) I'm giving up :) Now that I saw the code working, and it's *really* fast, and thought about the problems I'll have to deal if I make a WM and I'm convinced that it doesn't worth. :) --- Dirk Meyer <[EMAIL PROTECTED]> escreveu: > Gustavo Sverzut Barbieri wrote: > > You can make this one work making the overlap area transparent on > one > > layer. Or in this case, have the view and listing to be the same > > object. > > I've done that by having one background, one alpha and one content > layer. Making view and listing one object isn't an option, if you > start combining objects you can't re-use them. Right now I use the > same view area code for the menu and for the mp3 player. > Ok. > > As I said, we can make OPAQUE=true and have some transparent parts > in > > the window IF we are sure that everything that's under our window > will > > not change (or will not affect our window) > > Since aubin_round1 changes the background, we couldn't use any > transparent objects -- not an option. > > >> The same? View and Listing change, for the view area the > background > >> changes based on the size of the image. > > > > Huh? Are you talking that it changes when I change from > Images->Movies > > or it changes from inside the movie, when you select another item? > > aubin_round1 has different backgrounds for movie, audio, image and > games. It's also possible that the user wants a folder specific > background. > > > No I haven't. I'm in my parents house and I have no Linux here :( > > Friday I'm home, so I'll test. Also, are you and Rob writing about > your > > changes/innovations? As I'm out for few days I "lost sync" with > your > > things :) > > I'm documenting my skin and the xml files will follow. > > >> > About the OPAQUE, I think all the windows could be opaque for > now. > >> > >> That's too easy, it's not the case with the current skins. > >> > > > > Yes it is. We will only use OPAQUE=false when we have transparent > > popups or something like that. Actually when we want to have a > popup > > shown AND the background changing. IMHO this will be used only with > > Applets and if we want these applets over the menu or something. > > You're free to try. I have five areas in my skin (screen, title, > listing, view and info). Each area class inherits from a parent class > in area.py and only does content specific stuff. These higher classes > don't even use osd.drawXXX and call a function in area. By changing > area.py you can change all areas. > > But I doubt that your area.py will be faster than mine. I made some > ugly enhancements to speed up things. > > > Making them all a monolitic GUIObject is ugly, maybe various > > GUIObjects put together with a Container is the best solution) and > > draw things like you do now, I see no problem too. > > I don't thing it's ugly. I see no reason why they all should be one > GUIObject. And I don't really draw each area after another. I only > save want they want to draw. After that, I check whats new and draw > them at the same time. It's fast and I don't see one single reason > why > I should change it. Think about it that way: each area (== separate > object) is a part of the whole screen (menuw == GUIObject). Calling > it > GUIObject and Container makes no difference. > > > The point is we need a WM to handle focus and windows redrawing. > > Do you want to set a focus from listing to view area? The screen, > info, view and title area don't need a focus, the whole menu needs > one. That is done by making the menuw a GUIObject. > > Dischi > > -- > The good thing about standards is that there are so many to choose > from. > -- Andrew S. Tanenbaum > > > > --- > This SF.net email is sponsored by: Etnus, makers of TotalView, The > debugger > for complex code. Debugging C/C++ programs can leave you feeling lost > and > disoriented. TotalView can help you find your way. Available on major > UNIX > and Linux platforms. Try it free. www.etnus.com > ___ > Freevo-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/freevo-devel ___ Busca Yahoo! O serviço de busca mais completo da Internet. O que você pensar o Yahoo! encontra. http://br.busca.yahoo.com/ --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Freevo-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freevo-devel
Re: [Freevo-devel] Recording TV
I've been meaning to reply to this. :) Right now the two recording interfaces record_daemon.py (freevo proper) and rec_interface.py (used by the web interface) compliment each other in that they each have features that would be useful to the other. I think we should start thinking about unifying these into one common interface used by both methods of recording. In another email I will outline all of the functions of each and propose how we would do this. Aubin Paul wrote: Oh, and one last thing. I'm going to have the record_daemon spit out an XML file for each recorded show, so it'll be easy to see the show information in the Extended Video menu. This would include the title, plot summary and maybe even a screenshot by using mplayer to dump a png from a random place in the stream. That's a great feature! 1. I think the freevo_record.lst should include the prog_code, used in the guide and elsewhere, which is essentially something like this: '3 CIII',20:00-22:00 Adding that would make it trivial to highlight shows scheduled for recording in the guide. rec_interface.py has support for that, scheduled recordings, favorites, and recording programs all get highlighted in their own colour. 2. We need a way to have a submenu under the TV guide for viewing the record list. It shouldn't be hard, and deleting an entry is mainly just parsing a file line by line into a menu. I'm more curious as to what remote button makes sense for there. I thought about the 'pause' button while in the guide, since it's unused but that is confusing. There are also functions in rec_interface.py to get all scheduled recordings (as shown by record.cgi), record_daemon.py probably has the same. 3. The last thing I'd like to see is a auto-scheduler based on program names. What would happen ideally is that when the epg_xmltv.py is processing the guide (something I do at 3am) it looks for certain programme names in a file, and adds them to the record list. rec_favorites.py does this also. In the same script that I get epg_xmltv.py to update the guide I get rec_facvorites.py to immediately update my recording schedule based on my favorites. We'd add a line to the Record parameters menu called "Record all (Show name)" and then add that to a list, and use the pickled guide to add the days worth of stuff. The way I handled favorites was to give the user a choice on when to record that show... from every time it comes on to just one time on one day on one channel, or any combination of those. It also supports priorities of favorites in case two or more are scheduled to come on at the same time. This part is not completely implimented yet but I also plan on accounting for the number of tuner cards in the machine. There are docs on rec_interface and rec_favorites in Docs/freevoweb. More to follow! -Rob --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Freevo-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freevo-devel
[Freevo-cvslog] freevo/src/gui LetterBox.py,1.2,1.3
Update of /cvsroot/freevo/freevo/src/gui In directory sc8-pr-cvs1:/tmp/cvs-serv20059 Modified Files: LetterBox.py Log Message: Just a quick fix to take care of redrawing when changing the letter and still seeing the previous letter though the alpha. I will have to come up with a better solution (probably using a bg_surface or something) when I hook this object up to the skin properties because if the non-selected bg_color has a transparency it will still be broken. Index: LetterBox.py === RCS file: /cvsroot/freevo/freevo/src/gui/LetterBox.py,v retrieving revision 1.2 retrieving revision 1.3 diff -C2 -d -r1.2 -r1.3 *** LetterBox.py5 Mar 2003 03:53:34 - 1.2 --- LetterBox.py7 Mar 2003 00:19:58 - 1.3 *** *** 10,13 --- 10,20 # --- # $Log$ + # Revision 1.3 2003/03/07 00:19:58 rshortt + # Just a quick fix to take care of redrawing when changing the letter and still + # seeing the previous letter though the alpha. I will have to come up with + # a better solution (probably using a bg_surface or something) when I hook + # this object up to the skin properties because if the non-selected bg_color + # has a transparency it will still be broken. + # # Revision 1.2 2003/03/05 03:53:34 rshortt # More work hooking skin properties into the GUI objects, and also making *** *** 192,205 raise TypeError, 'Not all needed variables set.' if self.selected: c = self.selected_color.get_color_sdl() a = self.selected_color.get_alpha() ! else: ! c = self.bg_color.get_color_sdl() ! a = self.bg_color.get_alpha() - box = pygame.Surface(self.get_size(), 0, 32) - box.fill(c) - box.set_alpha(a) self.osd.screen.blit(box, self.get_position()) --- 199,216 raise TypeError, 'Not all needed variables set.' + box = pygame.Surface(self.get_size(), 0, 32) + c = self.bg_color.get_color_sdl() + a = self.bg_color.get_alpha() + box.fill(c) + box.set_alpha(a) + if self.selected: + sel_box = pygame.Surface(self.get_size(), 0, 32) c = self.selected_color.get_color_sdl() a = self.selected_color.get_alpha() ! sel_box.fill(c) ! sel_box.set_alpha(a) ! box.blit(sel_box, (0,0)) self.osd.screen.blit(box, self.get_position()) --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Freevo-cvslog mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freevo-cvslog
Re: [Freevo-devel] How to use PopupBox gui item?
Brian J. Murrell wrote: I have a few moments to resume some freevo hacking. First thing I want to do, now that I see that there is an InputBox GUI item, is implemenent the password protected folder idea I have. Also please ignore any problems with the object's graphics not drawing or updating cleanly as I am working on fixing that part. :) Also I don't think InputBox gets all of the skin properties that it should care about yet, a WIP. -Rob --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Freevo-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freevo-devel
Re: [Freevo-devel] How to use PopupBox gui item?
Brian J. Murrell wrote:
Problem is that I can't seem to use InputBox where I used to use
PopupBox to display that folder was password protected. I get an
error:
Traceback (most recent call last):
File "src/main.py", line 604, in ?
main_func()
File "src/main.py", line 826, in main_func
File "src/menu.py", line 492, in eventhandler
action( menuw=self )
File "src/mediamenu.py", line 441, in cwd
skin.InputBox('Password Protected Folder')
AttributeError: Skin instance has no attribute 'InputBox'
So some hunting around suggests to me that when using the "main1"
skin, Popup box is defined skin_main1.py, not in the src/gui menu.
That is the old PopupBox, which isn't an actual object but simply get
drawn to the screen.
So how do I take advantage of src/gui stuff? My guess is that I need
to use a skin designed to use it. Am I correct? How do I go about
doing that? Which skin(s) use the stuff in src/gui?
Untill recently you could use the objects in src/gui regardless of what
skin you had. Dischi is working on a new skin which provides some
information about the skin configuration to the src/gui objects. These
objects now make a call to the skin to configure the look & feel,
therefore they will only work with the new skin. The sin in progress is
skins/dischi1/skin_dischi1.py.
For examples of some of the gui code I have a modified audioitem.py
which demontrates an object when play() is called. To see this go into
WIP/RobShortt and make uitest. This will copy over your existing
audioitem.py. Then just go 'play' an mp3 to get a popup. You may edit
the audioitem.py and comment/uncomment lines in the play function to see
some of the new objects in action.
-Rob
---
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger
for complex code. Debugging C/C++ programs can leave you feeling lost and
disoriented. TotalView can help you find your way. Available on major UNIX
and Linux platforms. Try it free. www.etnus.com
___
Freevo-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freevo-devel
[Freevo-devel] How to use PopupBox gui item?
I have a few moments to resume some freevo hacking. First thing I
want to do, now that I see that there is an InputBox GUI item, is
implemenent the password protected folder idea I have.
Problem is that I can't seem to use InputBox where I used to use
PopupBox to display that folder was password protected. I get an
error:
Traceback (most recent call last):
File "src/main.py", line 604, in ?
main_func()
File "src/main.py", line 826, in main_func
File "src/menu.py", line 492, in eventhandler
action( menuw=self )
File "src/mediamenu.py", line 441, in cwd
skin.InputBox('Password Protected Folder')
AttributeError: Skin instance has no attribute 'InputBox'
So some hunting around suggests to me that when using the "main1"
skin, Popup box is defined skin_main1.py, not in the src/gui menu.
So how do I take advantage of src/gui stuff? My guess is that I need
to use a skin designed to use it. Am I correct? How do I go about
doing that? Which skin(s) use the stuff in src/gui?
Thanx,
b.
--
Brian J. Murrell
pgp0.pgp
Description: PGP signature
[Freevo-cvslog] freevo freevo_config.py,1.138,1.139
Update of /cvsroot/freevo/freevo In directory sc8-pr-cvs1:/tmp/cvs-serv23325 Modified Files: freevo_config.py Log Message: Arg Index: freevo_config.py === RCS file: /cvsroot/freevo/freevo/freevo_config.py,v retrieving revision 1.138 retrieving revision 1.139 diff -C2 -d -r1.138 -r1.139 *** freevo_config.py6 Mar 2003 21:39:32 - 1.138 --- freevo_config.py6 Mar 2003 21:42:07 - 1.139 *** *** 60,70 # is different, there will be only a warning ! FREEVO_CONF_VERSION = 1.1 ! LOCAL_CONF_VERSION = 2.0 # Description of changes in each new version ! FREEVO_CONF_CHANGES = [ ! (1.1, ! '''Added MPLAYER_ARGS_AUDIOCD for aido cd playback settings.'''),] LOCAL_CONF_CHANGES = [ --- 60,68 # is different, there will be only a warning ! FREEVO_CONF_VERSION = 1.0 ! LOCAL_CONF_VERSION = 2.1 # Description of changes in each new version ! FREEVO_CONF_CHANGES = [] # None so far LOCAL_CONF_CHANGES = [ *** *** 79,83 '''Remote control config has changed from Freevo Python files to the standard Lirc program config files, see freevo_config.py for ! more info.''')] --- 77,83 '''Remote control config has changed from Freevo Python files to the standard Lirc program config files, see freevo_config.py for ! more info.'''), ! (2.1, ! '''Added MPLAYER_ARGS_AUDIOCD for aido cd playback settings.''')] --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Freevo-cvslog mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freevo-cvslog
[Freevo-cvslog] freevo/skins/dischi1 blue1_big.xml,1.9,1.10 info_area.py,1.1,1.2
Update of /cvsroot/freevo/freevo/skins/dischi1
In directory sc8-pr-cvs1:/tmp/cvs-serv23691
Modified Files:
blue1_big.xml info_area.py
Log Message:
Added mp3 player view area. You can set the infos you want to see in the
skin. @VAR@ means insert a variable from the item object here, \t means
next col (currently only two cols are supported). I don't like the
delimiter @@ and \t, but I don't have a better idea (&var; doesn't work
because pyXML want's to replace it)
Index: blue1_big.xml
===
RCS file: /cvsroot/freevo/freevo/skins/dischi1/blue1_big.xml,v
retrieving revision 1.9
retrieving revision 1.10
diff -C2 -d -r1.9 -r1.10
*** blue1_big.xml 5 Mar 2003 22:13:37 - 1.9
--- blue1_big.xml 6 Mar 2003 21:45:23 - 1.10
***
*** 168,172
!
--- 168,181
!
! Title: [EMAIL PROTECTED]@
! Artist: [EMAIL PROTECTED]@
! Album: [EMAIL PROTECTED]@ (@year@)
! Track: [EMAIL PROTECTED]@
!
! Length: [EMAIL PROTECTED]@
! Elapsed: [EMAIL PROTECTED]@
!
Index: info_area.py
===
RCS file: /cvsroot/freevo/freevo/skins/dischi1/info_area.py,v
retrieving revision 1.1
retrieving revision 1.2
diff -C2 -d -r1.1 -r1.2
*** info_area.py5 Mar 2003 21:55:21 - 1.1
--- info_area.py6 Mar 2003 21:45:24 - 1.2
***
*** 10,13
--- 10,20
# ---
# $Log$
+ # Revision 1.2 2003/03/06 21:45:24 dischi
+ # Added mp3 player view area. You can set the infos you want to see in the
+ # skin. @VAR@ means insert a variable from the item object here, \t means
+ # next col (currently only two cols are supported). I don't like the
+ # delimiter @@ and \t, but I don't have a better idea (&var; doesn't work
+ # because pyXML want's to replace it)
+ #
# Revision 1.1 2003/03/05 21:55:21 dischi
# empty info area
***
*** 39,42
--- 46,51
from skin_utils import *
+ import re
+
TRUE = 1
FALSE = 0
***
*** 49,53
--- 58,68
def __init__(self, parent, screen):
Skin_Area.__init__(self, 'info', screen)
+ self.re_space= re.compile('^\t *(.*)')
+ self.re_var = re.compile('@[a-z_]*@')
+ self.re_table= re.compile('^(.*)t(.*)')
+ self.last_item = None
+ self.auto_update = []
+ self.table = []
def update_content_needed(self):
***
*** 55,59
check if the content needs an update
"""
! return FALSE
--- 70,74
check if the content needs an update
"""
! return self.auto_update or (self.last_item != self.item)
***
*** 62,65
update the info area
"""
! pass
!
--- 77,165
update the info area
"""
! settings = self.settings
! layout= self.layout
! area = self.area_val
! content = self.calc_geometry(layout.content, copy_object=TRUE)
! item = self.item
!
! if not settings.font.has_key(content.font):
! print '*** font <%s> not found' % content.font
! return
!
! font = settings.font[content.font]
!
! table = [ [], [] ]
! self.auto_update = []
!
! for line in content.cdata.encode('Latin-1').split('\n'):
! m = self.re_space.match(line)
! if m:
! line = m.groups(1)[0]
!
! has_vars = FALSE
! autoupdate = ''
! vars_exists= FALSE
!
! for m in self.re_var.findall(line):
! has_vars = TRUE
! repl = ''
! if hasattr(item, m[1:-1]):
! if m[1:-1] == 'year':
! if not item.year:
! repl = ''
! else:
! repl = str(item.year)
! elif m[1:-1] == 'length':
! if not item.length:
! repl = ''
! else:
! repl = '%d:%02d' % (int(item.length / 60),
! int(item.length % 60))
! elif m[1:-1] == 'elapsed':
! autoupdate = 'elapsed'
! repl = '%d:%02d' % (int(item.elapsed / 60),
! int(item.elapsed % 60))
! else:
! repl = str(eval('item.%s' % m[1:-1]))
!
! if repl:
! line = re.sub(m, repl, line)
! vars_exi
[Freevo-cvslog] freevo/skins/dischi1 xml_skin.py,1.19,1.20
Update of /cvsroot/freevo/freevo/skins/dischi1
In directory sc8-pr-cvs1:/tmp/cvs-serv23560
Modified Files:
xml_skin.py
Log Message:
Added text as content
Index: xml_skin.py
===
RCS file: /cvsroot/freevo/freevo/skins/dischi1/xml_skin.py,v
retrieving revision 1.19
retrieving revision 1.20
diff -C2 -d -r1.19 -r1.20
*** xml_skin.py 5 Mar 2003 21:57:15 - 1.19
--- xml_skin.py 6 Mar 2003 21:42:57 - 1.20
***
*** 10,13
--- 10,16
# ---
# $Log$
+ # Revision 1.20 2003/03/06 21:42:57 dischi
+ # Added text as content
+ #
# Revision 1.19 2003/03/05 21:57:15 dischi
# Added audio player. The info area is empty right now, but this skin
***
*** 367,373
--- 370,378
'height', 'font', 'align', 'valign', 'color'))
self.types = {}
+ self.cdata = ''
def parse(self, node, scale, current_dir):
XML_data.parse(self, node, scale, current_dir)
+ self.cdata = node.textof()
for subnode in node.children:
if subnode.name == u'item':
***
*** 376,381
--- 381,388
self.types[type] = XML_data(('font', 'align', 'valign'))
self.types[type].rectangle = None
+ self.types[type].cdata = ''
if type:
self.types[type].parse(subnode, scale, current_dir)
+ self.types[type].cdata = subnode.textof()
for rnode in subnode.children:
if rnode.name == u'rectangle':
***
*** 386,389
--- 393,397
self.types['default'] = XML_data(('font',))
self.types['default'].rectangle = None
+ self.types['default'].cdata = ''
---
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger
for complex code. Debugging C/C++ programs can leave you feeling lost and
disoriented. TotalView can help you find your way. Available on major UNIX
and Linux platforms. Try it free. www.etnus.com
___
Freevo-cvslog mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freevo-cvslog
[Freevo-cvslog] freevo freevo_config.py,1.137,1.138
Update of /cvsroot/freevo/freevo In directory sc8-pr-cvs1:/tmp/cvs-serv22234 Modified Files: freevo_config.py Log Message: Added MPLAYER_ARGS_AUDIOCD Index: freevo_config.py === RCS file: /cvsroot/freevo/freevo/freevo_config.py,v retrieving revision 1.137 retrieving revision 1.138 diff -C2 -d -r1.137 -r1.138 *** freevo_config.py4 Mar 2003 05:43:39 - 1.137 --- freevo_config.py6 Mar 2003 21:39:32 - 1.138 *** *** 60,68 # is different, there will be only a warning ! FREEVO_CONF_VERSION = 1.0 LOCAL_CONF_VERSION = 2.0 # Description of changes in each new version ! FREEVO_CONF_CHANGES = [] # None yet LOCAL_CONF_CHANGES = [ (1.1, --- 60,71 # is different, there will be only a warning ! FREEVO_CONF_VERSION = 1.1 LOCAL_CONF_VERSION = 2.0 # Description of changes in each new version ! FREEVO_CONF_CHANGES = [ ! (1.1, ! '''Added MPLAYER_ARGS_AUDIOCD for aido cd playback settings.'''),] ! LOCAL_CONF_CHANGES = [ (1.1, *** *** 458,461 --- 461,465 MPLAYER_ARGS_TVVIEW = '-nocache' MPLAYER_ARGS_DVDNAV = '-dvdnav' + MPLAYER_ARGS_AUDIOCD = '-cache 500 -cdda speed=1' MPLAYER_USE_WID = 1 --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Freevo-cvslog mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freevo-cvslog
[Freevo-cvslog] freevo/src/audio audiodiskitem.py,1.9,1.10
Update of /cvsroot/freevo/freevo/src/audio
In directory sc8-pr-cvs1:/tmp/cvs-serv21809/src/audio
Modified Files:
audiodiskitem.py
Log Message:
moved mplayer options to freevo_config.py
Index: audiodiskitem.py
===
RCS file: /cvsroot/freevo/freevo/src/audio/audiodiskitem.py,v
retrieving revision 1.9
retrieving revision 1.10
diff -C2 -d -r1.9 -r1.10
*** audiodiskitem.py6 Mar 2003 21:33:26 - 1.9
--- audiodiskitem.py6 Mar 2003 21:38:35 - 1.10
***
*** 146,151
item = AudioItem('cdda://%d' % (i+1), self, None, title)
item.set_info('', self.name, title, i+1, self.disc_id[1], '')
! item.mplayer_options = '-cdda speed=1 -cache 1000 -cdrom-device %s' % \
!self.devicename
if self.devicename:
item.mplayer_options += ' -cdrom-device %s' % self.devicename
--- 146,150
item = AudioItem('cdda://%d' % (i+1), self, None, title)
item.set_info('', self.name, title, i+1, self.disc_id[1], '')
! item.mplayer_options = config.MPLAYER_ARGS_AUDIOCD
if self.devicename:
item.mplayer_options += ' -cdrom-device %s' % self.devicename
---
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger
for complex code. Debugging C/C++ programs can leave you feeling lost and
disoriented. TotalView can help you find your way. Available on major UNIX
and Linux platforms. Try it free. www.etnus.com
___
Freevo-cvslog mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freevo-cvslog
[Freevo-cvslog] freevo/src/audio audiodiskitem.py,1.8,1.9
Update of /cvsroot/freevo/freevo/src/audio
In directory sc8-pr-cvs1:/tmp/cvs-serv19360
Modified Files:
audiodiskitem.py
Log Message:
set cd speed to 1
Index: audiodiskitem.py
===
RCS file: /cvsroot/freevo/freevo/src/audio/audiodiskitem.py,v
retrieving revision 1.8
retrieving revision 1.9
diff -C2 -d -r1.8 -r1.9
*** audiodiskitem.py25 Feb 2003 05:31:48 - 1.8
--- audiodiskitem.py6 Mar 2003 21:33:26 - 1.9
***
*** 146,150
item = AudioItem('cdda://%d' % (i+1), self, None, title)
item.set_info('', self.name, title, i+1, self.disc_id[1], '')
! item.mplayer_options = '-cache 1000 -cdrom-device %s' % self.devicename
if self.devicename:
item.mplayer_options += ' -cdrom-device %s' % self.devicename
--- 146,151
item = AudioItem('cdda://%d' % (i+1), self, None, title)
item.set_info('', self.name, title, i+1, self.disc_id[1], '')
! item.mplayer_options = '-cdda speed=1 -cache 1000 -cdrom-device %s' % \
!self.devicename
if self.devicename:
item.mplayer_options += ' -cdrom-device %s' % self.devicename
---
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger
for complex code. Debugging C/C++ programs can leave you feeling lost and
disoriented. TotalView can help you find your way. Available on major UNIX
and Linux platforms. Try it free. www.etnus.com
___
Freevo-cvslog mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freevo-cvslog
[Freevo-cvslog] freevo/src osd.py,1.20,1.21
Update of /cvsroot/freevo/freevo/src In directory sc8-pr-cvs1:/tmp/cvs-serv4808 Modified Files: osd.py Log Message: catch empty strings first Index: osd.py === RCS file: /cvsroot/freevo/freevo/src/osd.py,v retrieving revision 1.20 retrieving revision 1.21 diff -C2 -d -r1.20 -r1.21 *** osd.py 1 Mar 2003 17:27:29 - 1.20 --- osd.py 6 Mar 2003 21:06:04 - 1.21 *** *** 10,13 --- 10,16 # --- # $Log$ + # Revision 1.21 2003/03/06 21:06:04 dischi + # catch empty strings first + # # Revision 1.20 2003/03/01 17:27:29 dischi # *** empty log message *** *** *** 1050,1053 --- 1053,1059 if not pygame.display.get_init(): + return None + + if not string: return None --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Freevo-cvslog mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freevo-cvslog
[Freevo-cvslog] freevo/src/gui GUIObject.py,1.8,1.9
Update of /cvsroot/freevo/freevo/src/gui In directory sc8-pr-cvs1:/tmp/cvs-serv15254 Modified Files: GUIObject.py Log Message: Remove the GUI object from the parent when the parent changes Index: GUIObject.py === RCS file: /cvsroot/freevo/freevo/src/gui/GUIObject.py,v retrieving revision 1.8 retrieving revision 1.9 diff -C2 -d -r1.8 -r1.9 *** GUIObject.py5 Mar 2003 03:53:34 - 1.8 --- GUIObject.py6 Mar 2003 19:13:14 - 1.9 *** *** 8,11 --- 8,14 #--- # $Log$ + # Revision 1.9 2003/03/06 19:13:14 dischi + # Remove the GUI object from the parent when the parent changes + # # Revision 1.8 2003/03/05 03:53:34 rshortt # More work hooking skin properties into the GUI objects, and also making *** *** 387,390 --- 390,396 """Set the parent of this widget """ + if self.parent != parent and self.parent and self in self.parent.children: + self.parent.children.remove(self) + self.parent = parent --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Freevo-cvslog mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freevo-cvslog
[Freevo-devel] Re: skin and gui interaction
Gustavo Sverzut Barbieri wrote: > You can make this one work making the overlap area transparent on one > layer. Or in this case, have the view and listing to be the same > object. I've done that by having one background, one alpha and one content layer. Making view and listing one object isn't an option, if you start combining objects you can't re-use them. Right now I use the same view area code for the menu and for the mp3 player. > As I said, we can make OPAQUE=true and have some transparent parts in > the window IF we are sure that everything that's under our window will > not change (or will not affect our window) Since aubin_round1 changes the background, we couldn't use any transparent objects -- not an option. >> The same? View and Listing change, for the view area the background >> changes based on the size of the image. > > Huh? Are you talking that it changes when I change from Images->Movies > or it changes from inside the movie, when you select another item? aubin_round1 has different backgrounds for movie, audio, image and games. It's also possible that the user wants a folder specific background. > No I haven't. I'm in my parents house and I have no Linux here :( > Friday I'm home, so I'll test. Also, are you and Rob writing about your > changes/innovations? As I'm out for few days I "lost sync" with your > things :) I'm documenting my skin and the xml files will follow. >> > About the OPAQUE, I think all the windows could be opaque for now. >> >> That's too easy, it's not the case with the current skins. >> > > Yes it is. We will only use OPAQUE=false when we have transparent > popups or something like that. Actually when we want to have a popup > shown AND the background changing. IMHO this will be used only with > Applets and if we want these applets over the menu or something. You're free to try. I have five areas in my skin (screen, title, listing, view and info). Each area class inherits from a parent class in area.py and only does content specific stuff. These higher classes don't even use osd.drawXXX and call a function in area. By changing area.py you can change all areas. But I doubt that your area.py will be faster than mine. I made some ugly enhancements to speed up things. > Making them all a monolitic GUIObject is ugly, maybe various > GUIObjects put together with a Container is the best solution) and > draw things like you do now, I see no problem too. I don't thing it's ugly. I see no reason why they all should be one GUIObject. And I don't really draw each area after another. I only save want they want to draw. After that, I check whats new and draw them at the same time. It's fast and I don't see one single reason why I should change it. Think about it that way: each area (== separate object) is a part of the whole screen (menuw == GUIObject). Calling it GUIObject and Container makes no difference. > The point is we need a WM to handle focus and windows redrawing. Do you want to set a focus from listing to view area? The screen, info, view and title area don't need a focus, the whole menu needs one. That is done by making the menuw a GUIObject. Dischi -- The good thing about standards is that there are so many to choose from. -- Andrew S. Tanenbaum --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Freevo-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freevo-devel
Re: [Freevo-devel] Recording TV
On Thu, Mar 06, 2003 at 09:57:01AM -0500, Aubin Paul wrote: > > I have a folder under "Watch Movies" called 'Recording' and it > contains the files that are recorded. The files are tagged by date and > time, and then by show name and title. Like this: > > 03-02 9:00pm - The Simpsons - "Treehouse of Horror XI" > 03-03 9:30pm - The Daily Show with John Stewart Yes, that would work. But the waste of screen-space on the right must truncate the names somewhat. IMHO, the picklist should use the full width of the screen and forget the eye-candy. That spot on the right for "icons" might work alright for MP3s with putting an album cover there or something, but do you really need to see an icon for a recorded television program? That space should be given to the date/time/program/episide-title information. > I'm not sure what space is wasted. On my screen I have an info bar on > the top, a vertical menu on the right 2/3 of the screen and room for > cover images Yes. Do you really need a cover image for a television program? You are sacrificing being able to see details about an episode just to see a picture of what? A single frame in the episode? Surely using that space to give more textual information is of more use. > on the left. In my hacked MP3 player, the cover image > shows the album title, year and total track length under the cover. Yes. For MP3 player that is fine. But for television programs, what could you put in the "cover image" that would be of any real use in conveying information about the episode? > Shouldn't be too bad; Python isn't usually slower than C in my > experience, at least not in this type of application. A brute force search where you have thousands or tens of thousands of loop iterations and comparison operations? I doubt Python will be any better at it than Perl was. C is orders of magnitude faster at it than Perl was. In any case, lots of iterations has not been needed for my small list of choices, so Python would probably work. But somebody out there is going to have a lot of choices and complain that the process is too slow and processor intensive. > What /will/ happen is that scheduled shows (since they're processed in > advance) will be highlighted in red in the TV guide, and if you want > to record at that time, it'll cancel the scheduled record. Just cancel it? It won't try to find the same program/episode on at another time? This is the entire point of the scheduler. It finds repeated episodes and uses them to work out the best schedule of recording such that the user gets as much as they can. This is also why time-slot based recording totally sucks. If you record based on name, you can let a process find the best time to record it. > Hmm... that might work, though in fairness, I'm not recording that > much yet so conflicts haven't happened yet. You will and they will. > The current model doesn't > handle conflicts at all, but it's not impossible to do 1:1 conflicts. > I'm not sure how to handle multiple conflicts without a logic like > scoring. Well, scoring along with taking advantage of repeating episodes is the way to do it. > Scoring would probably help that; I don't see how. If you keep track of programs that you have seen/recorded before, their score is automatically nil due to the fact that you aren't going to even consider the need to record it again. Scoring really has nothing to do with not recording previously recorded programs. > I would imagine that the "Season > Pass" What is a "Season Pass list"? > list would have scores, I'm not sure how to add them to the main > recording menu without making it overly complex. I suppose we could > set a default of, say, one below high priority. Yes, programs have a default score. As the user is notified of un-automatically-resolvable conflicts, he should be given the opportunity to alter the score of one or more of the programs involved in the conflict so that it records what he wants this time and in the future. > That I'd be interested in; because it sounds like the only way I would do > it is to sort an array of shows by priority and pick the highest one. Kinda like that. Basically for every conflict that involves an episode that has a repeat showing you have double the number of _possible_ schedules. You double for every occurance of that. You can see why, when using powers of 2 the number of tests you have to do can grow quite quickly. You go through each possible schedule, adding up the scores of the programs that would be recorded in that schedule and choose the one that yeilds the highest score. > I haven't done that, but mostly, hitting the 60 second fast forward > handles most of the commercials. I do that when I watch mp1e recorded programs (and it's less annoying that watching commercials, but still annoying), but when I watch stuff I recorded with MJPEG, I have to transcode to MPEG4 anyway, so before I transcode, I edit out the commercials. Nice for watching and
Re: [Freevo-devel] Recording TV
--- "Brian J. Murrell" <[EMAIL PROTECTED]> escreveu: > On Tue, Mar 04, 2003 at 01:12:33AM -0500, Aubin Paul wrote: > This really needs to be addressed, as well as the real-estate issue > in > general. I have ony used the "default" skin, but I find that it > wastes too much screen space to "eye candy" and does not give enough > space to the business at hand... choosing media to play. It would be > nice if there were a no-nonesense, low-eye-candy-lots of well-used > real-estate skin. Oh, with a scrollable media chooser. Next/Prev > page just sucks. > Press "d" (DISPLAY) when in movies menu. You'll have a preliminary Extended Menu. In near future, that will be the default and you will have more menu states: text-listing, icon-listing + view + info, icon-listing. And text-listing should not use the submenu (Prev/Next) anymore. > But I digress... > > > 3. The last thing I'd like to see is a auto-scheduler based on > program > > names. > > I have that written already, albeit in `C', for efficiency. If I get > time (not hopeful) I might try re-writing it in Python just to test > out my python skills. :-) > > > What would happen ideally is that when the epg_xmltv.py is > > processing the guide (something I do at 3am) it looks for certain > > programme names in a file, and adds them to the record list. > > And what happens if that adding causes conflicts? That is what my > scheduler deals with. > > > A programme list file or "Season Pass" would look something like a > > file with line by line shows, when epg_xmltv.py runs, it would > compare > > this list to the processed guide, and auto-schedule the favourites. > > > You need scoring for programs to help resolve conflicts in a way that > you get what you want recorded and some heuristics to try and do the > right thing. For instance, it has been my experience that programs > that have episode titles normally, do not have them when the episode > is a repeat. You want to decrease a programs score in that instance. > > > We'd add a line to the Record parameters menu called "Record all > (Show > > name)" and then add that to a list, and use the pickled guide to > add > > the days worth of stuff. > > You also want to track what you have recorded, again for optimal > conflict resolution. For instance, you do not want to record an > episode of a program you have already seen at the expense of another > show who's episode you have not seen. > Sure. > > This should be dead simple to add and if you process your guide in > the > > middle of the night, almost invisible to the user. > > Conflict resolution _can_ be processor intensive. If you have a lot > of programs in your "wanted" list, you will wind up with a large > matrix of conflicts that you have to resolve by brute force. My > experience (with my recording schedule) is that this is not an issue. > It was in one of my early implementations but I found an optimization > that reduced searches by many orders of magnitude. > Great. > > I've started the plugin stuff for the different encoders, I have > mp1e > > working now, but I want to make sure we have one for mencoder > before I > > commit anything. > > I will want one for lavrec, but that should be quite easy. Your > encoder plugin model is like the "record" script from my OpenPVR > project. > > > Last of all, let me just recommend the recording stuff to anyone > who > > hasn't tried it. I don't think I've watched live television in a > week! > > Not watching live TV rules! 'Specially so when you take a couple of > minutes before watching to remove all commercials. Then you sit and > watch a whole program without having to touch the remote. > > I have been thinking about recording architure design a bit. > > I used to think at and at jobs were sufficient to manage recording > but > I have since changed my mind. > > This is my idea of a recording framework: > > It all revolves around a scheduling daemon. The daemon accepts > inputs > of several varieties. It will of course take a list of programs by > name, but also by recurring date/time (I usually refer to this as > "timeslot" programming and avoid it at all costs because it's > unreliable) or simply by a one-time date/time specification. > > The daemon re-evaluates the recording schedule after every input > change and always has a chronological list of what's going to be > recorded for as far out as it has information. If you have 2 weeks > of > XMLTV data, your scheduler will know what it's going to record for > the > next 2 weeks. > > Of course, what is going to record could change at any time due to > new > input (manual or XMLTV fed). Indeed, I would give it a whole new 2 > week XMLTV schedule every day, to keep up with the programming > changes > that happen on North American television networks on a daily basis. > > But even entering a one-time programming request (with score) could > change the schedule as a conflict resolution is performed after every > in
Re: [Freevo-devel] Re: skin and gui interaction
--- Dirk Meyer <[EMAIL PROTECTED]> escreveu: > Gustavo Sverzut Barbieri wrote: > > --- Dirk Meyer <[EMAIL PROTECTED]> escreveu: > Ho > >> That's a nice idea, and I tried that. But there are some problems: > if > >> we draw overlapping transparent rectangles for blue_round1, we > don't > >> want the color to overlapp. > > > > I didn't understant that. > > Look at blue1_round1 and go into the movie/mp3/image menu (the normal > one). You see a transparent background for the listing and one for > the > view area. These backgrounds overlap (you can see that when you > select > an item without image. If you draw these background on different > layers and blit them together, the second rectangle will darken > everything which is below it. Below means the background _and_ the > other rectangle and the space they share gets darken than the rest. > You can make this one work making the overlap area transparent on one layer. Or in this case, have the view and listing to be the same object. > >> But the most important problem: it's too > >> slow. We would redraw most of the screen all the time (areas can > >> overlap) and blitting something is slow, blitting an alpha surface > >> into a surface is very slow. And one very important problem: the > >> areas > >> depend on each other, one has to be redrawn when another changes. > >> > > > > Why? I don't understand. > > What I meant with OPAQUE maybe wasn't very clear. > > It was clear. I tried something similar to your proposal. It worked > fine until I got to the view area. > > > A Window could be opaque but have transparent areas. The OPAQUE > > thing means we just don't care with things are under this window: > we > > don't redraw them. > > We can't do that, beacuse ... > > > IE: the info area has rounded corners and transparent BG. > > ... the round corders are part of the background. The small space at > the corners where the round is has to be the original background. And > if the background below that transparent background changes, we have > to redraw the transparent part, too. > As I said, we can make OPAQUE=true and have some transparent parts in the window IF we are sure that everything that's under our window will not change (or will not affect our window) > > However we know that the screen BG never change. So we can make > > Info.OPAQUE=TRUE. > > Wrong. For Aubins new skin the background changes on the main menu > for > each item. The background can also change for different folders. > See my other email, "WindowManager", there I said that in that case we can make the MainMenuListing a GUIObject and the MainMenuIcon another, being MainMenuListing OPAQUE=false > > The same with View and Listing. > > The same? View and Listing change, for the view area the background > changes based on the size of the image. > Huh? Are you talking that it changes when I change from Images->Movies or it changes from inside the movie, when you select another item? > > But the real slow part for us, Menus, will become really fast. > > Have you tried my new skin? It's much faster than before. Because > every area is aware of all the others I can redraw only the parts I > want to change. > No I haven't. I'm in my parents house and I have no Linux here :( Friday I'm home, so I'll test. Also, are you and Rob writing about your changes/innovations? As I'm out for few days I "lost sync" with your things :) > > About the OPAQUE, I think all the windows could be opaque for now. > > That's too easy, it's not the case with the current skins. > Yes it is. We will only use OPAQUE=false when we have transparent popups or something like that. Actually when we want to have a popup shown AND the background changing. IMHO this will be used only with Applets and if we want these applets over the menu or something. > > > >> What I have done (with Robs help): the skin is _no_ GUIObject. The > >> skin is only a set of drawing functions. The menuwidget is a > >> GUIObject which fills the hole screen. The menuwidget can be > drawn, > >> shown, hiden like all other GUIObjects. It uses the skin functions > >> to draw itself. Since the menuwidget is one GUIObject, background, > >> listing, view, info and title area aren't GUIObjects, they are > only > >> part of one GUIObject. With this design I can redraw the changed > >> parts of the skin very fast, it would be much slower (you will > >> notice that even on a fast computer) with separate GUIObjects for > >> each area. > >> > > > > As i said before, I see no reason for that. > > I hope you understand now. I tried, it didn't work out. But I don't > see way we should have different GUIObjects for each area. The menu > is > one big GUIObject, it's fast and why should everything be an extra > GUIObject? > I think having multiple windows with GUIObjects inside are easy. in my mind it should work like Mandrake installation: it is a bunch of windows placed right on the screen, the look is like a one window wi
[Freevo-devel] Mouse input?
Hello, I would like to use a wireless mouse as the "remote control" for my freevo-machine. I have a Logitech optical wireless (radio) mouse with mouse wheel. I think it could be a nice input device, switch live TV channels with the mouse wheel, or by pushing the left mouse button, and getting a popup menu with all the channels (maybe with what show is currently on). Hardwarewise, it seems easier than installing an IR remote to my computer, and furthermore I intend to have my freevo machine in another room than my TV, for noise reasons. So, esteemed freevo hackers, I would like to ask what issues would be involved with adding mouse support. One very simple way (but maybe not satisfactory) would be to map mouse movements to up/down/left/right buttons, and mouse buttons to the space key or something like that. But it would not be as nice as having a mouse cursor I think when navigating the TV guide (I might be wrong though). Thanks for any input! --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Freevo-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freevo-devel
[Freevo-devel] [PATCH] Fix Time zone bug in xmltv schedule processing
Here is a patch for the previously described bug in handling of time zones in the +0100 form in xml files. Note that this leaves a bug with written time zones still in the code. See a thread I started on the xmltv-devel list about the problems with interpreting time zone abbreviations: http://sourceforge.net/mailarchive/forum.php?thread_id=1784917&forum_id=7180 I'm trying to get the xmltv people to make +0100 style time zone specifications mandatory, which would be the only reasonable fix to this bug as I see it. This is my first patch to freevo, and I'm also new to Pyton so let me know if I messed up somewhere. Krister Lagerstrom wrote: Actually, I think the Python mx.DateTime module is probably better for stuff like this. It is included in the newer binary Freevo releases. The docs are on the net. Thanks for the tip! I looked at the docs at http://www.lemburg.com/files/python/mxDateTime.html, and it looks to me as though it doesn't handle arbitrary time zones. Regards, Erland patch_xmltv-tzbug.tar.gz Description: Unix tar archive
Re: [Freevo-devel] Recording TV
On Wed, Mar 05, 2003 at 07:55:05PM -0500, Brian J. Murrell wrote: > I have lots of experience at this part. I hope I can help, at least > with suggestions if not code. The latter will depend on my time. That works for me :) > I must admit that I am still not using Freevo, but maybe that can > change soon. How are you using the UI to choose recorded television > program to watch? Are you just using the "Movies" menu? How do you > know that you are watching program episodes in the order they were > shown without any kind of date display or date sort on that menu? I have a folder under "Watch Movies" called 'Recording' and it contains the files that are recorded. The files are tagged by date and time, and then by show name and title. Like this: 03-02 9:00pm - The Simpsons - "Treehouse of Horror XI" 03-03 9:30pm - The Daily Show with John Stewart > This really needs to be addressed, as well as the real-estate issue in > general. I have ony used the "default" skin, but I find that it > wastes too much screen space to "eye candy" and does not give enough > space to the business at hand... choosing media to play. It would be > nice if there were a no-nonesense, low-eye-candy-lots of well-used > real-estate skin. Oh, with a scrollable media chooser. Next/Prev > page just sucks. I'm not sure what space is wasted. On my screen I have an info bar on the top, a vertical menu on the right 2/3 of the screen and room for cover images on the left. In my hacked MP3 player, the cover image shows the album title, year and total track length under the cover. > I have that written already, albeit in `C', for efficiency. If I get > time (not hopeful) I might try re-writing it in Python just to test > out my python skills. :-) Shouldn't be too bad; Python isn't usually slower than C in my experience, at least not in this type of application. > And what happens if that adding causes conflicts? That is what my > scheduler deals with. What /will/ happen is that scheduled shows (since they're processed in advance) will be highlighted in red in the TV guide, and if you want to record at that time, it'll cancel the scheduled record. The only thing I need to do to get that to work is to add that info to the record file. > You need scoring for programs to help resolve conflicts in a way that > you get what you want recorded and some heuristics to try and do the > right thing. For instance, it has been my experience that programs > that have episode titles normally, do not have them when the episode > is a repeat. You want to decrease a programs score in that instance. Hmm... that might work, though in fairness, I'm not recording that much yet so conflicts haven't happened yet. The current model doesn't handle conflicts at all, but it's not impossible to do 1:1 conflicts. I'm not sure how to handle multiple conflicts without a logic like scoring. > You also want to track what you have recorded, again for optimal > conflict resolution. For instance, you do not want to record an > episode of a program you have already seen at the expense of another > show who's episode you have not seen. Scoring would probably help that; I would imagine that the "Season Pass" list would have scores, I'm not sure how to add them to the main recording menu without making it overly complex. I suppose we could set a default of, say, one below high priority. > Conflict resolution _can_ be processor intensive. If you have a lot > of programs in your "wanted" list, you will wind up with a large > matrix of conflicts that you have to resolve by brute force. My > experience (with my recording schedule) is that this is not an issue. > It was in one of my early implementations but I found an optimization > that reduced searches by many orders of magnitude. That I'd be interested in; because it sounds like the only way I would do it is to sort an array of shows by priority and pick the highest one. > I will want one for lavrec, but that should be quite easy. Your > encoder plugin model is like the "record" script from my OpenPVR > project. Should be easy enough; just write a small python script and set a variable. > Not watching live TV rules! 'Specially so when you take a couple of > minutes before watching to remove all commercials. Then you sit and > watch a whole program without having to touch the remote. I haven't done that, but mostly, hitting the 60 second fast forward handles most of the commercials. I don't know if I could watch shows and manually set commercial breaks, though, hypothetically, there is no reason it would be difficult, since we intercept the remote before it's passed to mplayer, and we could just split based on those breaks. > It all revolves around a scheduling daemon. The daemon accepts inputs > of several varieties. It will of course take a list of programs by > name, but also by recurring date/time (I usually refer to this as > "timeslot" programming and avoid it at all costs because it's > unre
