Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Fri 19 Sep 2014, 03:53
All times are UTC - 4
 Forum index » Advanced Topics » Additional Software (PETs, n' stuff) » Multimedia
Precord mp3,wav,ogg,aac,flac recorder/player.
Post new topic   Reply to topic View previous topic :: View next topic
Page 7 of 12 [177 Posts]   Goto page: Previous 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12 Next
Author Message
mcewanw

Joined: 16 Aug 2007
Posts: 2346
Location: New Zealand

PostPosted: Sat 26 Dec 2009, 11:02    Post subject:  

tasmod wrote:

Older problem is that using window close control instead of quit leaves mp3 playing as arecord is backgrounded.


Oh yes, I forgot to add the lines to fix that; simple to remedy though. The fix will be in the next version. In the meantime, you can just type:

Code:

precord quit


at the commandline, or simply start up another instance of Precord and press the stop button or close button...

_________________
Non enim propter gloriam, diuicias aut honores pugnamus set propter libertatem solummodo quam Nemo bonus nisi simul cum vita amittit.
Back to top
View user's profile Send private message Visit poster's website 
mcewanw

Joined: 16 Aug 2007
Posts: 2346
Location: New Zealand

PostPosted: Sat 26 Dec 2009, 11:27    Post subject:  

mcewanw wrote:

Oh yes, I forgot to add the lines to fix that; simple to remedy though.


Actually... no it isn't easy to catch that one... Was easy in my earlier wiakrecord because that was a daemon program and the "wiak" client detected the error and sent a clean-up signal. No such solution here. Maybe need a wee daemon running to keep an eye on the running recording. In the meantime, just use close button and if you forget, just start second Precord instance up and press stop... as suggested above. That's one of the reason's I designed the intercomms (IPC) client called "wiak" (written in C) - gtkdialog being a real pain at times like that.

_________________
Non enim propter gloriam, diuicias aut honores pugnamus set propter libertatem solummodo quam Nemo bonus nisi simul cum vita amittit.
Back to top
View user's profile Send private message Visit poster's website 
mikeb


Joined: 23 Nov 2006
Posts: 8252

PostPosted: Sat 26 Dec 2009, 11:36    Post subject:  

I just have case have the
*)
do the same as the exit button for clean quitting

mike
Back to top
View user's profile Send private message 
mcewanw

Joined: 16 Aug 2007
Posts: 2346
Location: New Zealand

PostPosted: Sat 26 Dec 2009, 23:15    Post subject:  

mikeb wrote:
I just have case have the
*)
do the same as the exit button for clean quitting

mike


Ah... but there is a major difference. The problem here is a gtkdialog one, which occurs for any long running process started from WITHIN gtkdialog; that becomes a child of the running gtkdialog. Unfortunately, gtkdialog, should, but doesn't take its children with it when it dies suddenly by hitting its window X button, so the script which started gtkdialog up waits patiently for any such gtkdialog children to complete before running the final few commands in the driving bash script. Hence, in this scenario, putting 'kills' at the end of the bash script is no solution - in fact, I'd say that the bash script cannot itself directly do anything about the issue ... (it is thus a serious gtkdialog bug since gtkdialog should itself have an inbuilt mechanism to clean up its children on window X pressed).

Your recorder program doesn't start the arecord process from within gtkdialog itself so it is not a child of gtkdialog, just a child of your shell script. The disadvantage with that method is that you have to then restart/redraw the gtkdialog GUI to show your pause button.

That would ruin the Precord interface since gtkdialog doesn't exactly redraw its GUI instantly. To avoid that, I'd have to find some other mechanism to decouple the starting of arecord and so on, such that gtkdialog isn't its ancestor process. One other way out, which I used in wiakrecord, as I said before, is to have the whole main program running as a background daemon, with the GUI only being a client of that (and thus not a parent of arecord). Alternatively, I could also start up some little daemon monitoring program at the same time the arecord or ffmpeg etc process is started, and get that to detect if the gtkdialog suddenly dies (such that the wee daemon can then kill arecord off for me... messy and tricky though).

Maybe, it is best just to live with the "slight" issue, especially since Precord is fortunately able to simply be started up again and still find its children... and can then kill the wee pests. No doubt I'll try and find a solution though (I already tried, but my curiousity/determination forces me to keep trying for a while...:-) Its not worth it to me to waste the current interface as a solution though - if only the author's of gtkdialog would fix the issue at source...

By the way, your wee recorder program suffers from the lesser problem that it leaves lame process running if you close down the app after PAUSE has been pressed (simple to fix though - you need to do a kill -CONT before the final kill -TERM ; I do that in Precord).

_________________
Non enim propter gloriam, diuicias aut honores pugnamus set propter libertatem solummodo quam Nemo bonus nisi simul cum vita amittit.
Back to top
View user's profile Send private message Visit poster's website 
mikeb


Joined: 23 Nov 2006
Posts: 8252

PostPosted: Sun 27 Dec 2009, 11:59    Post subject:  

