Beta Pnd_Run.sh


sebt3

homebrew player (P. & C.)
Joined
Sep 9, 2008
Messages
4,885
Age
43
Location
France
Website
sebt3.openpandora.org
Hi there,

Last time with HF5, my change to pnd_run.sh introduced many regressions. For nexts OS releases, I want to come clean. So I decided to ask your help and built this installer.

Change since HF5 in pnd_run.sh :
- Rewrite the loging. Make it way nicer
- rewrite the argument parsing. Fixing the many differents space issues.
- support more than 9 loops (thanks vimacs)
- many code clean-ups
- support for user configured pre/post scripts (have to be in the appdata, will not be taken from the pnd. file have to be named PND_pre_script.sh and PND_post_script.sh)
- APPDATADIR is exported to the application, so launcher script can take adventage of it (I have already posted a backward compatible solution on the boards)
- PND (the name of the pnd file) is also exported to the application
- Wait up to 2 minuts that the app have effectivly left the union filesystem before attempting to unmount.
- if an error occur while mounting, retry once before giving up
- implemented a garbage collector for loopback.

[ installer ]
the install script will ask you for your password.
You old pnd_run.sh will be backuped.

tests and feedbacks encouraged ;)
 
I;ve been testing the updated Pnd_Run.sh. It's working great. However, I've noticed that there is now 10 second or more delay for MeniMenu to reload after I exit a application. Is the delay intended?
 
Jonney said:
I;ve been testing the updated Pnd_Run.sh. It's working great. However, I've noticed that there is now 10 second or more delay for MeniMenu to reload after I exit a application. Is the delay intended?
Not realy.
Is this for every apps ?
May I see a pndrun_*.out file of one app when this happen ?
 
Last edited by a moderator:
Oh, one thing I've been noticing is that when I close an application, its icon on the desktop "blinks".
 
What else could it be though? I think its blinking because of the things that occur when unmounting the PND of that application.
 
Last edited by a moderator:
i noticed a much highest cpu usage with this pnd_run. for instance, if i run panplayer from a script started by midori 0.3, both pnd_run script rush up at 50% cpu each for 3-4 secs, then mplayer get about 30% cpu and pnd_run use 70% for about 15 more secs, then it stabilise down.

I reduced the output from those scripts that helped a lot, but even with about 0 lines outputed to pndrun_ i still get an uncanny cpu usage for a launching script. at the very least way more than with the older (less stable) script.
 
indeed, this version of pnd_run.sh does use a bit more cpu for each line written in the log (mostly for a awk, 2 sed, a date and a printf)
And it might have an impact on your application performance if it log a lot (aka several time per second).

When starting an app like abiword, pnd_run.sh dont use more then 1-2% of my CPU and not for long.
If pnd_run.sh is using CPU when your app is not logging, then there is a problem somewhere I cant get right now : both pnd_run.sh process are in wait (the 1st for the app to return, the second for the app to log something)
 
alright, was hoping you would have a fair idea on the source, ill keep you posted on what i discover (ill spend a bit of time later today tracking that lag down ! )
 
sebt3 said:
Hi there,

Last time with HF5, my change to pnd_run.sh introduced many regressions. For nexts OS releases, I want to come clean. So I decided to ask your help and built this installer.

Change since HF5 in pnd_run.sh :
- Rewrite the loging. Make it way nicer
- rewrite the argument parsing. Fixing the many differents space issues.
- support more than 9 loops (thanks vimacs)
- many code clean-ups
- support for user configured pre/post scripts (have to be in the appdata, will not be taken from the pnd. file have to be named PND_pre_script.sh and PND_post_script.sh)
- APPDATADIR is exported to the application, so launcher script can take adventage of it (I have already posted a backward compatible solution on the boards)
- PND (the name of the pnd file) is also exported to the application
- Wait up to 2 minuts that the app have effectivly left the union filesystem before attempting to unmount.
- if an error occur while mounting, retry once before giving up
- implemented a garbage collector for loopback.

[ installer ]
the install script will ask you for your password.
You old pnd_run.sh will be backuped.

tests and feedbacks encouraged ;)

Sebt3, Many thanks for this and the rest of your hard work.

however, I'm having problems with the new pnd_run.sh pnd...
when I first ran it, nothing happened - it didnt ask me for my password or similar, but it does seem to have done something... namely that every time i try to run an app as usual an error comes up from swfdec flash player saying that this isnt a flash file - for some reason, the new script seems to have changed the PND file association.

can you tell me where the backup pnd_run.sh is stored? or alternatively, does anyone have a working one they can send me?
 
Last edited by a moderator:
neurocyde said:
can you tell me where the backup pnd_run.sh is stored? or alternatively, does anyone have a working one they can send me?

sudo mv /usr/pandora/scripts/pnd_run.sh.2011* /usr/pandora/scripts/pnd_run.sh

should restaure your previous version ;)

EDIT: but I cant see how that's related.
 
Last edited by a moderator:
well, i found the issue why it was using so much ressources. It overridden my redirection when starting the pnd, panplayer (mplayer more specificatly), spit out a tremendous ammount of output (a few hundreds thousands lines easy if you have cache enabled when loading from a url since it keep updating the cachefill) adding exec &> panplayer.log in the mplayer.sh script is a decent workaround, but if possible, you really should figure a way to reduce the impact of std::eek:ut from pnd lol. maybe just automaticly disable it if there is too many.
 
sebt3 said:
neurocyde said:
can you tell me where the backup pnd_run.sh is stored? or alternatively, does anyone have a working one they can send me?

sudo mv /usr/pandora/scripts/pnd_run.sh.2011* /usr/pandora/scripts/pnd_run.sh

should restaure your previous version ;)

EDIT: but I cant see how that's related.

Thanks for that, but it didnt work - probably because you're right and it's an unrelated problem.
nevermind, thanks for your help anyway!
 
Last edited by a moderator:
Jey123456 said:
well, i found the issue why it was using so much ressources. It overridden my redirection when starting the pnd, panplayer (mplayer more specificatly), spit out a tremendous ammount of output (a few hundreds thousands lines easy if you have cache enabled when loading from a url since it keep updating the cachefill) adding exec &> panplayer.log in the mplayer.sh script is a decent workaround, but if possible, you really should figure a way to reduce the impact of std::eek:ut from pnd lol. maybe just automaticly disable it if there is too many.
knowing that /tmp is a ramfs, I would prefer that the file we put there are keept small. Appdata directory seems a good target directory for large debug files.

BTW:
Uploaded a new version that :
- is cleaned a bit more
- have a bug fixed (wont change much from your point of view)
- give more info when failed to (u)mount.
 
Last edited by a moderator:
im not too sure how exactly it happen,but it seem to bug quite alot when running pnd_run.sh from another pnd (i ended up with symlink to midori in my panplayer appdata, panplayer cant mount anymore, because its trying to mix up with midori loop (even after reboot).

Im having a read through the pnd_run.sh script see if i can see what could be the cause of that, but chance are you might have some suggestions on which part precisely to investigate xD.
 
Back
Top