John Molohan wrote: > Stephen Rowles wrote: >>> Stephen >>> >>> >>>> TV Watching: >>>> >>>> TV watching would be much better if it was like a stand alone PVR, I >>>> would >>>> like to see fastforward and rewind (I realise things like mplayer and >>>> xine >>>> have issues with these) working, pause, and record working while >>>> watching >>>> TV. >>>> >>> What part of this is not working? XIne handles already with ivtv >>> supported cards, and I believe mplayer supports this for the rest. I >>> get pause fast forward rewind and when the next xine release (already >>> works with the SVN) comes out VCR style record when you hit the >>> button. If it is notwokring for you it maybe a config issue. If you >>> mean some then more then details please, I am curios about what other >>> PVR features to look forward to (never actually used a stand alone >>> PVR). >>> >> It might work for ivtv, it doesn't work for DVB ;) I should have made that >> a bit clearer! A lot of this is made better with the dvbstreamer plug-in >> but fast forward and rewind do not work, at least not in the sense that >> any end user would be expecting, fast forward does not mean "skip >> 30seconds" and rewind does not mean "skip back 30 seconds". Fast forward >> and rewind are a continuous operation, most PVR's support this at multiple >> speeds from 2x -> 16x in both directions. I would like to see that in >> Freevo (I understand this may well depend on xine / mplayer, but it still >> something I would like to see). >> > Couldn't agree more there. I know it's a xine/mplayer issue (and you can > ffwd to a certain extent) but it really is awkward. >> Other PVR function includes things like On Screen Display of current >> channel while watching TV, moving through channels on screen with now/next >> appearing at the bottom of the screen to pick another channel without >> having to stop viewing the program you are watching. And of course the >> infamous "red button" functionality for DVB. >> > I would have thought that if this was implemented for xine using the pvr > plugin (ivtv) it shouldn't be too hard for DVB to do the same. Guess it > just needs someone to write a couple of patches :) >> >>>> Missing from the list is a more consistent control system with less >>>> unique >>>> commands. Having a separate key for stop and back seems silly, and >>>> again >>>> >>> Not seeing what the problem with seperate buttons for Stop and back. >>> Makes a lot sense to me, different functions different buttons. What >>> exactly are you seeing as a problem? >>> >> Having different buttons for back and stop is a waste of time and confuses >> end users. Why do you need 2 buttons, they have the same function. Back >> goes back up menu items, back when playing media stops playing and moves >> back to the menu, why do you need to have "stop"? >> > On my setup back goes back when in menus but detaches the player when > listening to audio. Two legitimate uses there. Also stop would be > universally expected and understood as a function whereas pressing back > (which normally is used for menu navigation) to stop media playback > wouldn't be as intuitive. > >> Why is there enter and select as different buttons, why are they used >> inconsistently? Sometimes select shows a sub menu, sometimes (TV guide) it >> shows the full description of the program and you have to press a >> different key to get the sub menu. Then on top of that there is a Play >> button which has a 3rd meaning, do we really need that many buttons? I >> could see the argument for 2, but 3? So far I have been unable to get what >> I would consider a sensible and easy to use key configuration without >> going in and changing the freevo plug-ins for things like TV. >> > Agree with you here, I'm not sure why more than two are needed. Again > maybe someone could grep the source and see if there's any real > difference. If not it could be a relatively straightforward patch.
I agree to, it confused me at first, I still don't see why SELECT and ENTER should be different. It's useful to have a play, pause and a stop. Stop and exit could be combined together, when the detach function has been removed. Take a look at src/events.py, it's easy to read even for non-programmers, The interesting it is towards the bottom, which does the mappings. If you come up with a list of mapping that you would like to see, if they are okay and nobody objects I'll happily commit them. >> Minimising controls, or at least supporting simpler controls, will make >> freevo much easier to use. As it stands when my mother in law comes to >> visit she cannot really use the TV because the control system is too >> complicated to explain. That is my target audience for my control >> comments. An aim to allow full functionality for the mac remote would be a >> good target. That has 6 buttons: >> >> http://a248.e.akamai.net/7/248/51/3025041174545801/www.info.apple.com/images/kbase/302504/302504_2.jpg >> >> effectively: >> >> up >> down >> left >> right >> play/pause >> menu Have you tried MENU_ARROW_NAVIGATION=True, when it is on then right doesn't do a page down but a select and left does an exit. This means that menu needs to be mapped to DISPLAY and STOP. But this could be a bit tricky as DISPLAY is normally passed on to the application to toggle it's OSD. But you also have to consider people with lots of buttons... :) >>>> This would also help with people using things like the apple remote, >>>> easy >>>> navigation / control is possible with a small number of buttons, I think >>>> freevo should slim down it's button usage dramatically to make life >>>> easier. >>>> >>> I have a nice Hauppague remote now, but I have used freevo just fine a >>> much smaller remote, 4 nav buttons, play,stop,ff,rr, vol+/-, ok,menu. >>> Your average DVD player these days has more buttons on the remote. I >>> think the real solution here is better documentation on how to >>> configure a remote to better work in freevo. Partly true about the documentation to the events could be optimized and made more consistent. >> I would be very interested in how you have this setup just using the >> freevo local config and lirc config. If it is simply a case of documenting >> this properly then I would love to see some updates on the wiki that would >> help. >> > Me too, the poor old wiki is awful neglected :( The wiki is a *community* tool, this means that *anyone* can contribute to the wiki and it's really better for users of freevo to do this than developers as they see freevo from a different perspective. I know it's a great benefit to have a good wiki. Duncan ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Freevo-users mailing list Freevo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freevo-users