Quote:
By the way, your wee recorder program suffers from the lesser problem that it leaves lame process running if you close down the app after PAUSE has been pressed (simple to fix though - you need to do a kill -CONT before the final kill -TERM ; I do that in Precord).

wow thanks for picking that one up...I'd left that at its simple conclusion just with the vu added....so basically one cannot kill a stopped process?

I had no brain the last time I posted and you are doing things in a way that I'm just getting familiar with...one for me to bear in mind.Indeed I have not done anything with gtkdialog for a while and youy reinspired me Smile ...now I just need more time Very Happy .
Funny you should mention it but my pburn effort has a separate script that draws /redraws the gui only when there is a change eg a flash stick is plugged in, as detected by the main loop so everything is a child of bash again . The draw back becomes an advantage because when there is a hardware event pmount gets the focus to alert the user...oh the hoops we skip through to please gtkdialog Very Happy

regards

mike
Back to top
View user's profile Send private message 
mcewanw

Joined: 16 Aug 2007
Posts: 2346
Location: New Zealand

PostPosted: Mon 28 Dec 2009, 03:24    Post subject: Eureka?  

<action signal="hide">exit:Exit</action>

Maybe the above will do it, though my initial tests suggest otherwise. It is from Patriot's suggestion re: gtkdialog menubar bug in Gtkdialog Tips (admittedly, Precord doesn't 'have' a menubar, but I was/am hoping Patriot's 'fix' is more universal(?). Whether it is supposed to be more universal wasn't clear to me from what was written in the Gtkdialog Tips thread...):

http://www.murga-linux.com/puppy/viewtopic.php?p=354192&search_id=962159899#354192

First test suggests it doesn't work for the issue in Precord: i.e. audio keeps playing on user presses jwm window [X] abrupt close control.

This "long processes keep running" problem seems to be a very long running gtkdialog issue (been plaguing people for years) and one of the major serious 'bugs/issues', which forces all sorts of workaround (like 'having to' redraw the GUI and start the long running processes outside of gtkdialog itself...).

Apparently forum member disciple has written something that may or may not be usefully related, but, alas I haven't been able to find where he wrote it (just a reference from Zigbert to the matter):

zigbert wrote:
- Bugfix: Close all dialogs (and PIDs) when pressing 'Emergency Stop' button. (thanks to disciple)
from:

http://www.murga-linux.com/puppy/viewtopic.php?p=355674&search_id=962159899#355674

*****However*****, if Patriot's signal="hide" thingy can't be made to do the job (or whatever disciple has written):

I have in fact found another non-gtkdialog method of overcoming the problem, I think... some testing required for certainty (in fact, I might have found two bash-related methods which might sort out the problem once and for all). I'll let the siggies and patties know in the Gtkdialog thread, once I've verified my idea.

What I wrote before is a clue for now(!), but lets hope I don't get run over by a bus, meantime:

mcewanw wrote:
Maybe need a wee daemon running to keep an eye on the running recording


