Re: [Rhythmbox-devel] playlist source burner

[William Jon McCann <mccannwj pha jhu edu>]

Hi,

Bastien Nocera wrote:
> Hey Colin,
>
> On Sat, 2004-08-28 at 21:37 -0400, Colin Walters wrote:
> > I agree with Bastien about the temporary folder UI (and GConf key).
> > nautilus-cd-burner just uses g_get_tmp_dir, this should be fine.  I
> > don't see a reason why an even halfway modern system wouldn't have space
> > for a CD image on the normal temporary directory paths.  And if they
> > don't, then we can add some code to autodetect large local volumes.
>
>
> Actually, nautilus-cd-burner uses either the user provided path,
> g_get_tmp_dir or the user's home directory, and checks the space left in
> each of them for that.

I suppose that whatever is done should be consistent between the two 
applications.  However, this method of automatically finding a temporary 
directory doesn't work very well in a few cases.

 - g_get_tmp_dir is too small or already used (perhaps by other users)
 - g_get_home_dir is on a (remote) filesystem that is unacceptable for 
use with streaming media
 - user doesn't know how to or cannot set TMPDIR|TMP|TEMP for only this 
process

And possibly:

 - sysadmin wants to set a default / mandated location for large media 
scratch files

I think this may actually hit more users than it might seem.  However, I 
think these all involve some sysadmin involvement at some point.  So, 
how about checking: GConf key shared between n-c-b and rb for media 
scratch location, g_get_tmp_dir(), g_get_home_dir()?  And removing the 
UI for the folder selection?

Using an autodetected large local volume without the user's consent may 
not be so good.  If RB happens to crash it will leave litter in an 
unknown place.


The next thing is to determine how much space will be needed.  The 
easiest way is to compute it from the song duration.  Is it safe to rely 
on the duration being present and correct?


Jon