Re: [Freevo-users] more 1.7.5 issues, xine doesn't appear to be doing xvmc any more
Stephen Rowles wrote: Stephen Rowles wrote: Duncan Webb wrote: Memory is a very good suggestion, I have reverted back to 1.7.1 and this seems more stable and my wife was able to use the media centre to watch several programs today without the media centre crashing. I have noticed that xine playback now uses less CPU than before and playback is more reliable and responsive. Ok, I've finally got more memory (512meg so now plenty to spare) and got 1.7.6.1 installed. Everything seems to work, and I don't have the nightmare case I had before where playback was not working properly (I can skip etc. quite well), so I think I hit a memory boundary as you suggested. So for future reference Fedora with Freevo 1.7.6 and only 128meg RAM doesn't work very well! It still seems like playback is using more CPU than before, but I will have to do some more testing to find out. In general the whole system is more responsive than before, so I must have been just on the edge of swap last time round. It still isn't as responsive as 1.7.1, but it is just a feeling and certainly not as hideous as last time. I can't quite remember when the event handling was added, this could make a slight difference to the responsiveness of freevo. As far as memory is concerned I guess if elementtree is anything like tinyxml/ticpp (C++) then a 3MB xml file is exploded to 40MB DOM tree. So it could explain why the freevo would use more memory. I really wouldn't expect freevo to use more cpu, except now it is handling the stdout and stderr streams. It is possible that subprocess is more intensive than popen. What you can try is to use the childapp.py from 1.7.1 with 1.7.6.1 (it may or may not work). Duncan - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Freevo-users mailing list Freevo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freevo-users
Re: [Freevo-users] more 1.7.5 issues, xine doesn't appear to be doing xvmc any more
Stephen Rowles wrote: Duncan Webb wrote: The only thing that I can think of is that freevo is using more memory and you have just gone over the top of the physical memory. You can check this with Dag Wieers' dstat or vmstat program. Duncan Memory is a very good suggestion, I have reverted back to 1.7.1 and this seems more stable and my wife was able to use the media centre to watch several programs today without the media centre crashing. I have noticed that xine playback now uses less CPU than before and playback is more reliable and responsive. Ok, I've finally got more memory (512meg so now plenty to spare) and got 1.7.6.1 installed. Everything seems to work, and I don't have the nightmare case I had before where playback was not working properly (I can skip etc. quite well), so I think I hit a memory boundary as you suggested. So for future reference Fedora with Freevo 1.7.6 and only 128meg RAM doesn't work very well! It still seems like playback is using more CPU than before, but I will have to do some more testing to find out. In general the whole system is more responsive than before, so I must have been just on the edge of swap last time round. It still isn't as responsive as 1.7.1, but it is just a feeling and certainly not as hideous as last time. If I find out more I will report back. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Freevo-users mailing list Freevo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freevo-users
Re: [Freevo-users] more 1.7.5 issues, xine doesn't appear to be doing xvmc any more
I am seeing the same sort of slowdown using Xine with xxmc viewing Live TV with the tv.ivtv_xine_tv plugin. On Feb 1, 2008 5:55 PM, Stephen Rowles [EMAIL PROTECTED] wrote: Duncan Webb wrote: I've been testing this but the CPU usage of xine is not affected by freevo. Using a matrox G400DH the CPU usage is about 80% with or without freevo running. The only thing that I can think of is that freevo is using more memory and you have just gone over the top of the physical memory. You can check this with Dag Wieers' dstat or vmstat program. What you can do is a testing install, using the howto in the wiki and then you can have different versions installed and see if there is any real difference. http://doc.freevo.org/SourceSVNInstallation Duncan - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ Freevo-users mailing list Freevo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freevo-users
Re: [Freevo-users] more 1.7.5 issues, xine doesn't appear to be doing xvmc any more
I am actually seeing the same thing on the 1.8 svn not on the 1.7 branch. I don't use it to watch Live TV often, so I tried it out after I update the svn yesterday (after about a month or two without updating) and the video is unwatchable. It doesn't seem to be responding to any key strokes either, as a side issue. Hitting ESC and/or Q just freezes the screen. On Feb 5, 2008 1:36 PM, Duncan Webb [EMAIL PROTECTED] wrote: Justin Wetherell wrote: I am seeing the same sort of slowdown using Xine with xxmc viewing Live TV with the tv.ivtv_xine_tv plugin. What was you previous release? Between releases 1.7.5 and 1.7.6 there have no changes to tv.ivtv_xine_tv or childapp. Duncan - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ Freevo-users mailing list Freevo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freevo-users
Re: [Freevo-users] more 1.7.5 issues, xine doesn't appear to be doing xvmc any more
This problem might be unrelated. When looking at /var/log/freevo/xine- stderr-0.log I noticed a problem. It was looking for the XvMCConfig file in /usr/X11R6/lib/X11/ but mine was located in /etc/X11/, so I made a link from /etc/X11/XvMCConfig to /usr/X11R6/lib/X11/. and it seemed to solve the problem. The weird thing is this problem didn't exist before I updated the svn or when I ran Xine from outside of Freevo. Maybe this is the same problem he is having? or maybe I am insane On Feb 5, 2008 1:55 PM, Justin Wetherell [EMAIL PROTECTED] wrote: I am actually seeing the same thing on the 1.8 svn not on the 1.7 branch. I don't use it to watch Live TV often, so I tried it out after I update the svn yesterday (after about a month or two without updating) and the video is unwatchable. It doesn't seem to be responding to any key strokes either, as a side issue. Hitting ESC and/or Q just freezes the screen. On Feb 5, 2008 1:36 PM, Duncan Webb [EMAIL PROTECTED] wrote: Justin Wetherell wrote: I am seeing the same sort of slowdown using Xine with xxmc viewing Live TV with the tv.ivtv_xine_tv plugin. What was you previous release? Between releases 1.7.5 and 1.7.6 there have no changes to tv.ivtv_xine_tv or childapp. Duncan - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ Freevo-users mailing list Freevo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freevo-users
Re: [Freevo-users] more 1.7.5 issues, xine doesn't appear to be doing xvmc any more
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Justin Wetherell wrote: | This problem might be unrelated. When looking at | /var/log/freevo/xine-stderr-0.log I noticed a problem. It was looking | for the XvMCConfig file in /usr/X11R6/lib/X11/ but mine was located in | /etc/X11/, so I made a link from /etc/X11/XvMCConfig to | /usr/X11R6/lib/X11/. and it seemed to solve the problem. The weird thing | is this problem didn't exist before I updated the svn or when I ran Xine | from outside of Freevo. Maybe this is the same problem he is having? or | maybe I am insane Just a wild guess but is it possible that you have two versions of xine on your system? In freevo.conf the absolute path is used to xine but from the command line it will use the first it finds. Easy enough to find out with: which -a xine Not much has been changed, that could cause this, such as changing the PATH environment. I'm a a bit of a loss to figure out what could cause this. Duncan | I am actually seeing the same thing on the 1.8 svn not on the 1.7 | branch. I don't use it to watch Live TV often, so I tried it out | after I update the svn yesterday (after about a month or two without | updating) and the video is unwatchable. It doesn't seem to be | responding to any key strokes either, as a side issue. Hitting ESC | and/or Q just freezes the screen. | | | On Feb 5, 2008 1:36 PM, Duncan Webb [EMAIL PROTECTED] | mailto:[EMAIL PROTECTED] wrote: | | Justin Wetherell wrote: | I am seeing the same sort of slowdown using Xine with xxmc | viewing Live | TV with the tv.ivtv_xine_tv plugin. | | What was you previous release? | | Between releases 1.7.5 and 1.7.6 there have no changes to | tv.ivtv_xine_tv or childapp. | | Duncan | | | | | | | - | This SF.net email is sponsored by: Microsoft | Defy all challenges. Microsoft(R) Visual Studio 2008. | http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ | | | | | ___ | Freevo-users mailing list | Freevo-users@lists.sourceforge.net | https://lists.sourceforge.net/lists/listinfo/freevo-users -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHqMaENi6l+Xvys44RAudgAJ9eJo31MCcVE2utUDd9aHSR1F+H8wCggE94 rPBrzn7aBnZxPxF7ibww+4E= =YEB+ -END PGP SIGNATURE- - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Freevo-users mailing list Freevo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freevo-users
Re: [Freevo-users] more 1.7.5 issues, xine doesn't appear to be doing xvmc any more
Stephen Rowles wrote: Richard van Paasen wrote: Is xine eating up the cpu (check with 'top')? If you have a (VIA) unichrome video chipset, check the ~/.xine/config file of the user that runs freevo. There is an entry for saving cpu cycles: video.device.unichrome_cpu_save = 1 This takes down the cpu load from 40% to 10% on my box with xxmc output. Richard. Xine was eating the CPU, but the odd thing is that I ran my standalone test command as the same user I run freevo with (root, yes I know but it is fire-walled off from the world). I have no idea what is causing the problem, but I'm giving up and reverting to 1.7.2 which I was running before with no problems, I will do that tomorrow evening. I have literally changed nothing else between installs, only freevo has changed, but my media centre is now a mess, crashing on playback of video, not recording correctly etc. I will report back if reverting to 1.7.2 helps, or if this is just a co-incidence and something else happens to have failed / started failing at the same time :) If reverting doesn't work at least I will know for sure that something other than freevo is broken. I've been testing this but the CPU usage of xine is not affected by freevo. Using a matrox G400DH the CPU usage is about 80% with or without freevo running. The only thing that I can think of is that freevo is using more memory and you have just gone over the top of the physical memory. You can check this with Dag Wieers' dstat or vmstat program. What you can do is a testing install, using the howto in the wiki and then you can have different versions installed and see if there is any real difference. http://doc.freevo.org/SourceSVNInstallation Duncan - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Freevo-users mailing list Freevo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freevo-users
Re: [Freevo-users] more 1.7.5 issues, xine doesn't appear to be doing xvmc any more
Duncan Webb wrote: I've been testing this but the CPU usage of xine is not affected by freevo. Using a matrox G400DH the CPU usage is about 80% with or without freevo running. The only thing that I can think of is that freevo is using more memory and you have just gone over the top of the physical memory. You can check this with Dag Wieers' dstat or vmstat program. What you can do is a testing install, using the howto in the wiki and then you can have different versions installed and see if there is any real difference. http://doc.freevo.org/SourceSVNInstallation Duncan Memory is a very good suggestion, I have reverted back to 1.7.1 and this seems more stable and my wife was able to use the media centre to watch several programs today without the media centre crashing. I have noticed that xine playback now uses less CPU than before and playback is more reliable and responsive. The machine does have very little memory, only 128meg, I might have to see if I can find some budget for more ram (I need low profile ram to fit in my case). And see if more memory helps. For now I have a much happier 1.7.1 install. I forward ported some of the changes, such as the tv_guide cElementTree for python 2.5 fix so it is still nicer than before :) Cheers. Steve. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Freevo-users mailing list Freevo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freevo-users
Re: [Freevo-users] more 1.7.5 issues, xine doesn't appear to be doing xvmc any more
Richard van Paasen wrote: Is xine eating up the cpu (check with 'top')? If you have a (VIA) unichrome video chipset, check the ~/.xine/config file of the user that runs freevo. There is an entry for saving cpu cycles: video.device.unichrome_cpu_save = 1 This takes down the cpu load from 40% to 10% on my box with xxmc output. Richard. Xine was eating the CPU, but the odd thing is that I ran my standalone test command as the same user I run freevo with (root, yes I know but it is fire-walled off from the world). I have no idea what is causing the problem, but I'm giving up and reverting to 1.7.2 which I was running before with no problems, I will do that tomorrow evening. I have literally changed nothing else between installs, only freevo has changed, but my media centre is now a mess, crashing on playback of video, not recording correctly etc. I will report back if reverting to 1.7.2 helps, or if this is just a co-incidence and something else happens to have failed / started failing at the same time :) If reverting doesn't work at least I will know for sure that something other than freevo is broken. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Freevo-users mailing list Freevo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freevo-users
Re: [Freevo-users] more 1.7.5 issues, xine doesn't appear to be doing xvmc any more
Stephen Rowles wrote: Has there been any changes to the way freevo uses xine between 1.7.1 and 1.7.5? It appears to be issuing the correct command: /usr/bin/xine --auto-play=fq --hide-gui --borderless --geometry 720x576+0+0 --no-splash --stdctl -V xxmc -A alsa --no-lirc file:///data/TV/01-23_21_00_Torchwood_-_Sleeper.ts But my CPU usage has rocketed, seeking is now very slow as there is a huge amount of CPU being used just to play back. And stopping the video takes ages, again as all the CPU is going on playing video. Just to confirm, I have played the video back on the command line using the above command, and CPU sits at a healthy 15% and video playback quality is fine, so there is definitely something odd about how freevo is launching xine that is causing the problems. (above command was from a ps listing while the video was playing, then just copied and pasted to test) Cheers. Steve. Further thoughts, I've just diff'd xine.py from SVN release 1.7.1 and 1.7.5, it appears that there is now extra logic tracking the standard in / out from xine. I wonder if this is slowing it down at all? Would it be possible to use the old 1.7.1 version of xine.py with my 1.7.5 install? or will this cause problems? Cheers. Steve. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Freevo-users mailing list Freevo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freevo-users
Re: [Freevo-users] more 1.7.5 issues, xine doesn't appear to be doing xvmc any more
Stephen Rowles wrote: Stephen Rowles wrote: Has there been any changes to the way freevo uses xine between 1.7.1 and 1.7.5? It appears to be issuing the correct command: /usr/bin/xine --auto-play=fq --hide-gui --borderless --geometry 720x576+0+0 --no-splash --stdctl -V xxmc -A alsa --no-lirc file:///data/TV/01-23_21_00_Torchwood_-_Sleeper.ts But my CPU usage has rocketed, seeking is now very slow as there is a huge amount of CPU being used just to play back. And stopping the video takes ages, again as all the CPU is going on playing video. Just to confirm, I have played the video back on the command line using the above command, and CPU sits at a healthy 15% and video playback quality is fine, so there is definitely something odd about how freevo is launching xine that is causing the problems. (above command was from a ps listing while the video was playing, then just copied and pasted to test) Cheers. Steve. Further thoughts, I've just diff'd xine.py from SVN release 1.7.1 and 1.7.5, it appears that there is now extra logic tracking the standard in / out from xine. I wonder if this is slowing it down at all? Would it be possible to use the old 1.7.1 version of xine.py with my 1.7.5 install? or will this cause problems? Would you try changing the line: self.app = XineApp(command, self) to: self.app = childapp.ChildApp2(command) This will stop freevo parsing the output of the xine command. I don't think it will make any difference but will stop the call backs from stdout and stderr. Duncan - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Freevo-users mailing list Freevo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freevo-users
Re: [Freevo-users] more 1.7.5 issues, xine doesn't appear to be doing xvmc any more
Duncan Webb wrote: Would you try changing the line: self.app = XineApp(command, self) to: self.app = childapp.ChildApp2(command) This will stop freevo parsing the output of the xine command. I don't think it will make any difference but will stop the call backs from stdout and stderr. That has improved things slightly, taken a few % off the CPU usage, but still in the high 40's - 60's as opposed to the 15% it takes to play back when run from the command line :( Any other ideas? - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Freevo-users mailing list Freevo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freevo-users
Re: [Freevo-users] more 1.7.5 issues, xine doesn't appear to be doing xvmc any more
- Oorspronkelijk bericht - From: Stephen Rowles [EMAIL PROTECTED] To: [EMAIL PROTECTED], freevo-users@lists.sourceforge.net Date: 28-Jan-2008 19:53 Subject: Re: [Freevo-users] more 1.7.5 issues, xine doesn't appear to be doing xvmc any more Duncan Webb wrote: Would you try changing the line: self.app = XineApp(command, self) to: self.app = childapp.ChildApp2(command) This will stop freevo parsing the output of the xine command. I don't think it will make any difference but will stop the call backs from stdout and stderr. That has improved things slightly, taken a few % off the CPU usage, but still in the high 40's - 60's as opposed to the 15% it takes to play back when run from the command line :( Any other ideas? Is xine eating up the cpu (check with 'top')? If you have a (VIA) unichrome video chipset, check the ~/.xine/config file of the user that runs freevo. There is an entry for saving cpu cycles: video.device.unichrome_cpu_save = 1 This takes down the cpu load from 40% to 10% on my box with xxmc output. Richard. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Freevo-users mailing list Freevo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freevo-users
Re: [Freevo-users] more 1.7.5 issues, xine doesn't appear to be doing xvmc any more
Stephen Rowles wrote: Has there been any changes to the way freevo uses xine between 1.7.1 and 1.7.5? It appears to be issuing the correct command: /usr/bin/xine --auto-play=fq --hide-gui --borderless --geometry 720x576+0+0 --no-splash --stdctl -V xxmc -A alsa --no-lirc file:///data/TV/01-23_21_00_Torchwood_-_Sleeper.ts But my CPU usage has rocketed, seeking is now very slow as there is a huge amount of CPU being used just to play back. And stopping the video takes ages, again as all the CPU is going on playing video. Just to confirm, I have played the video back on the command line using the above command, and CPU sits at a healthy 15% and video playback quality is fine, so there is definitely something odd about how freevo is launching xine that is causing the problems. (above command was from a ps listing while the video was playing, then just copied and pasted to test) Cheers. Steve. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Freevo-users mailing list Freevo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freevo-users
