pMusic 6.0.0

[zigbert]

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

[Michalis]

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.

[zigbert]

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.

The progressbar runs as an unique process.

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.

I have tried get this, but either I'm not skilled enough, or the limitation in the gtkdialog library are strict.

Sigmund

[peppyy]

Hi again Zidbert.
Is there a chance that the progress bar could be replaced with a text counter which uses percent? I don't understand how the whole dialog works but I was sure I saw a gtk gui that had a percentage counter.

Of course I could be completely wrong

[zigbert]

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

[HairyWill]

Code: Select all

while [ a != b ]; do if [ "`cat '"$WORKDIR"'/pmusic-ffmpeg_output`" ]; then nice -18 '"$APPDIR"'/func_progressbar; usleep 100000; fi; done

Zigbert as I copied this approach in psip I have a couple of suggestions.
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.

[zigbert]

HairyWill

1. while [ "$(ps | grep [p]music)" ] is a great improvement. I will add it at once.

2. usleep 100000 gives a smooth 'clock' in the bar. But it could be an option to update the progressbar every 2 seconds instead of hiding the progressbar.

Thanks for great feedback.
Sigmund

[zigbert]

It seems to me that the actual cpu-eater is the while-loop started inside gtkdialog. I tried to set nice -18 in front of 'while', but no joy.

Sigmund

[Michalis]

I think that I managed to make something which with your knowledge maybe you can make it even better

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

To

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

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:

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

then I changed pmusic to:

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

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

[zigbert]

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

[Michalis]

So it seems that I didn't help

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.)

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.

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.

[zigbert]

Michalis
Could you measure what the difference is on your system, if func_progressbar is empty compared to the original.

Thanks
Sigmund

[zigbert]

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

[zigbert]

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

[Dingo]

do you think to add a language support?

[Michalis]

Haven't used pmusic 0.3.1 yet, I'll try it later, but my cpu usage is similar to yours:

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

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.

Maybe now I have drag you to the wrong path of cpu measurements

[zigbert]

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

[zigbert]

Dingo
Translation will of course be supported. I just want to wait until I feel that Pmusic has arrived its lasting interface. I think we're close to it....

Sigmund

[trapster]

zigbert....please.

This version is nearly 300 bytes bigger then the last.
We are getting a little bloated here.

[Michalis]

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

Thank you and sorry for the delay but I didn't had much time, I had to do that thing called work

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

where is "gtk-undo"?

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")

It's referring to line 37 of func_progressbar:

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

Then when it automatically changed to the next song in the playlist I got this error:

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

again for line 37 of func_progressbar, wrong time calculation? wrong way to calculate? I don't know.

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)")

referring to line 43:

Code: Select all

TIME_SEC=$[$SEC_PLAYED-($TIME_MIN*60)]

Last error was when exited using "file" "quit":

Code: Select all

/usr/local/pmusic/pmusic: line 618: kill: (22010) - No such process

Ok now live errors, I'm playing another song and I get this error:

Code: Select all

/usr/local/pmusic/func_progressbar: line 27: (01*60)+08: value too great for base (error token is "08")

It's being printed every second or 2.


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")

Pause also seems not to work:

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.