pMusic 6.0.0
Michalis
I noticed today that my pmusic had 3 instances of func_progressbar running at the same time. I have done an approach to try to fix it, but it is a bit too early to ship a new release. Can you try to explain why progressbar is hungry for your resources.
- Are your machinery old?
- Does 'top' show that progressbar stealing too much cpu?
- Are there several func_progressbar shown in pprocess?
- Are you using the latest Pmusic - version 0.3.0?
- Is it Puppy 4.1 or ... ?
I disable progressbar on my music-station to avoid fan is running constantly (a PIII 600 laptop anno 1999).
Edit: Version 0.3.0 reduces the cpu-priority for func_progressbar.
Sigmund
I noticed today that my pmusic had 3 instances of func_progressbar running at the same time. I have done an approach to try to fix it, but it is a bit too early to ship a new release. Can you try to explain why progressbar is hungry for your resources.
- Are your machinery old?
- Does 'top' show that progressbar stealing too much cpu?
- Are there several func_progressbar shown in pprocess?
- Are you using the latest Pmusic - version 0.3.0?
- Is it Puppy 4.1 or ... ?
I disable progressbar on my music-station to avoid fan is running constantly (a PIII 600 laptop anno 1999).
Edit: Version 0.3.0 reduces the cpu-priority for func_progressbar.
Sigmund
I'm running pmusic 0.3.0 in puppy 3.1
The machine I usually use is old, also I use many programs simultaneously, at least 4-5 (usually much more). When having the progress bar pmusic cpu usage is doubling and generally I like to use programs and functions as less resource hungry as possible, so I have always progress bar disable. A strange thing is that the system isn't showing any difference at pmusic's cpu usage, but I can see that throughout the total cpu usage every time.
Anyway, what I would like isn't a progress bar using less resources (actually I don't mind whether I see a progress bar or not) rather than just to see the title of the song which is playing (statically) in the position of the progress bar.
The machine I usually use is old, also I use many programs simultaneously, at least 4-5 (usually much more). When having the progress bar pmusic cpu usage is doubling and generally I like to use programs and functions as less resource hungry as possible, so I have always progress bar disable. A strange thing is that the system isn't showing any difference at pmusic's cpu usage, but I can see that throughout the total cpu usage every time.
Anyway, what I would like isn't a progress bar using less resources (actually I don't mind whether I see a progress bar or not) rather than just to see the title of the song which is playing (statically) in the position of the progress bar.
The progressbar runs as an unique process.A strange thing is that the system isn't showing any difference at pmusic's cpu usage, but I can see that throughout the total cpu usage every time.
I have tried get this, but either I'm not skilled enough, or the limitation in the gtkdialog library are strict.Anyway, what I would like isn't a progress bar using less resources (actually I don't mind whether I see a progress bar or not) rather than just to see the title of the song which is playing (statically) in the position of the progress bar.
Sigmund
If you could active send a percent status to that textbox, it would be easy. But since the Pmusic gui has nothing to do with the actual playback, it only reads outputs from the player. As far as I know, the only way gtkdialog supports an idle gui (no user activity) waiting for system input is via the pregressbar widget.
I don't think a textbox would use lesser cpu. The problem is not the progressbar widget itself, but that pmusic constantly runs a loop to check for new outputs from ffpmeg. If the output of ffmpeg could be used directly in Pmusic progressbar, this wouldn't be necessary.
Sigmund
I don't think a textbox would use lesser cpu. The problem is not the progressbar widget itself, but that pmusic constantly runs a loop to check for new outputs from ffpmeg. If the output of ffmpeg could be used directly in Pmusic progressbar, this wouldn't be necessary.
Sigmund
Code: Select all
while [ a != b ]; do if [ "`cat '"$WORKDIR"'/pmusic-ffmpeg_output`" ]; then nice -18 '"$APPDIR"'/func_progressbar; usleep 100000; fi; done
Do you really need to poll 10 tens a second surely twice a second would be adequate, even less if all you display is the title?
I changed the while condition to something like
while [ "$(ps | grep [p]music)" ]
this should help to ensure that the loop terminates properly when all the other pmusic processes are closed.
Will
contribute: [url=http://www.puppylinux.org]community website[/url], [url=http://tinyurl.com/6c3nm6]screenshots[/url], [url=http://tinyurl.com/6j2gbz]puplets[/url], [url=http://tinyurl.com/57gykn]wiki[/url], [url=http://tinyurl.com/5dgr83]rss[/url]
contribute: [url=http://www.puppylinux.org]community website[/url], [url=http://tinyurl.com/6c3nm6]screenshots[/url], [url=http://tinyurl.com/6j2gbz]puplets[/url], [url=http://tinyurl.com/57gykn]wiki[/url], [url=http://tinyurl.com/5dgr83]rss[/url]
I think that I managed to make something which with your knowledge maybe you can make it even better
First of all I changed:
To
according to HairyWills' suggestion
Then I copied and renamed func_progressbar file to a new one called func_noprogressbar in the same directory.
Afterwards I did some cleaning in the file and so this is what is now left:
then I changed pmusic to:
So what have I achieved from that?
I can see only the title without the red progress bar and the time.
What haven't I achieved from that?
No significant reduction in the cpu usage. That's maybe because the cleaning is very primitive and because of lack of knowledge I have produced many mistakes which I can see when running pmusic from console and in kp.
Maybe If you can fix those problems then you could achieved what we are asking? Not sure I just hope I gave you some help, or I at least I want to believe so
First of all I changed:
Code: Select all
while [ a != b ]; do if [ "`cat '"$WORKDIR"'/pmusic-ffmpeg_output`" ]; then nice -18 '"$APPDIR"'/func_progressbar; usleep 100000; fi; done
Code: Select all
while [ "$(ps | grep [p]music)" ]; do if [ "`cat '"$WORKDIR"'/pmusic-ffmpeg_output`" ]; then nice -18 '"$APPDIR"'/func_progressbar; usleep 100000; fi; done
Then I copied and renamed func_progressbar file to a new one called func_noprogressbar in the same directory.
Afterwards I did some cleaning in the file and so this is what is now left:
Code: Select all
#!/bin/bash
WORKDIR=$HOME/.pmusic/tmp
#show tool-info instead of song
TMP=`cat $WORKDIR/pmusic-PERCENT_BAR`
case "`cat $WORKDIR/pmusic-progressbar_status`" in
undo) echo $TMP; echo 'Go BACK in playlist history'; exit ;;
redo) echo $TMP; echo 'Go FORWARD in playlist history'; exit ;;
esac
#make sure to give some output
if [ "`cat $WORKDIR/pmusic-ffmpeg_output`" = "pmusic_stop" ] || [ ! "`cat $WORKDIR/pmusic-ffmpeg_output`" ]; then
echo " " > $WORKDIR/pmusic-OLD_TIME
echo 0
echo "»»» Pmusic «««"
else
#read ffmpeg output
FILE=`cat $WORKDIR/pmusic-ffmpeg_output | grep "from '" | cut -d "'" -f 2- | sed -e "s/'://g"`
#show metainfo of file if exist. (in indexlist)
FILE2="`cat $HOME/.pmusic/index_all | grep -w "$FILE" | cut -d '|' -f 2`"
if [ "$FILE2" ]; then FILE="$FILE2"; fi
#---
NOW_PLAYING=`basename "$FILE" 2> /dev/null | sed -e 's/\.[^\.]*$//'`
FFMPEG_OUTPUT=`tail -c 120 $WORKDIR/pmusic-ffmpeg_output` #check for invalid output
if [ "$FILE" ] && [ ! "`echo "$FFMPEG_OUTPUT" | grep 'invalid'`" ]; then # expr + 1 checks if it's a number
#find percent for progress bar
#calculate time of seconds played
if [ `echo $NOW_PLAYING | cut -b 1` -lt 9 2> /dev/null ]; then #first char is a number. This bugs progress bar.
echo "| $NOW_PLAYING |"
else
echo "$NOW_PLAYING "
fi
#keep values incase of invalid output next loop
else #no time is detected
cat $WORKDIR/pmusic-PERCENT_BAR
if [ "$FILE" ]; then
echo "$NOW_PLAYING$TMP"
else
echo "»»» Pmusic «««"
fi
fi
fi
exit 0
Code: Select all
if [ $SHOW_PROGRESS_BAR = true ]; then
GUI_PROGRESS_BAR="
<progressbar>
<label>\" \"</label>
<input>"'while [ "$(ps | grep [p]music)" ]; do if [ "`cat '"$WORKDIR"'/pmusic-ffmpeg_output`" ]; then nice -18 '"$APPDIR"'/func_progressbar; usleep 100000; fi; done'"</input>
</progressbar>"
else
GUI_PROGRESS_BAR="
<progressbar>
<label>\" \"</label>
<input>"'while [ "$(ps | grep [p]music)" ]; do if [ "`cat '"$WORKDIR"'/pmusic-ffmpeg_output`" ]; then nice -18 '"$APPDIR"'/func_noprogressbar; usleep 1000000; fi; done'"</input>
</progressbar>"
fi
I can see only the title without the red progress bar and the time.
What haven't I achieved from that?
No significant reduction in the cpu usage. That's maybe because the cleaning is very primitive and because of lack of knowledge I have produced many mistakes which I can see when running pmusic from console and in kp.
Maybe If you can fix those problems then you could achieved what we are asking? Not sure I just hope I gave you some help, or I at least I want to believe so
Michalis
Thanks a lot for your investigating.
My conclusion (at this moment) is that; it doesn't matter how much we strip func_progressbar. Running this function once a second or 10 times a second shouldn't steal much cpu even on older systems. The problem seems to be the 'while' loop itself. It's running constantly, and sleep/func_progressbar doesn't seem to affect the cpu hunger. (Please correct me if I'm wrong.) Why it acts like this is a mystery for me. I'm not a skilled person, so it could be just me. Like I told in my previous post, I have also tried to set a lower cpu-priority with 'nice' in front of the 'while' loop. But either is it not allowed, or I didn't fixed the syntax?
Sigmund
Thanks a lot for your investigating.
My conclusion (at this moment) is that; it doesn't matter how much we strip func_progressbar. Running this function once a second or 10 times a second shouldn't steal much cpu even on older systems. The problem seems to be the 'while' loop itself. It's running constantly, and sleep/func_progressbar doesn't seem to affect the cpu hunger. (Please correct me if I'm wrong.) Why it acts like this is a mystery for me. I'm not a skilled person, so it could be just me. Like I told in my previous post, I have also tried to set a lower cpu-priority with 'nice' in front of the 'while' loop. But either is it not allowed, or I didn't fixed the syntax?
Sigmund
So it seems that I didn't help
Because of that what I tried to do is to reduce what the fuction was doing when running. So I deleted everything that had to do with time calculation and also made the loop run every 2 seconds, this makes it to just read the title output from ffmpeg and thus to use less cpu power.
Of course at the end as I've already told you I haven't any programming knowledge and I'm not sure if I'm correct or totally wrong also. But I think it would be better to keep your opinion and try to find solution over it.
I'm not so sure about it, at least according to what I've seen in my system. Changing how often the "while fuction would be running, by changing the usleep parameter, I noticed that when the fuction was running I had a significant increase to the cpu usage. It was noticed in conky with sort spikes in the cpu usage graph.zigbert wrote:My conclusion (at this moment) is that; it doesn't matter how much we strip func_progressbar. Running this function once a second or 10 times a second shouldn't steal much cpu even on older systems. The problem seems to be the 'while' loop itself. It's running constantly, and sleep/func_progressbar doesn't seem to affect the cpu hunger. (Please correct me if I'm wrong.)
Because of that what I tried to do is to reduce what the fuction was doing when running. So I deleted everything that had to do with time calculation and also made the loop run every 2 seconds, this makes it to just read the title output from ffmpeg and thus to use less cpu power.
Of course at the end as I've already told you I haven't any programming knowledge and I'm not sure if I'm correct or totally wrong also. But I think it would be better to keep your opinion and try to find solution over it.
I have used 'top' to measure cpu usage, and couldn't see much difference. Now I have installed conky which shows dramatical differences. Which one is to trust?
Conky resut when running only Pmusic on my system:
66% - Normal
18% - No func_progressbar
23% - While-loop with sleep 1
9% - No progresbar
If conky is to trust, I have something to investigate
Sigmund
Conky resut when running only Pmusic on my system:
66% - Normal
18% - No func_progressbar
23% - While-loop with sleep 1
9% - No progresbar
If conky is to trust, I have something to investigate
Sigmund
Version 0.3.1 is uploaded
See main post
cpu-usage on my system (conky):
3% - Idle
9% - Pmusic without progress bar
18% - Pmusic 0.3.1
37% - Gxine
66% - Pmusic 0.3.0
There is still a potential for even more cpu reduction. Let's take a look at the code in some time ... when we've learned more...
Sigmund
See main post
cpu-usage on my system (conky):
3% - Idle
9% - Pmusic without progress bar
18% - Pmusic 0.3.1
37% - Gxine
66% - Pmusic 0.3.0
There is still a potential for even more cpu reduction. Let's take a look at the code in some time ... when we've learned more...
Sigmund
- Dingo
- Posts: 1437
- Joined: Tue 11 Dec 2007, 17:48
- Location: somewhere at the end of rainbow...
- Contact:
do you think to add a language support?
replace .co.cc with .info to get access to stuff I posted in forum
dropbox 2GB free
OpenOffice for Puppy Linux
dropbox 2GB free
OpenOffice for Puppy Linux
Haven't used pmusic 0.3.1 yet, I'll try it later, but my cpu usage is similar to yours:
Maybe now I have drag you to the wrong path of cpu measurements
Don't know if conky or top is more trustful but all my comments are according to conky. Never thought that it can be wrong or give different results than top.zigbert wrote:I have used 'top' to measure cpu usage, and couldn't see much difference. Now I have installed conky which shows dramatical differences. Which one is to trust?
Conky resut when running only Pmusic on my system:
66% - Normal
18% - No func_progressbar
23% - While-loop with sleep 1
9% - No progresbar
If conky is to trust, I have something to investigate
Maybe now I have drag you to the wrong path of cpu measurements
Thank you and sorry for the delay but I didn't had much time, I had to do that thing called workzigbert wrote:Michalis
I'm excited to hear from you after played with 0.3.1. Are we on the right track or have you fooled both of us
Sigmund
Ok I was going to post very few errors in the beginning but I couldn't leave you without some decent work reading and trying to figure out the solution
Anyway I tested it and it's better in cpu usage according to conky:
without progress bar: 16% average (13 to 19%)
with progress bar 43% average (35 to 47%)
It's lower but not optimal yet.
Of course I started it from rxvt in order to see if there are any errors and I noticed few.
Every time I start it, it displays:
Code: Select all
(gtkdialog3:7454): Gtk-WARNING **: Could not find the icon 'gtk-undo'. The 'hicolor' theme was not found either, perhaps you need to install it.
You can get a copy from:
http://icon-theme.freedesktop.org/releases
Ok nothing serious till now, but then when I clicked on a song to play I got this:
Code: Select all
/usr/local/pmusic/func_progressbar: line 37: b/s
Stream
Press
1+1: division by 0 (error token is "Stream
Press
1+1")
Code: Select all
if [ "$NOW_PLAYING" ] && [ "$LENGTH" ] && [ "$[$SEC_PLAYED+1]" ] && [ ! "`echo "$SEC_PLAYED" | grep '10000000000'`" ] && [ ! "`echo "$FFMPEG_OUTPUT" | grep 'invalid'`" ]; then # +1 checks if it's a number
Code: Select all
/usr/local/pmusic/func_progressbar: line 37: 158
video:0kB+1: syntax error in expression (error token is "video:0kB+1")
/usr/local/pmusic/func_progressbar: line 37: 158
video:0kB+1: syntax error in expression (error token is "video:0kB+1")
expr: non-numeric argument
Another error I got was when pressing the stop button:
Code: Select all
/usr/local/pmusic/func_progressbar: line 43: pmusic_stop-(*60): syntax error: operand expected (error token is "*60)")
Code: Select all
TIME_SEC=$[$SEC_PLAYED-($TIME_MIN*60)]
Code: Select all
/usr/local/pmusic/pmusic: line 618: kill: (22010) - No such process
Code: Select all
/usr/local/pmusic/func_progressbar: line 27: (01*60)+08: value too great for base (error token is "08")
Changing to the next song got me this error:
Code: Select all
/usr/local/pmusic/func_progressbar: line 37: 106
video:0kB+1: syntax error in expression (error token is "video:0kB+1")
expr: syntax error
/usr/local/pmusic/func_progressbar: line 43: -(*60): syntax error: operand expected (error token is "*60)")
Another error:
Code: Select all
/usr/local/pmusic/func_progressbar: line 37: 125
video:0kB+1: syntax error in expression (error token is "video:0kB+1")
/usr/local/pmusic/func_progressbar: line 37: 125
video:0kB+1: syntax error in expression (error token is "video:0kB+1")
/usr/local/pmusic/func_progressbar: line 37: am
Stream
when using the fast forward I got this error:
Code: Select all
/usr/local/pmusic/func_progressbar: line 37: tream
Press
mdb:164,
mdb:164,+1: syntax error in expression (error token is "Press
mdb:164,
mdb:164,+1")
Something else I'm facing is that when using fast forward (30 secs next) it takes much time around 2-3 secs usually but even 8 secs the first time using it after pmusic lanch. After ff the time counter in progress bar always starts from 1 sec and counting althougth the song is playing for 1 or 2 minutes.
Another error I got now by pressing fast forward near the end of the song and so it had changed song is:
Code: Select all
/usr/local/pmusic/func_progressbar: line 37: 145
video:0kB+1: syntax error in expression (error token is "video:0kB+1")
/usr/local/pmusic/func_progressbar: line 37: skiping
1+1: syntax error in expression (error token is "1+1")
/usr/local/pmusic/func_progressbar: line 37: 10000000000
video:0kB+1: syntax error in expression (error token is "video:0kB+1")
/usr/local/pmusic/func_progressbar: line 37: #0
Press
mdb:100,
1+1: syntax error: operand expected (error token is "#0
Press
mdb:100,
1+1")
Code: Select all
/usr/local/pmusic/func: line 888: kill: (14332) - No such process
/usr/local/pmusic/func: line 888: kill: (14492) - No such process
/usr/local/pmusic/func: line 888: kill: (14784) - No such process
Anyway it seems that many errors have to do with line 37 of func_progressbar, so that must be the starting point, correct? Don't seem to be any important errors, rather than just code cleaning and debugging.
I'm also attaching all rxvt's output in order you want it.
Generally feeling: I'm satisfied using pmusic but needs some work in order to become perfect.
- Attachments
-
- pmusic errors.tar.gz
- (946 Bytes) Downloaded 566 times