Re: [Gtkpod-questions] Version 2.0.0 first beta

[phantomjinx <p.g...@ph...>]

On 06/03/11 11:20, Javier Kohen wrote:
>
>
> On Sun, Mar 6, 2011 at 12:13, phantomjinx 
> <p.g...@ph... 
> <mailto:p.g...@ph...>> wrote:
>
>     On 06/03/11 09:16, Javier Kohen wrote:
>
>         Because the way the file conversion code is intertwined with
>         the song database, it's not trivial to limit the time spent
>         converting during saves; we'd risk saving the database before
>         the songs have been written, which would probably be a bad
>         idea. For such a minor feature as this I'm not motivated to
>         redesign the file conversion code, as it's an error prone process.
>
>         I can revert my change and going back to the save every N
>         tracks feature that was there before, which *is not more
>         precise*, since it can still take an arbitrarily long amount
>         of time between saves, however it works exactly as advertised
>         to the user.
>
>         What do you think?
>
>     <snip>
>
>     A little confused why you would want to 'limit' converting during
>     saves? The time interval determines how long before starting a
>     save during an import. If a save cuts into that time then "the
>     next save" should be ignored. What I mean is the clock should stop
>     when the save starts ... only resuming when the copying of tracks
>     resumes. Likewise, if copying tracks take longer than 10 minutes
>     then a save should be 'scheduled' after the remaining conversions
>     have finished. The 10 minute interval becomes an approximate
>     appropriate time rather than a definite hard rule.
>
>
> Sure, that's how it works. Rainer was rightfully confused though, 
> because the ten minutes can become more like 30-60 in reality. I 
> personally don't mind, but users could be confused.
>
> If you don't think it's a problem, I'm fine with leaving it as is.
>
Well, I think the question to ask ...

The original requirement was to improve reliability of track import by 
introducing a save point at a set interval. The improved reliability 
stems from a failure/crash etc... would mean that only a small number of 
tracks would be lost rather than the entire import. However, the 
original approach placed reliability too far above that of performance 
and the user experience was diminished by long import times.

So, Has this requirement been achieved? Is there now a fair balance 
between performance and reliability with the user able to understand 
when and how a save will be initiated?

Other than an explanation of the save interval on the preference page 
... I think it probably has but I think this is your's and Rainer's call.

Cheers

PGR