(Though I'm still hoping the simple "signal=hide" thingy will be usable instead).

I suppose I should also look at the gtkdialog source code to see what are 'signals' might work (apart from 'hide') - assuming that would reveal that detail.

_________________
Non enim propter gloriam, diuicias aut honores pugnamus set propter libertatem solummodo quam Nemo bonus nisi simul cum vita amittit.
Back to top
View user's profile Send private message Visit poster's website 
mcewanw

Joined: 16 Aug 2007
Posts: 2346
Location: New Zealand

PostPosted: Mon 28 Dec 2009, 04:26    Post subject: Eureka indeed.  

Eureka indeed... Well done Patriot. The following works (a very useful/significant find by Patriot, I'd say):

<action signal="hide">exit:Exit</action>

and the playing audio file is able to stop on window closed abruptly by pressing [X] in top right hand corner (rather than the normal "close" button).

I just need to alter my code slightly and I should be able to upload the new fixed version soon. No need for the other method I'd come up with of monitoring for the child process closing (though I've no idea what action signal="hide" actually does internally... maybe very similar)

_________________
Non enim propter gloriam, diuicias aut honores pugnamus set propter libertatem solummodo quam Nemo bonus nisi simul cum vita amittit.
Back to top
View user's profile Send private message Visit poster's website 
mikeb


Joined: 23 Nov 2006
Posts: 8252

PostPosted: Mon 28 Dec 2009, 04:44    Post subject:  

Nice find....the curve of learning is forever upward Very Happy
So basically child processes from a gtkdialog dialog will behave as such with this added..neat...will be playing with that.
So another example would be alsamixer closing with the window exit I guess rather than needing an explicit kill.

mike
Back to top
View user's profile Send private message 
mcewanw

Joined: 16 Aug 2007
Posts: 2346
Location: New Zealand

PostPosted: Mon 28 Dec 2009, 05:11    Post subject:  

mikeb wrote:
Nice find....the curve of learning is forever upward :D
So basically child processes from a gtkdialog dialog will behave as such with this added..neat...will be playing with that.
So another example would be alsamixer closing with the window exit I guess rather than needing an explicit kill.

mike


Should be the case, I'd say.

But the technique likes:

gtkdialog3 --program=MAIN_DIALOG --center

but not...

MAIN_DIALOG=$(gtkdialog3 --program=MAIN_DIALOG --center)

though I'm half asleep, so I'm wondering if I'm missing something simple?

_________________
Non enim propter gloriam, diuicias aut honores pugnamus set propter libertatem solummodo quam Nemo bonus nisi simul cum vita amittit.
Back to top
View user's profile Send private message Visit poster's website 
mikeb


Joined: 23 Nov 2006
Posts: 8252

PostPosted: Mon 28 Dec 2009, 05:18    Post subject:  

Quote:
gtkdialog3 --program=MAIN_DIALOG --center

but not...

MAIN_DIALOG=$(gtkdialog3 --program=MAIN_DIALOG --center)


hhmm getting lost in the bash handling then...I'm tending towards the former anyway....some ways of using gtkdialog make me go crosseyed even when awake

regards and get some sleep

mike
Back to top
View user's profile Send private message 
mcewanw

Joined: 16 Aug 2007
Posts: 2346
Location: New Zealand

PostPosted: Mon 28 Dec 2009, 05:31    Post subject:  

mikeb wrote:
Quote:
gtkdialog3 --program=MAIN_DIALOG --center

but not...

MAIN_DIALOG=$(gtkdialog3 --program=MAIN_DIALOG --center)


hhmm getting lost in the bash handling then...I'm tending towards the former anyway....some ways of using gtkdialog make me go crosseyed even when awake

regards and get some sleep

mike


Hmmm... yes I'd better get some sleep: I'm going cuckoo:

It is the above that works for some reason; nothing to do with signal="hide", which doesn't seem to do anything in this context afterall... I need to rethink what is going on methinks...

_________________
Non enim propter gloriam, diuicias aut honores pugnamus set propter libertatem solummodo quam Nemo bonus nisi simul cum vita amittit.
Back to top
View user's profile Send private message Visit poster's website 
mcewanw

Joined: 16 Aug 2007
Posts: 2346
Location: New Zealand

PostPosted: Mon 28 Dec 2009, 05:44    Post subject:  

command substitution [i.e. backticks or $(...)] invokes a subshell, so that must be somthing to do with it. Even caffeine isn't helping at the moment. Anyway, it will be done.
_________________
Non enim propter gloriam, diuicias aut honores pugnamus set propter libertatem solummodo quam Nemo bonus nisi simul cum vita amittit.
Back to top
View user's profile Send private message Visit poster's website 
mcewanw

Joined: 16 Aug 2007
Posts: 2346
Location: New Zealand

PostPosted: Mon 28 Dec 2009, 06:52    Post subject:  

Oh well... all that detective work effort when all that was causing the problem was command substitution resulting in gtkdialog being run in a subshell! Anyway, I seem to have it all going properly now, but I won't make a pet of it until tomorrow because my mind is a bit blown now and I'd likely make a hash of it...

Very worth while remembering that though: run gtkdialog in a subshell and long-running processes won't close if the jwm wm [X] button is used to close the GUI... Nothing to do with signal="hide" in this case.

Answer: don't run gtkdialog in a subshell.

_________________
Non enim propter gloriam, diuicias aut honores pugnamus set propter libertatem solummodo quam Nemo bonus nisi simul cum vita amittit.
Back to top
View user's profile Send private message Visit poster's website 
mikeb


Joined: 23 Nov 2006
Posts: 8252

PostPosted: Mon 28 Dec 2009, 07:30    Post subject:  

It's amazing how much effort it takes to come to the tiniest of conclusions Very Happy
Took me several days to fix fonts in puppy 4 and the fix was one additional stanza in font.conf...but worth it....at least answers can be found...something that always bugged me with windows was those unanswered questions

mike
Back to top
View user's profile Send private message 
mcewanw

Joined: 16 Aug 2007
Posts: 2346
Location: New Zealand

PostPosted: Tue 29 Dec 2009, 09:19    Post subject: Uploaded version 5.0.2
Subject description: has much improved range of options for mp3 vbr
 

******Latest Version 5.0.2******
# Changes:
# Version 5.0.2: Fixed rec/play processes left running after jwm [X] pressed.
# mp3 vbr now uses combination of minimum bitrate + quality settings to determine compression and quality.
# running VU meter and alsamixer close on exit.
# changed commandline args (run: precord --help)

_________________
Non enim propter gloriam, diuicias aut honores pugnamus set propter libertatem solummodo quam Nemo bonus nisi simul cum vita amittit.
Back to top
View user's profile Send private message Visit poster's website 
Display posts from previous:   Sort by:   
Page 7 of 12 [177 Posts]   Goto page: Previous 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12 Next
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » Advanced Topics » Additional Software (PETs, n' stuff) » Multimedia
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.1003s ][ Queries: 12 (0.0053s) ][ GZIP on ]