From: phantomjinx <p.g...@ph...> - 2011-02-27 01:48:57
|
Morning folks, First beta of version 2 available for download and testing on sourceforge here -> http://sourceforge.net/projects/gtkpod/files/gtkpod/gtkpod-2.0.0-unstable/gtkpod-2.0.0-beta1.tar.gz/download Should you wish to use a deb or rpm then this beta is the same as the gtkpod*42c4b92*.[deb rpm] files under the gtkpod-2.0.0-unstable/20110227 directory. I note that active translation work is being undertaken on transifex for some languages, the latest being Czech, so these will be included in subsequent betas and the final release. However, I dont expect to include any new features from now but only bug fixes to this baseline. This beta will have a life of about a week and then depending on results, either a full release or further betas will be made. Thanks for your efforts PGR |
From: Chris J. <cdp...@gm...> - 2011-02-27 10:11:09
|
Thanks for uploading this. I noticed that if you want to build it from source and then run it "local" (ie without installing) then the source must be in a directory called gtkpod (rather than gtkpod-2.0.0) because there is some code in directories.c that specifically checks that the path to the executable contains the string "gtkpod/src". Untarring the source and then renaming gtkpod-2.0.0 to gtkpod before building did the trick for me. Cheers, Chris On 27 February 2011 01:48, phantomjinx <p.g...@ph...>wrote: > Morning folks, > > First beta of version 2 available for download and testing on > sourceforge here -> > > > http://sourceforge.net/projects/gtkpod/files/gtkpod/gtkpod-2.0.0-unstable/gtkpod-2.0.0-beta1.tar.gz/download > > Should you wish to use a deb or rpm then this beta is the same as the > gtkpod*42c4b92*.[deb rpm] files under the gtkpod-2.0.0-unstable/20110227 > directory. > > I note that active translation work is being undertaken on transifex for > some languages, the latest being Czech, so these will be included in > subsequent betas and the final release. > > However, I dont expect to include any new features from now but only bug > fixes to this baseline. This beta will have a life of about a week and > then depending on results, either a full release or further betas will > be made. > > Thanks for your efforts > > PGR > > > ------------------------------------------------------------------------------ > Free Software Download: Index, Search & Analyze Logs and other IT data in > Real-Time with Splunk. Collect, index and harness all the fast moving IT > data > generated by your applications, servers and devices whether physical, > virtual > or in the cloud. Deliver compliance at lower cost and gain new business > insights. http://p.sf.net/sfu/splunk-dev2dev > _______________________________________________ > Gtkpod-devel mailing list > Gtk...@li... > https://lists.sourceforge.net/lists/listinfo/gtkpod-devel > |
From: Rainer M K. <r.m...@gm...> - 2011-02-28 09:26:23
|
Hi One question: I can only set the maximum time "auto save every second" to a maximum of 100 seconds - that is not much (at least ion the ipod touch 1 gen, where the transfer is rather slow and the updating is also rather slow). Would it be possible to increase that limit, or even set it to minutes? I can not imagine someboty doing autosaves every less them one inute. Cheers, Rainer On Sun, Feb 27, 2011 at 2:48 AM, phantomjinx <p.g...@ph...> wrote: > Morning folks, > > First beta of version 2 available for download and testing on > sourceforge here -> > > http://sourceforge.net/projects/gtkpod/files/gtkpod/gtkpod-2.0.0-unstable/gtkpod-2.0.0-beta1.tar.gz/download > > Should you wish to use a deb or rpm then this beta is the same as the > gtkpod*42c4b92*.[deb rpm] files under the gtkpod-2.0.0-unstable/20110227 > directory. > > I note that active translation work is being undertaken on transifex for > some languages, the latest being Czech, so these will be included in > subsequent betas and the final release. > > However, I dont expect to include any new features from now but only bug > fixes to this baseline. This beta will have a life of about a week and > then depending on results, either a full release or further betas will > be made. > > Thanks for your efforts > > PGR > > ------------------------------------------------------------------------------ > Free Software Download: Index, Search & Analyze Logs and other IT data in > Real-Time with Splunk. Collect, index and harness all the fast moving IT data > generated by your applications, servers and devices whether physical, virtual > or in the cloud. Deliver compliance at lower cost and gain new business > insights. http://p.sf.net/sfu/splunk-dev2dev > _______________________________________________ > Gtkpod-questions mailing list > Gtk...@li... > https://lists.sourceforge.net/lists/listinfo/gtkpod-questions > -- NEW GERMAN FAX NUMBER!!! Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Natural Sciences Building Office Suite 2039 Stellenbosch University Main Campus, Merriman Avenue Stellenbosch South Africa Cell: +27 - (0)83 9479 042 Fax: +27 - (0)86 516 2782 Fax: +49 - (0)321 2125 2244 email: Ra...@kr... Skype: RMkrug Google: R.M...@gm... |
From: Javier K. <jk...@gm...> - 2011-02-28 09:36:01
|
On Mon, Feb 28, 2011 at 10:26, Rainer M Krug <r.m...@gm...> wrote: > Hi > > One question: I can only set the maximum time "auto save every second" > to a maximum of 100 seconds - that is not much (at least ion the ipod > touch 1 gen, where the transfer is rather slow and the updating is > also rather slow). Would it be possible to increase that limit, or > even set it to minutes? I can not imagine someboty doing autosaves > every less them one inute. > Certainly. I think this is related to the problem I reported with this setting being linked to another one. If P.G. doesn't know what I'm talking about, I might try seeing how this GTK+ UI designer works and see if I can spot the problem. One reason not to make the limit to high though is that it seems the time spent transcoding tracks is not taken into account because of the way the saving code works, so what happens is the following: gtkpod spends 60 seconds (or whatever you set this property to) reading songs from your file system, which on my system gives about 120 songs, then it transcodes all of them and finally saves the database. The transcoding takes about 20 minutes here, so obviously the setting is not doing what it's intended to do. I only found this out last night, so I'll think of ways to fix it. |
From: Rainer M K. <R.M...@gm...> - 2011-02-28 09:58:47
|
On 02/28/2011 10:35 AM, Javier Kohen wrote: > > > On Mon, Feb 28, 2011 at 10:26, Rainer M Krug <r.m...@gm... > <mailto:r.m...@gm...>> wrote: > > Hi > > One question: I can only set the maximum time "auto save every second" > to a maximum of 100 seconds - that is not much (at least ion the ipod > touch 1 gen, where the transfer is rather slow and the updating is > also rather slow). Would it be possible to increase that limit, or > even set it to minutes? I can not imagine someboty doing autosaves > every less them one inute. > > > Certainly. I think this is related to the problem I reported with this > setting being linked to another one. If P.G. doesn't know what I'm > talking about, I might try seeing how this GTK+ UI designer works and > see if I can spot the problem. Great - thanks. > > One reason not to make the limit to high though is that it seems the > time spent transcoding tracks is not taken into account because of the > way the saving code works, so what happens is the following: gtkpod > spends 60 seconds (or whatever you set this property to) reading songs > from your file system, which on my system gives about 120 songs, then it > transcodes all of them and finally saves the database. The transcoding > takes about 20 minutes here, so obviously the setting is not doing what > it's intended to do. I only found this out last night, so I'll think of > ways to fix it. I don'd have any transcoding, as I do this manually. Now is a workflow question in need: 1) I mount my iPod (touch, 1Gen, 32GB) and load it into gtkpod 2) I add songs via "add folder" and this copies about 10 songs to the iPod in 10 seconds. Would it be better / faster to add them to a local repository and then copy from the local repository to the iPod? Rainer > > > > ------------------------------------------------------------------------------ > Free Software Download: Index, Search & Analyze Logs and other IT data in > Real-Time with Splunk. Collect, index and harness all the fast moving IT data > generated by your applications, servers and devices whether physical, virtual > or in the cloud. Deliver compliance at lower cost and gain new business > insights. http://p.sf.net/sfu/splunk-dev2dev > > > > _______________________________________________ > Gtkpod-questions mailing list > Gtk...@li... > https://lists.sourceforge.net/lists/listinfo/gtkpod-questions |
From: Rainer M K. <r.m...@gm...> - 2011-03-01 09:48:18
|
On Mon, Feb 28, 2011 at 8:14 PM, Javier Kohen <jk...@gm...> wrote: > > > On Mon, Feb 28, 2011 at 10:58, Rainer M Krug <r.m...@gm...> wrote: >> >> On 02/28/2011 10:35 AM, Javier Kohen wrote: >> > >> > >> > On Mon, Feb 28, 2011 at 10:26, Rainer M Krug <r.m...@gm... >> > <mailto:r.m...@gm...>> wrote: >> > >> > Hi >> > >> > One question: I can only set the maximum time "auto save every >> > second" >> > to a maximum of 100 seconds - that is not much (at least ion the >> > ipod >> > touch 1 gen, where the transfer is rather slow and the updating is >> > also rather slow). Would it be possible to increase that limit, or >> > even set it to minutes? I can not imagine someboty doing autosaves >> > every less them one inute. >> > >> > >> > Certainly. I think this is related to the problem I reported with this >> > setting being linked to another one. If P.G. doesn't know what I'm >> > talking about, I might try seeing how this GTK+ UI designer works and >> > see if I can spot the problem. >> >> Great - thanks. > > Both the problem you and I were seeing have been fixed with my commit > 91b0b77b8082cd04d75d74477e70367a167e5e20. > I'll look into more precise timing next, but it's not as important I think. True - although it is irritating, that the 100 seconds save takes actually considerably longer... > >> >> > >> > One reason not to make the limit to high though is that it seems the >> > time spent transcoding tracks is not taken into account because of the >> > way the saving code works, so what happens is the following: gtkpod >> > spends 60 seconds (or whatever you set this property to) reading songs >> > from your file system, which on my system gives about 120 songs, then it >> > transcodes all of them and finally saves the database. The transcoding >> > takes about 20 minutes here, so obviously the setting is not doing what >> > it's intended to do. I only found this out last night, so I'll think of >> > ways to fix it. >> >> I don'd have any transcoding, as I do this manually. >> >> Now is a workflow question in need: >> >> 1) I mount my iPod (touch, 1Gen, 32GB) and load it into gtkpod >> 2) I add songs via "add folder" and this copies about 10 songs to the >> iPod in 10 seconds. >> >> Would it be better / faster to add them to a local repository and then >> copy from the local repository to the iPod? > > Hm... why would it be? What are you trying to solve? To make thinks faster - but I can live with it. Cheers, Rainer > -- NEW GERMAN FAX NUMBER!!! Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Natural Sciences Building Office Suite 2039 Stellenbosch University Main Campus, Merriman Avenue Stellenbosch South Africa Cell: +27 - (0)83 9479 042 Fax: +27 - (0)86 516 2782 Fax: +49 - (0)321 2125 2244 email: Ra...@kr... Skype: RMkrug Google: R.M...@gm... |
From: Javier K. <jk...@gm...> - 2011-03-01 11:06:30
|
On Tue, Mar 1, 2011 at 10:48, Rainer M Krug <r.m...@gm...> wrote: > On Mon, Feb 28, 2011 at 8:14 PM, Javier Kohen <jk...@gm...> wrote: > > > > > > On Mon, Feb 28, 2011 at 10:58, Rainer M Krug <r.m...@gm...> wrote: > >> > >> On 02/28/2011 10:35 AM, Javier Kohen wrote: > >> > > >> > > >> > On Mon, Feb 28, 2011 at 10:26, Rainer M Krug <r.m...@gm... > >> > <mailto:r.m...@gm...>> wrote: > >> > > >> > Hi > >> > > >> > One question: I can only set the maximum time "auto save every > >> > second" > >> > to a maximum of 100 seconds - that is not much (at least ion the > >> > ipod > >> > touch 1 gen, where the transfer is rather slow and the updating is > >> > also rather slow). Would it be possible to increase that limit, or > >> > even set it to minutes? I can not imagine someboty doing autosaves > >> > every less them one inute. > >> > > >> > > >> > Certainly. I think this is related to the problem I reported with this > >> > setting being linked to another one. If P.G. doesn't know what I'm > >> > talking about, I might try seeing how this GTK+ UI designer works and > >> > see if I can spot the problem. > >> > >> Great - thanks. > > > > Both the problem you and I were seeing have been fixed with my commit > > 91b0b77b8082cd04d75d74477e70367a167e5e20. > > I'll look into more precise timing next, but it's not as important I > think. > > True - although it is irritating, that the 100 seconds save takes > actually considerably longer... > Could you give me more details? What takes longer? The limit is 10 minutes now, by the way. |
From: Rainer M K. <r.m...@gm...> - 2011-03-01 11:17:14
|
On Tue, Mar 1, 2011 at 12:06 PM, Javier Kohen <jk...@gm...> wrote: > > > On Tue, Mar 1, 2011 at 10:48, Rainer M Krug <r.m...@gm...> wrote: >> >> On Mon, Feb 28, 2011 at 8:14 PM, Javier Kohen <jk...@gm...> wrote: >> > >> > >> > On Mon, Feb 28, 2011 at 10:58, Rainer M Krug <r.m...@gm...> wrote: >> >> >> >> On 02/28/2011 10:35 AM, Javier Kohen wrote: >> >> > >> >> > >> >> > On Mon, Feb 28, 2011 at 10:26, Rainer M Krug <r.m...@gm... >> >> > <mailto:r.m...@gm...>> wrote: >> >> > >> >> > Hi >> >> > >> >> > One question: I can only set the maximum time "auto save every >> >> > second" >> >> > to a maximum of 100 seconds - that is not much (at least ion the >> >> > ipod >> >> > touch 1 gen, where the transfer is rather slow and the updating >> >> > is >> >> > also rather slow). Would it be possible to increase that limit, >> >> > or >> >> > even set it to minutes? I can not imagine someboty doing >> >> > autosaves >> >> > every less them one inute. >> >> > >> >> > >> >> > Certainly. I think this is related to the problem I reported with >> >> > this >> >> > setting being linked to another one. If P.G. doesn't know what I'm >> >> > talking about, I might try seeing how this GTK+ UI designer works and >> >> > see if I can spot the problem. >> >> >> >> Great - thanks. >> > >> > Both the problem you and I were seeing have been fixed with my commit >> > 91b0b77b8082cd04d75d74477e70367a167e5e20. >> > I'll look into more precise timing next, but it's not as important I >> > think. >> >> True - although it is irritating, that the 100 seconds save takes >> actually considerably longer... > > Could you give me more details? What takes longer? The limit is 10 minutes > now, by the way. Sorry - the maximum of 10 minutes is fine - thanks. The actual *copying* of the tracks to the ipod between syncs (on the ipod - showing "syncing ...") takes longer. I am at the moment adding 450 tracks from a local repo and it will take about one hour, I have set it to less then a minute (I don't remember actually, but I can check later) and it hasn't done a sync on the iPod yet. > -- NEW GERMAN FAX NUMBER!!! Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Natural Sciences Building Office Suite 2039 Stellenbosch University Main Campus, Merriman Avenue Stellenbosch South Africa Cell: +27 - (0)83 9479 042 Fax: +27 - (0)86 516 2782 Fax: +49 - (0)321 2125 2244 email: Ra...@kr... Skype: RMkrug Google: R.M...@gm... |
From: Javier K. <jk...@gm...> - 2011-03-01 11:23:03
|
On Tue, Mar 1, 2011 at 12:17, Rainer M Krug <r.m...@gm...> wrote: > On Tue, Mar 1, 2011 at 12:06 PM, Javier Kohen <jk...@gm...> wrote: > > > > > > On Tue, Mar 1, 2011 at 10:48, Rainer M Krug <r.m...@gm...> wrote: > >> > >> On Mon, Feb 28, 2011 at 8:14 PM, Javier Kohen <jk...@gm...> wrote: > >> > > >> > > >> > On Mon, Feb 28, 2011 at 10:58, Rainer M Krug <r.m...@gm...> > wrote: > >> >> > >> >> On 02/28/2011 10:35 AM, Javier Kohen wrote: > >> >> > > >> >> > > >> >> > On Mon, Feb 28, 2011 at 10:26, Rainer M Krug <r.m...@gm... > >> >> > <mailto:r.m...@gm...>> wrote: > >> >> > > >> >> > Hi > >> >> > > >> >> > One question: I can only set the maximum time "auto save every > >> >> > second" > >> >> > to a maximum of 100 seconds - that is not much (at least ion > the > >> >> > ipod > >> >> > touch 1 gen, where the transfer is rather slow and the updating > >> >> > is > >> >> > also rather slow). Would it be possible to increase that limit, > >> >> > or > >> >> > even set it to minutes? I can not imagine someboty doing > >> >> > autosaves > >> >> > every less them one inute. > >> >> > > >> >> > > >> >> > Certainly. I think this is related to the problem I reported with > >> >> > this > >> >> > setting being linked to another one. If P.G. doesn't know what I'm > >> >> > talking about, I might try seeing how this GTK+ UI designer works > and > >> >> > see if I can spot the problem. > >> >> > >> >> Great - thanks. > >> > > >> > Both the problem you and I were seeing have been fixed with my commit > >> > 91b0b77b8082cd04d75d74477e70367a167e5e20. > >> > I'll look into more precise timing next, but it's not as important I > >> > think. > >> > >> True - although it is irritating, that the 100 seconds save takes > >> actually considerably longer... > > > > Could you give me more details? What takes longer? The limit is 10 > minutes > > now, by the way. > > Sorry - the maximum of 10 minutes is fine - thanks. > > The actual *copying* of the tracks to the ipod between syncs (on the > ipod - showing "syncing ...") takes longer. I am at the moment adding > 450 tracks from a local repo and it will take about one hour, I have > set it to less then a minute (I don't remember actually, but I can > check later) and it hasn't done a sync on the iPod yet. > Yes, I've noticed. It gets even worse when transcoding. I need to make a more invasive change in order to be able to interrupt the actual saving. |
From: Javier K. <jk...@gm...> - 2011-03-06 09:16:34
|
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? On Tue, Mar 1, 2011 at 12:23, Javier Kohen <jk...@gm...> wrote: > > On Tue, Mar 1, 2011 at 12:17, Rainer M Krug <r.m...@gm...> wrote: > >> On Tue, Mar 1, 2011 at 12:06 PM, Javier Kohen <jk...@gm...> wrote: >> > >> > >> > On Tue, Mar 1, 2011 at 10:48, Rainer M Krug <r.m...@gm...> wrote: >> >> >> >> On Mon, Feb 28, 2011 at 8:14 PM, Javier Kohen <jk...@gm...> >> wrote: >> >> > >> >> > >> >> > On Mon, Feb 28, 2011 at 10:58, Rainer M Krug <r.m...@gm...> >> wrote: >> >> >> >> >> >> On 02/28/2011 10:35 AM, Javier Kohen wrote: >> >> >> > >> >> >> > >> >> >> > On Mon, Feb 28, 2011 at 10:26, Rainer M Krug <r.m...@gm... >> >> >> > <mailto:r.m...@gm...>> wrote: >> >> >> > >> >> >> > Hi >> >> >> > >> >> >> > One question: I can only set the maximum time "auto save every >> >> >> > second" >> >> >> > to a maximum of 100 seconds - that is not much (at least ion >> the >> >> >> > ipod >> >> >> > touch 1 gen, where the transfer is rather slow and the >> updating >> >> >> > is >> >> >> > also rather slow). Would it be possible to increase that >> limit, >> >> >> > or >> >> >> > even set it to minutes? I can not imagine someboty doing >> >> >> > autosaves >> >> >> > every less them one inute. >> >> >> > >> >> >> > >> >> >> > Certainly. I think this is related to the problem I reported with >> >> >> > this >> >> >> > setting being linked to another one. If P.G. doesn't know what I'm >> >> >> > talking about, I might try seeing how this GTK+ UI designer works >> and >> >> >> > see if I can spot the problem. >> >> >> >> >> >> Great - thanks. >> >> > >> >> > Both the problem you and I were seeing have been fixed with my commit >> >> > 91b0b77b8082cd04d75d74477e70367a167e5e20. >> >> > I'll look into more precise timing next, but it's not as important I >> >> > think. >> >> >> >> True - although it is irritating, that the 100 seconds save takes >> >> actually considerably longer... >> > >> > Could you give me more details? What takes longer? The limit is 10 >> minutes >> > now, by the way. >> >> Sorry - the maximum of 10 minutes is fine - thanks. >> >> The actual *copying* of the tracks to the ipod between syncs (on the >> ipod - showing "syncing ...") takes longer. I am at the moment adding >> 450 tracks from a local repo and it will take about one hour, I have >> set it to less then a minute (I don't remember actually, but I can >> check later) and it hasn't done a sync on the iPod yet. >> > > Yes, I've noticed. It gets even worse when transcoding. I need to make a > more invasive change in order to be able to interrupt the actual saving. > > |
From: phantomjinx <p.g...@ph...> - 2011-03-06 11:13:25
|
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. Although, I may have totally confused the situation. phantomjinx |
From: Javier K. <jk...@gm...> - 2011-03-06 11:20:27
|
On Sun, Mar 6, 2011 at 12:13, phantomjinx <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. |
From: phantomjinx <p.g...@ph...> - 2011-03-06 11:51:13
|
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 |
From: Rainer M K. <r.m...@gm...> - 2011-03-07 08:51:47
|
On Sun, Mar 6, 2011 at 12:50 PM, phantomjinx <p.g...@ph...> wrote: > 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. The user is not that interestd in the inner workings of a program - therefore a setting which uses time will be expected by a user to be saving after that given time (or as soon as possible afterwards) and not after up to 60 minutes when 10 minutes si set - that might be confused with a bug. As you pointed out, reliability is the issue here, and to have effectively "checkpoints" after the time set, after which the copying can be picked up if an unexpected disconnect occurs. So from a user perspective, I would say that option of having it time based is only useful if this time interval is actually kept. The second option is to go back to the "saving after x tracks". That is the option which I think is more intuitive: when copying tracks to the iPod, I usually know how many tracks I will copy, but I do't know how long it will take - therefore I, personally, would consider the option of having the "checkpoint" saved after x tracks more userfriendly. Cheers, Raine > > Cheers > > PGR > > > > ------------------------------------------------------------------------------ > What You Don't Know About Data Connectivity CAN Hurt You > This paper provides an overview of data connectivity, details > its effect on application quality, and explores various alternative > solutions. http://p.sf.net/sfu/progress-d2d > _______________________________________________ > Gtkpod-questions mailing list > Gtk...@li... > https://lists.sourceforge.net/lists/listinfo/gtkpod-questions > -- NEW GERMAN FAX NUMBER!!! Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Natural Sciences Building Office Suite 2039 Stellenbosch University Main Campus, Merriman Avenue Stellenbosch South Africa Cell: +27 - (0)83 9479 042 Fax: +27 - (0)86 516 2782 Fax: +49 - (0)321 2125 2244 email: Ra...@kr... Skype: RMkrug Google: R.M...@gm... |
From: Javier K. <jk...@gm...> - 2011-03-07 20:52:03
|
On Mon, Mar 7, 2011 at 09:51, Rainer M Krug <r.m...@gm...> wrote: > > The user is not that interestd in the inner workings of a program - > therefore a setting which uses time will be expected by a user to be > saving after that given time (or as soon as possible afterwards) and > not after up to 60 minutes when 10 minutes si set - that might be > confused with a bug. As you pointed out, reliability is the issue > here, and to have effectively "checkpoints" after the time set, after > which the copying can be picked up if an unexpected disconnect occurs. > > So from a user perspective, I would say that option of having it time > based is only useful if this time interval is actually kept. The > second option is to go back to the "saving after x tracks". That is > the option which I think is more intuitive: when copying tracks to the > iPod, I usually know how many tracks I will copy, but I do't know how > long it will take - therefore I, personally, would consider the option > of having the "checkpoint" saved after x tracks more userfriendly. > Since we agree, I've reverted the change, except for separating the related GtkAdjustment from the number of threads GtkAdjustment, which was a real fix. Rainer, how long does it take on your iPod to save 10 tracks + to write the database? I would suggest changing the default to something higher than 10 tracks, otherwise it could hurt performance severely for users who are not aware of this setting. |
From: Rainer M K. <r.m...@gm...> - 2011-03-08 08:19:42
|
On Mon, Mar 7, 2011 at 9:51 PM, Javier Kohen <jk...@gm...> wrote: > > > On Mon, Mar 7, 2011 at 09:51, Rainer M Krug <r.m...@gm...> wrote: >> >> The user is not that interestd in the inner workings of a program - >> therefore a setting which uses time will be expected by a user to be >> saving after that given time (or as soon as possible afterwards) and >> not after up to 60 minutes when 10 minutes si set - that might be >> confused with a bug. As you pointed out, reliability is the issue >> here, and to have effectively "checkpoints" after the time set, after >> which the copying can be picked up if an unexpected disconnect occurs. >> >> So from a user perspective, I would say that option of having it time >> based is only useful if this time interval is actually kept. The >> second option is to go back to the "saving after x tracks". That is >> the option which I think is more intuitive: when copying tracks to the >> iPod, I usually know how many tracks I will copy, but I do't know how >> long it will take - therefore I, personally, would consider the option >> of having the "checkpoint" saved after x tracks more userfriendly. > > Since we agree, I've reverted the change, except for separating the related > GtkAdjustment from the number of threads GtkAdjustment, which was a real > fix. Great. > Rainer, how long does it take on your iPod to save 10 tracks + to write the > database? I would suggest changing the default to something higher than 10 > tracks, otherwise it could hurt performance severely for users who are not > aware of this setting. I don't have any real numbers, but as far as I remember, the writing of the database took about 1/4 to 1/3 of the overall time when adding 10 tracks. I agree - the default should be higher. I would set it to around somewhere between 30 and 50. It should be definitely higher then a typical album - so I would suggest 40. In regard to my problems (mounting of iPod breaks), I experience sometimes even a complete crash of gtkpod - and I don't have a clue when. Cheers, Rainer -- NEW GERMAN FAX NUMBER!!! Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Natural Sciences Building Office Suite 2039 Stellenbosch University Main Campus, Merriman Avenue Stellenbosch South Africa Cell: +27 - (0)83 9479 042 Fax: +27 - (0)86 516 2782 Fax: +49 - (0)321 2125 2244 email: Ra...@kr... Skype: RMkrug Google: R.M...@gm... |
From: Javier K. <jk...@gm...> - 2011-03-08 10:35:41
|
On Tue, Mar 8, 2011 at 11:33, P.G. Richardson < p.g...@ph...> wrote: > <snip> > > In regard to my problems (mounting of iPod breaks), I experience > > sometimes even a complete crash of gtkpod - and I don't have a clue > > when. > > > > Are you using beta1 or beta2? If the former then I would recommend the > latter. > And maybe try running a build with debug information within gdb, so you can get a stack trace if it anything goes wrong. I haven't seen any crashes and I recently uploaded 18000 tracks to my iPod. |
From: Rainer M K. <r.m...@gm...> - 2011-03-08 10:40:02
|
On Tue, Mar 8, 2011 at 11:35 AM, Javier Kohen <jk...@gm...> wrote: > > > On Tue, Mar 8, 2011 at 11:33, P.G. Richardson > <p.g...@ph...> wrote: >> >> <snip> >> > In regard to my problems (mounting of iPod breaks), I experience >> > sometimes even a complete crash of gtkpod - and I don't have a clue >> > when. >> > >> >> Are you using beta1 or beta2? If the former then I would recommend the >> latter. > > And maybe try running a build with debug information within gdb, so you can > get a stack trace if it anything goes wrong. > I haven't seen any crashes and I recently uploaded 18000 tracks to my iPod. beta2, self compiled. The crash is definitely linked to the disconnection of the iPod while copying / synching. I only had it a few times while trying out things. So I decided to try a "manual offline" approach - copying the iPod file structure to my HDD, adding al the tracks, and copying them back. I am copying now back for already 90 minutes, and everything is OK ( but this does not help you). I should have thought about gdb. I am compiling the new gtkpod (.bb....) and will add the debug info to it and see that I try it again. I will give feedback as soon as it crashes again (which hopefully it does not), Rainer > -- NEW GERMAN FAX NUMBER!!! Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Natural Sciences Building Office Suite 2039 Stellenbosch University Main Campus, Merriman Avenue Stellenbosch South Africa Cell: +27 - (0)83 9479 042 Fax: +27 - (0)86 516 2782 Fax: +49 - (0)321 2125 2244 email: Ra...@kr... Skype: RMkrug Google: R.M...@gm... |
From: Rainer M K. <r.m...@gm...> - 2011-03-08 10:44:16
|
On Tue, Mar 8, 2011 at 11:39 AM, Rainer M Krug <r.m...@gm...> wrote: > On Tue, Mar 8, 2011 at 11:35 AM, Javier Kohen <jk...@gm...> wrote: >> >> >> On Tue, Mar 8, 2011 at 11:33, P.G. Richardson >> <p.g...@ph...> wrote: >>> >>> <snip> >>> > In regard to my problems (mounting of iPod breaks), I experience >>> > sometimes even a complete crash of gtkpod - and I don't have a clue >>> > when. >>> > >>> >>> Are you using beta1 or beta2? If the former then I would recommend the >>> latter. >> >> And maybe try running a build with debug information within gdb, so you can >> get a stack trace if it anything goes wrong. >> I haven't seen any crashes and I recently uploaded 18000 tracks to my iPod. > > beta2, self compiled. > > The crash is definitely linked to the disconnection of the iPod while > copying / synching. I only had it a few times while trying out things. > So I decided to try a "manual offline" approach - copying the iPod > file structure to my HDD, adding al the tracks, and copying them back. > I am copying now back for already 90 minutes, and everything is OK ( > but this does not help you). > > I should have thought about gdb. I am compiling the new gtkpod > (.bb....) and will add the debug info to it and see that I try it > again. > > I will give feedback as soon as it crashes again (which hopefully it does not), Actually, I could not find any specific debug option in configure - is there anything I have to add whenn calling configure? > > Rainer > > >> > > > > -- > NEW GERMAN FAX NUMBER!!! > > Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation > Biology, UCT), Dipl. Phys. (Germany) > > Centre of Excellence for Invasion Biology > Natural Sciences Building > Office Suite 2039 > Stellenbosch University > Main Campus, Merriman Avenue > Stellenbosch > South Africa > > Cell: +27 - (0)83 9479 042 > Fax: +27 - (0)86 516 2782 > Fax: +49 - (0)321 2125 2244 > email: Ra...@kr... > > Skype: RMkrug > Google: R.M...@gm... > -- NEW GERMAN FAX NUMBER!!! Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Natural Sciences Building Office Suite 2039 Stellenbosch University Main Campus, Merriman Avenue Stellenbosch South Africa Cell: +27 - (0)83 9479 042 Fax: +27 - (0)86 516 2782 Fax: +49 - (0)321 2125 2244 email: Ra...@kr... Skype: RMkrug Google: R.M...@gm... |
From: Javier K. <jk...@gm...> - 2011-03-08 10:46:48
|
On Tue, Mar 8, 2011 at 11:44, Rainer M Krug <r.m...@gm...> wrote: > > Actually, I could not find any specific debug option in configure - is > there anything I have to add whenn calling configure? > I usually invoke "./configure CFLAGS=-ggdb LDFLAGS=-ggdb". You can add -O0 to both for increased precision in the debug info. LDFLAGS might not be needed, but it also doesn't hurt. |
From: Rainer M K. <r.m...@gm...> - 2011-03-08 10:51:22
|
On Tue, Mar 8, 2011 at 11:46 AM, Javier Kohen <jk...@gm...> wrote: > > > On Tue, Mar 8, 2011 at 11:44, Rainer M Krug <r.m...@gm...> wrote: >> >> Actually, I could not find any specific debug option in configure - is >> there anything I have to add whenn calling configure? > > I usually invoke "./configure CFLAGS=-ggdb LDFLAGS=-ggdb". You can add -O0 > to both for increased precision in the debug info. LDFLAGS might not be > needed, but it also doesn't hurt. Thanks - I used the configure as you specified it (plus --prefix=$HOME) as I tried -ggdb-O0 and -ggdbO0, but none worked. Cheers and thanks, Rainer > -- NEW GERMAN FAX NUMBER!!! Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Natural Sciences Building Office Suite 2039 Stellenbosch University Main Campus, Merriman Avenue Stellenbosch South Africa Cell: +27 - (0)83 9479 042 Fax: +27 - (0)86 516 2782 Fax: +49 - (0)321 2125 2244 email: Ra...@kr... Skype: RMkrug Google: R.M...@gm... |
From: Rainer M K. <r.m...@gm...> - 2011-03-09 12:08:29
|
OK - first results: gtkpod 2.0.0.bb2aec9 self compiled I got an empty main window and an empty message box, and nothing happened any more after a unexpected disconnection of the iPod. Mesasage in gdb: (gtkpod:4542): GLib-WARNING **: GError set over the top of a previous GError or uninitialized memory. This indicates a bug in someone's code. You must ensure an error is NULL before it's set. The overwriting error message was: '/home/rkrug/.gvfs/iPod_Touch_1/iTunes_Control/Music/F16/libgpod041235.mp3' could not be accessed (Input/output error). process 4542: arguments to dbus_connection_ref() were incorrect, assertion "connection->generation == _dbus_current_generation" failed in file dbus-connection.c line 2637. This is normally a bug in some application using the D-Bus library. I had to kill gtkpod to close it. This happened while adding mp3 files to iPod - m4a earlier worked, although I do not think that has anything to do with the error. In addition: the "save after x tracks" does not work - set it to 50, but it did not save at all before finishing the m4as and not while adding the mp3. More might follow, Rainer On Tue, Mar 8, 2011 at 11:51 AM, Rainer M Krug <r.m...@gm...> wrote: > On Tue, Mar 8, 2011 at 11:46 AM, Javier Kohen <jk...@gm...> wrote: >> >> >> On Tue, Mar 8, 2011 at 11:44, Rainer M Krug <r.m...@gm...> wrote: >>> >>> Actually, I could not find any specific debug option in configure - is >>> there anything I have to add whenn calling configure? >> >> I usually invoke "./configure CFLAGS=-ggdb LDFLAGS=-ggdb". You can add -O0 >> to both for increased precision in the debug info. LDFLAGS might not be >> needed, but it also doesn't hurt. > > Thanks - I used the configure as you specified it (plus > --prefix=$HOME) as I tried -ggdb-O0 and -ggdbO0, but none worked. > > Cheers and thanks, > > Rainer > >> > > > > -- > NEW GERMAN FAX NUMBER!!! > > Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation > Biology, UCT), Dipl. Phys. (Germany) > > Centre of Excellence for Invasion Biology > Natural Sciences Building > Office Suite 2039 > Stellenbosch University > Main Campus, Merriman Avenue > Stellenbosch > South Africa > > Cell: +27 - (0)83 9479 042 > Fax: +27 - (0)86 516 2782 > Fax: +49 - (0)321 2125 2244 > email: Ra...@kr... > > Skype: RMkrug > Google: R.M...@gm... > -- NEW GERMAN FAX NUMBER!!! Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Natural Sciences Building Office Suite 2039 Stellenbosch University Main Campus, Merriman Avenue Stellenbosch South Africa Cell: +27 - (0)83 9479 042 Fax: +27 - (0)86 516 2782 Fax: +49 - (0)321 2125 2244 email: Ra...@kr... Skype: RMkrug Google: R.M...@gm... |
From: Javier K. <jk...@gm...> - 2011-03-09 16:36:29
|
On Wed, Mar 9, 2011 at 13:08, Rainer M Krug <r.m...@gm...> wrote: > OK - first results: > > gtkpod 2.0.0.bb2aec9 self compiled > > I got an empty main window and an empty message box, and nothing > happened any more after a unexpected disconnection of the iPod. > Mesasage in gdb: > > (gtkpod:4542): GLib-WARNING **: GError set over the top of a previous > GError or uninitialized memory. > This indicates a bug in someone's code. You must ensure an error is > NULL before it's set. > The overwriting error message was: > '/home/rkrug/.gvfs/iPod_Touch_1/iTunes_Control/Music/F16/libgpod041235.mp3' > could not be accessed (Input/output error). > process 4542: arguments to dbus_connection_ref() were incorrect, > assertion "connection->generation == _dbus_current_generation" failed > in file dbus-connection.c line 2637. > This is normally a bug in some application using the D-Bus library. > > > I had to kill gtkpod to close it. > > This happened while adding mp3 files to iPod - m4a earlier worked, > although I do not think that has anything to do with the error. > > In addition: the "save after x tracks" does not work - set it to 50, > but it did not save at all before finishing the m4as and not while > adding the mp3. > I just compiled HEAD, and this feature works for me with the setting set to save every 2 tracks importing mp3s. |
From: Rainer M K. <r.m...@gm...> - 2011-03-09 17:09:49
|
On Wed, Mar 9, 2011 at 5:36 PM, Javier Kohen <jk...@gm...> wrote: > > > On Wed, Mar 9, 2011 at 13:08, Rainer M Krug <r.m...@gm...> wrote: >> >> OK - first results: >> >> gtkpod 2.0.0.bb2aec9 self compiled >> >> I got an empty main window and an empty message box, and nothing >> happened any more after a unexpected disconnection of the iPod. >> Mesasage in gdb: >> >> (gtkpod:4542): GLib-WARNING **: GError set over the top of a previous >> GError or uninitialized memory. >> This indicates a bug in someone's code. You must ensure an error is >> NULL before it's set. >> The overwriting error message was: >> >> '/home/rkrug/.gvfs/iPod_Touch_1/iTunes_Control/Music/F16/libgpod041235.mp3' >> could not be accessed (Input/output error). >> process 4542: arguments to dbus_connection_ref() were incorrect, >> assertion "connection->generation == _dbus_current_generation" failed >> in file dbus-connection.c line 2637. >> This is normally a bug in some application using the D-Bus library. >> >> >> I had to kill gtkpod to close it. >> >> This happened while adding mp3 files to iPod - m4a earlier worked, >> although I do not think that has anything to do with the error. >> >> In addition: the "save after x tracks" does not work - set it to 50, >> but it did not save at all before finishing the m4as and not while >> adding the mp3. > > I just compiled HEAD, and this feature works for me with the setting set to > save every 2 tracks importing mp3s. Confirmed - working now. Rainer > -- NEW GERMAN FAX NUMBER!!! Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Natural Sciences Building Office Suite 2039 Stellenbosch University Main Campus, Merriman Avenue Stellenbosch South Africa Cell: +27 - (0)83 9479 042 Fax: +27 - (0)86 516 2782 Fax: +49 - (0)321 2125 2244 email: Ra...@kr... Skype: RMkrug Google: R.M...@gm... |