It will still take a while, and it will be announced herebroomdodger wrote:When will that be available? Will you announce it here?zigbert wrote:broomdodger
Thank you for the report.
I will check it out.... It will probably take some time since the next version seems to be 2.2 - with new goodies
Hmm, not good. I need to know the actual process that is not handled correct. Please execute the following command in a terminal and post the result herebroomdodger wrote:wary 5.2
pmusic 2.1.8
Watching 'top' memory size (vsz and %mem) gtkdialog4 used by pmusic, the memory usage keeps increasing and can get quite high, 60% !
Is this a memory leak in gtkdialog4 or something pmusic is doing?
from top:
gtkdialog4 -f /root/.pmusic/tmp/xml_Pmusic -G +0+0
Code: Select all
ps | grep pmusic
211224 ps | grep pmusiczigbert wrote:Hmm, not good. I need to know the actual process that is not handled correct. Please execute the following command in a terminal and post the result herebroomdodger wrote:wary 5.2
pmusic 2.1.8
Watching 'top' memory size (vsz and %mem) gtkdialog4 used by pmusic, the memory usage keeps increasing and can get quite high, 60% !
Is this a memory leak in gtkdialog4 or something pmusic is doing?
from top:
gtkdialog4 -f /root/.pmusic/tmp/xml_Pmusic -G +0+0Code: Select all
ps | grep pmusic
Sigmundzigbert wrote:broomdodger
It looks like it works ok, but you seem to have an older (low-powered) system. I checked my crappy laptop from 2007, and gtkdialog4 -f /root/.pmusic/tmp/xml_Pmusic -G +0+0 shows 2% while yours said 9%.
There are a couple of things worth checking here:broomdodger wrote:These two from top about 20 seconds apart:
PID PPID USER STAT VSZ %MEM CPU %CPU COMMAND
6705 6607 root S 47156 9% 0 1% gtkdialog4 -f /root/.pmusic/tmp/xml_Pmusic -G +0+0
about 20 seconds later
6705 6607 root S 47620 9% 0 1% gtkdialog4 -f /root/.pmusic/tmp/xml_Pmusic -G +0+0
I am not the one to tell the reason why gtkdialog uses more resources than a compiled code, but it obviously does. But I find it strange that Pmusic should use 60% of 512Mb RAM. - That is a lot...- maybe the "XML" (sic) file contains a lot of info (complicated UI and data) and ends up using a lot of memory
- maybe gtkdialog uses a lot of memory with some things (or has a memory leak).
Well, that could make perfectly sense. The func_progressbar is not a loop running in the background. It is a function called from the gui each 0.2 sec, and depending on its output, it might not be finished before next call. Most of these calls quits immediately, but some will occupy the system with larger requests. When a new track is started, func_progressbar will update the values of NOW_PLAYING. This require 'ffmpeg -i', and for streams, that could in particular take some time.2) Note how your "ps" output showed multiple instances of func_progressbar. It doesn't make sense that there are multiple progressbar instances at the same time...
Code: Select all
# pmusic
/usr/bin/seamonkey
) button. Pmusic has always been made for large music collection, but version 2.2 is made for huge collections. Since jamendo.com gives access to 250000+ tracks there was a need of an improved search engine. The new button gives quick access to search filters.
Huh... seems Pmusic cant index via a symlink, path has to be absolute. Who would have known.......DaveS wrote:Dear God I am struggling with Pmusic. I seem unable to index my music. Each time I return to the browser window after indexing it reports 'index missing' (Racy) Whatever am I doing wrong? Surely it should not be this difficult?
