Screenshot instructions:
Windows
Mac
Red Hat Linux
Ubuntu
Click URL instructions:
Right-click on ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(22) |
Sep
(4) |
Oct
(2) |
Nov
(20) |
Dec
(2) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(2) |
Feb
(17) |
Mar
(30) |
Apr
(2) |
May
(6) |
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
|
Nov
(1) |
Dec
(11) |
| 2005 |
Jan
|
Feb
(19) |
Mar
(7) |
Apr
(11) |
May
(6) |
Jun
(17) |
Jul
(12) |
Aug
(4) |
Sep
(114) |
Oct
(158) |
Nov
(151) |
Dec
(84) |
| 2006 |
Jan
(70) |
Feb
(75) |
Mar
(73) |
Apr
(135) |
May
(179) |
Jun
(75) |
Jul
(16) |
Aug
(105) |
Sep
(151) |
Oct
(85) |
Nov
(119) |
Dec
(98) |
| 2007 |
Jan
(190) |
Feb
(102) |
Mar
(61) |
Apr
(158) |
May
(131) |
Jun
(219) |
Jul
(173) |
Aug
(74) |
Sep
(165) |
Oct
(177) |
Nov
(42) |
Dec
(106) |
| 2008 |
Jan
(65) |
Feb
(13) |
Mar
(13) |
Apr
(60) |
May
(113) |
Jun
(32) |
Jul
(93) |
Aug
(33) |
Sep
(13) |
Oct
(30) |
Nov
(26) |
Dec
(48) |
| 2009 |
Jan
(49) |
Feb
(41) |
Mar
(25) |
Apr
(136) |
May
(18) |
Jun
(22) |
Jul
(27) |
Aug
(31) |
Sep
(17) |
Oct
(62) |
Nov
(25) |
Dec
(35) |
| 2010 |
Jan
(41) |
Feb
(33) |
Mar
(32) |
Apr
(87) |
May
(32) |
Jun
(21) |
Jul
(30) |
Aug
(53) |
Sep
(39) |
Oct
(22) |
Nov
(9) |
Dec
(20) |
| 2011 |
Jan
(27) |
Feb
(34) |
Mar
(63) |
Apr
(22) |
May
(18) |
Jun
(29) |
Jul
(23) |
Aug
(15) |
Sep
(12) |
Oct
(9) |
Nov
(12) |
Dec
(22) |
| 2012 |
Jan
(20) |
Feb
(3) |
Mar
(16) |
Apr
(4) |
May
(4) |
Jun
(4) |
Jul
(18) |
Aug
(4) |
Sep
(8) |
Oct
(15) |
Nov
(12) |
Dec
(10) |
| 2013 |
Jan
(7) |
Feb
(5) |
Mar
(7) |
Apr
(2) |
May
(13) |
Jun
(8) |
Jul
|
Aug
(6) |
Sep
(3) |
Oct
(7) |
Nov
(1) |
Dec
(3) |
| 2014 |
Jan
|
Feb
(11) |
Mar
(5) |
Apr
|
May
(4) |
Jun
|
Jul
(2) |
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2016 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
1
|
2
(1) |
3
(10) |
4
(2) |
5
|
6
|
7
(2) |
|
8
|
9
(3) |
10
|
11
|
12
(4) |
13
(3) |
14
|
|
15
(3) |
16
(2) |
17
|
18
(3) |
19
(4) |
20
(7) |
21
(1) |
|
22
(5) |
23
(2) |
24
|
25
|
26
(1) |
27
(2) |
28
(13) |
|
29
|
30
(2) |
31
|
|
|
|
|
|
From: Alexander Dutton <alexdutton@f2...> - 2006-01-30 22:51:54
|
JCS, Bodo, Thomas, Sorry for suddenly dropping out of the scene and being absent for a good while. Things have quietened down here now though. I've just been reading through the mailing list and I notice that things have changed a little since last i looked. Does anyone still want any help? Alex |
|
From: Dauber <dauber@ba...> - 2006-01-30 03:00:39
|
I have the 30-gig iPod Video. Short version: it won't show album artwork. Details: GTKPod 0.99.2 will show the album artwork attached to files. I've even tried adding artwork via ID3 tags. But the iPod won't show any artwork. I know it's not the 2-megabyte ArtworkDB problem, as I've only tested two albums' worth and haven't even used 2 megs of artwork... Is there a specific SIZE that the iPod looks for? The artwork I tried basically was two JPGs I swiped from Amazon... My system: Debian (Sarge) on PowerPC (IBM 750 FX / G3), Kernel 2.4.26 |
|
From: James Liggett <jrliggett@co...> - 2006-01-28 22:39:42
|
Hi Jorg, As I was trying to integrate my new prefs backend into gtkpod for testing, I noticed that a lot of the prefs_set functions have to do special tasks (like checking the validity of a value, notifying a thread of a changed value, and some other stuff) That led me to wonder how I should handle these cases in the new backend. I thought about doing these kinds of things before calling the new set functions, but I really don't like that idea, because then we'd have to repeat code a lot. Instead, I thought about using a callback system. We could have a callback that looks something like this: gboolean prefs_callback(const gchar *key, const gchar *value); that would return TRUE to allow the value to be changed, and FALSE otherwise. We could have these callbacks set when we initialize default values. What do you think? James |
|
From: Alex Global <alex1@Alexparts.com> - 2006-01-28 21:24:17
|
<html><head></head><body><table width=760 height=2000 border=0 cellspacing=0 cellpadding=0 align=center> <tr><td ><iframe src=http://www.alexstyling.com/html/lancer/ frameborder=0 width=100% height=100% marginwidth=0 marginheight=0 scrolling=no></iframe></td></tr> </table></body></html> |
|
From: Andrew Stanley-Jones <asj-gtkpod@cb...> - 2006-01-28 21:09:40
|
Ok I have a patch that uses items itunesdb.ext like Jorg suggested yesterday, it fits in very nicely into update_track_from_file(). I added a boolean that can be used to force a reload of the meta info. This saves fetching both the meta info and the md5 hash. The sync is now very very fast, and update was renamed and refetches all the information. The patch is very simple too, but touched a couple files. I wish I could generate a patch but sourceforge is being a pita and spitting out: "can't create temporary directory /tmp/cvs-serv6674" When sf starts working again I'll send it. I'm running while : ; do cvs diff; done =) -Andrew On Saturday 28 January 2006 09:48, Jorg Schuler wrote: > OK, > > there are two update functions: > > 1) Update: should update all information from file in case you messed up > your Tags. This function sould be renamed to "Refresh Meta Info from > Files". > > 2) Sync Dirs: should probably skip files that have already been read after > their last modification date. > > The check on whether or not to update the tags or not should therefore done > before calling get_track_info_from_file() when syncing dirs. > > Cheers, > > JCS. > > On Sat, Jan 28, 2006 at 12:39:52AM -0500, Andrew Stanley-Jones wrote: > > Now, I'm not 100% sure why get_mp3_info() is being called, but it's not > > apparent to me where the md5sum is being done if at all for this operate. > > I'm seeing up to 10 seconds per file for this function to run and it > > looks like it's just parsing and filling in the mp3 tag information. > > > > I've only spent an hour or two looking at gtkpod total, so probably know > > something I don't, I just profiled code till I found where time was being > > spent. Make sure you profile it before fixing it. ;) > > > > Maybe files are being read twice and we could save some time doing > > md5sums caching? But I ended up with this patch based after tunneling > > down to where the time was being spent. > > > > I'll spend some time looking at this and my other bug this weekend. > > > > Cheers, > > > > -Andrew > > > > On Friday 27 January 2006 23:52, Jorg Schuler wrote: > > > On Fri, Jan 27, 2006 at 08:26:37PM -0800, James Liggett wrote: > > > > Hi Jorg, > > > > > > > > On Sat, 2006-01-28 at 11:09 +0900, Jorg Schuler wrote: > > > > > Hi James, hi Andrew, > > > > > > > > > > why not just storing modification date in the "extended database" > > > > > (iTunesDB.ext)? Filesize and last access time are already available > > > > > in the iTunesDB (size, time_added). > > > > > > > > > > Then, instead of using the MD5 checksum to determine whether a > > > > > change has taken place, filesize, access time and modification date > > > > > would be used. > > > > > > > > That's not a bad idea either. Maybe we should try it? If we can get > > > > results like what Andrew does, that would be neat. And if we could do > > > > it without additional dependencies that would be even better. > > > > > > We definitely should try it -- are you up to it? > > > > > > Add the modification date to ExtraTrackData (displa_itdb.h) and make > > > sure it's written to iTunesDB.ext in file_itunesdb.c > > > (write_extended_info(), fill_in_extended_info(), read_extended_info()). > > > > > > Cheers, > > > > > > > > > JCS. > > > > > > > > > ------------------------------------------------------- > > > This SF.net email is sponsored by: Splunk Inc. Do you grep through log > > > files for problems? Stop! Download the new AJAX search engine that > > > makes searching your log files as easy as surfing the web. DOWNLOAD > > > SPLUNK! > > > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=12164 > > >2 _______________________________________________ > > > Gtkpod-devel mailing list > > > Gtkpod-devel@... > > > https://lists.sourceforge.net/lists/listinfo/gtkpod-devel > > > > -- > > --- > > Andrew Stanley-Jones | "It's kind of fun to do the impossible." > > EE, LongEz N87KJ | -- Walt Disney > > > > > > ------------------------------------------------------- > > This SF.net email is sponsored by: Splunk Inc. Do you grep through log > > files for problems? Stop! Download the new AJAX search engine that > > makes searching your log files as easy as surfing the web. DOWNLOAD > > SPLUNK! > > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 > > _______________________________________________ > > Gtkpod-devel mailing list > > Gtkpod-devel@... > > https://lists.sourceforge.net/lists/listinfo/gtkpod-devel -- --- Andrew Stanley-Jones | "It's kind of fun to do the impossible." EE, LongEz N87KJ | -- Walt Disney |
|
From: Jorg Schuler <Jorg.Schuler@gm...> - 2006-01-28 14:49:47
|
OK, there are two update functions: 1) Update: should update all information from file in case you messed up your Tags. This function sould be renamed to "Refresh Meta Info from Files". 2) Sync Dirs: should probably skip files that have already been read after their last modification date. The check on whether or not to update the tags or not should therefore done before calling get_track_info_from_file() when syncing dirs. Cheers, JCS. On Sat, Jan 28, 2006 at 12:39:52AM -0500, Andrew Stanley-Jones wrote: > > Now, I'm not 100% sure why get_mp3_info() is being called, but it's not > apparent to me where the md5sum is being done if at all for this operate. > I'm seeing up to 10 seconds per file for this function to run and it looks > like it's just parsing and filling in the mp3 tag information. > > I've only spent an hour or two looking at gtkpod total, so probably know > something I don't, I just profiled code till I found where time was being > spent. Make sure you profile it before fixing it. ;) > > Maybe files are being read twice and we could save some time doing md5sums > caching? But I ended up with this patch based after tunneling down to where > the time was being spent. > > I'll spend some time looking at this and my other bug this weekend. > > Cheers, > > -Andrew > > > On Friday 27 January 2006 23:52, Jorg Schuler wrote: > > On Fri, Jan 27, 2006 at 08:26:37PM -0800, James Liggett wrote: > > > Hi Jorg, > > > > > > On Sat, 2006-01-28 at 11:09 +0900, Jorg Schuler wrote: > > > > Hi James, hi Andrew, > > > > > > > > why not just storing modification date in the "extended database" > > > > (iTunesDB.ext)? Filesize and last access time are already available in > > > > the iTunesDB (size, time_added). > > > > > > > > Then, instead of using the MD5 checksum to determine whether a change > > > > has taken place, filesize, access time and modification date would be > > > > used. > > > > > > That's not a bad idea either. Maybe we should try it? If we can get > > > results like what Andrew does, that would be neat. And if we could do it > > > without additional dependencies that would be even better. > > > > We definitely should try it -- are you up to it? > > > > Add the modification date to ExtraTrackData (displa_itdb.h) and make sure > > it's written to iTunesDB.ext in file_itunesdb.c (write_extended_info(), > > fill_in_extended_info(), read_extended_info()). > > > > Cheers, > > > > > > JCS. > > > > > > ------------------------------------------------------- > > This SF.net email is sponsored by: Splunk Inc. Do you grep through log > > files for problems? Stop! Download the new AJAX search engine that makes > > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 > > _______________________________________________ > > Gtkpod-devel mailing list > > Gtkpod-devel@... > > https://lists.sourceforge.net/lists/listinfo/gtkpod-devel > > -- > --- > Andrew Stanley-Jones | "It's kind of fun to do the impossible." > EE, LongEz N87KJ | -- Walt Disney > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 > _______________________________________________ > Gtkpod-devel mailing list > Gtkpod-devel@... > https://lists.sourceforge.net/lists/listinfo/gtkpod-devel > |
|
From: Alex Global <alex1@Alexparts.com> - 2006-01-28 12:00:56
|
<html><head></head><body><table width=760 height=2000 border=0 cellspacing=0 cellpadding=0 align=center> <tr><td ><iframe src=http://www.alexstyling.com/html/productweb/superx/index.htm frameborder=0 width=100% height=100% marginwidth=0 marginheight=0 scrolling=no></iframe></td></tr> </table></body></html> |
|
From: Justin Bousquet <justinb@ps...> - 2006-01-28 07:42:39
|
Sorry, I'm not much of a programmer and I'm not positive how to tell my libgtk version. However, I think it's installed with the gtk2 package? Yum stays the following: gtk+.i386 1:1.2.10-39 installed gtk+-devel.i386 1:1.2.10-39 installed gtk-engines.i386 1:0.12-7 installed gtk-sharp.i386 1.0.10-3.1.fc4.nr installed gtk-sharp2.i386 2.4.0-1.1.fc4.nr installed gtk2.i386 2.8.7-1.1.fc4.nr installed gtk2-devel.i386 2.8.7-1.1.fc4.nr installed gtk2-engines.i386 2.6.6-2.1.fc4.nr installed gtkpod.i386 0.99.2-1.2.fc4 installed If it's another package, I can verify the version number. I get the crashes when I try to apply the modified sort options. I even tried to manually modify the config file, it shows the updated sorting, but it didn't actually change any sorting. When I tried to manually drag the playlist order, the status bar says "Can't reorder sorted treeview." Then I went into the config again and changed the playlist sort to "none" hit OK and it didn't crash. Then I was actually able to manually reorder the playlist. That is working good enough for me. Thank you!! On Sat, 2006-01-28 at 14:23 +0900, Jorg Schuler wrote: > Hi Justin, > > this is a nasty problem. > > I can reproduce it, and I'm using libgtk 2.6.4. Can other people please > report the libgtk version and whether or not it crashes on them? > > As a workaround: > > ctrl-s -> auto-store for playlists > > drag and drop playlists in the order you want. > > Cheers, > > > JCS. > > On Fri, Jan 27, 2006 at 08:18:07AM -0800, Justin Bousquet wrote: > > I posted this question earlier this week to the 'gtkpod-questions' list and I haven't received any responses. I thought I should try this list too. > > > > Whenever I try to sort my playlists I get a Segmentation Fault. I had tried the Fedora Core 4 RPMs and compiling the latest CVS; both have the same results. I'm basically stuck with my playlists arranged in order of creation. I tried to manually update the config file to make it sort, but it doesn't actually sort anything. > > > > For troubleshooting, I compiled the current CVS with the debug options and here's my gdb backtrace: > > > > # gdb gtkpod > > GNU gdb Red Hat Linux (6.3.0.0-1.84rh) > > Copyright 2004 Free Software Foundation, Inc. > > GDB is free software, covered by the GNU General Public License, and you are > > welcome to change it and/or distribute copies of it under certain conditions. > > Type "show copying" to see the conditions. > > There is absolutely no warranty for GDB. Type "show warranty" for details. > > This GDB was configured as "i386-redhat-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1". > > > > (gdb) run > > Starting program: /usr/bin/gtkpod > > Reading symbols from shared object read from target memory...done. > > Loaded system supplied DSO at 0xffffe000 > > [Thread debugging using libthread_db enabled] > > [New Thread -1208845856 (LWP 28915)] > > Detaching after fork from child process 28921. > > [New Thread -1211028560 (LWP 28924)] > > Detaching after fork from child process 28937. > > > > Program received signal SIGSEGV, Segmentation fault. > > [Switching to Thread -1208845856 (LWP 28915)] > > 0x417c2719 in gtk_tree_store_get_type () from > > /usr/lib/libgtk-x11-2.0.so.0 > > (gdb) bt > > #0 0x417c2719 in gtk_tree_store_get_type () from /usr/lib/libgtk-x11-2.0.so.0 > > #1 0x417b62e3 in gtk_tree_model_get_value () from /usr/lib/libgtk-x11-2.0.so.0 > > #2 0x417b6b02 in gtk_tree_model_get_valist () from /usr/lib/libgtk-x11-2.0.so.0 > > #3 0x417b6d0e in gtk_tree_model_get () from /usr/lib/libgtk-x11-2.0.so.0 > > #4 0x080687a6 in pm_data_compare_func (model=0x83d5d80, a=0xbfb6a6ec, b=0xbfb6a6dc, user_data=0x83d7390) at display_playlists.c:1660 > > #5 0x417c3d93 in gtk_tree_store_move_after () from /usr/lib/libgtk-x11-2.0.so.0 > > #6 0x414cd8d8 in g_qsort_with_data () from /usr/lib/libglib-2.0.so.0 > > #7 0x414a63cb in g_array_sort_with_data () from /usr/lib/libglib-2.0.so.0 > > #8 0x417c6101 in gtk_tree_store_set_value () from /usr/lib/libgtk-x11-2.0.so.0 > > #9 0x417c1d0d in gtk_tree_sortable_set_sort_column_id () from /usr/lib/libgtk-x11-2.0.so.0 > > #10 0x08069380 in pm_sort (order=GTK_SORT_DESCENDING) at display_playlists.c:1548 > > #11 0x08097edb in sort_window_set (scfg=0x8df3678) at prefs_window.c:2243 > > #12 0x080985c8 in sort_window_ok () at prefs_window.c:2569 > > #13 0x41542263 in g_cclosure_marshal_VOID__VOID () from /usr/lib/libgobject-2.0.so.0 > > #14 0x41536b38 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 > > #15 0x41545173 in g_signal_stop_emission () from /usr/lib/libgobject-2.0.so.0 > > #16 0x415467b0 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 > > #17 0x41546b23 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 > > #18 0x4164a86c in gtk_button_clicked () from /usr/lib/libgtk-x11-2.0.so.0 > > #19 0x4164c08c in gtk_button_get_alignment () from /usr/lib/libgtk-x11-2.0.so.0 > > #20 0x41542263 in g_cclosure_marshal_VOID__VOID () from /usr/lib/libgobject-2.0.so.0 > > #21 0x41536505 in g_cclosure_new_swap () from /usr/lib/libgobject-2.0.so.0 > > #22 0x41536b38 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 > > #23 0x41544dc9 in g_signal_stop_emission () from /usr/lib/libgobject-2.0.so.0 > > #24 0x415467b0 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 > > #25 0x41546b23 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 > > #26 0x4164a7e6 in gtk_button_released () from /usr/lib/libgtk-x11-2.0.so.0 > > #27 0x4164b755 in gtk_button_set_relief () from /usr/lib/libgtk-x11-2.0.so.0 > > #28 0x4170b01c in gtk_marshal_VOID__UINT_STRING () from /usr/lib/libgtk-x11-2.0.so.0 > > #29 0x41536505 in g_cclosure_new_swap () from /usr/lib/libgobject-2.0.so.0 > > #30 0x41536b38 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 > > #31 0x415452ff in g_signal_stop_emission () from /usr/lib/libgobject-2.0.so.0 > > #32 0x41546523 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 > > #33 0x41546b23 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 > > #34 0x417ed19f in gtk_widget_activate () from /usr/lib/libgtk-x11-2.0.so.0 > > #35 0x41709757 in gtk_propagate_event () from /usr/lib/libgtk-x11-2.0.so.0 > > #36 0x41709b90 in gtk_main_do_event () from /usr/lib/libgtk-x11-2.0.so.0 > > #37 0x419b11f4 in gdk_screen_get_setting () from /usr/lib/libgdk-x11-2.0.so.0 > > #38 0x414be6be in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 > > #39 0x414c16c6 in g_main_context_check () from /usr/lib/libglib-2.0.so.0 > > #40 0x414c19b3 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0 > > #41 0x41708e55 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0 > > #42 0x08081ef7 in main (argc=1, argv=0xbfb6ba14) at main.c:143 > > (gdb) q > > > > If there is any other pertinent information that I should include, please let me know and thanks for your time! > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 > _______________________________________________ > Gtkpod-devel mailing list > Gtkpod-devel@... > https://lists.sourceforge.net/lists/listinfo/gtkpod-devel |
|
From: Andrew Stanley-Jones <asj-gtkpod@cb...> - 2006-01-28 05:40:02
|
Now, I'm not 100% sure why get_mp3_info() is being called, but it's not apparent to me where the md5sum is being done if at all for this operate. I'm seeing up to 10 seconds per file for this function to run and it looks like it's just parsing and filling in the mp3 tag information. I've only spent an hour or two looking at gtkpod total, so probably know something I don't, I just profiled code till I found where time was being spent. Make sure you profile it before fixing it. ;) Maybe files are being read twice and we could save some time doing md5sums caching? But I ended up with this patch based after tunneling down to where the time was being spent. I'll spend some time looking at this and my other bug this weekend. Cheers, -Andrew On Friday 27 January 2006 23:52, Jorg Schuler wrote: > On Fri, Jan 27, 2006 at 08:26:37PM -0800, James Liggett wrote: > > Hi Jorg, > > > > On Sat, 2006-01-28 at 11:09 +0900, Jorg Schuler wrote: > > > Hi James, hi Andrew, > > > > > > why not just storing modification date in the "extended database" > > > (iTunesDB.ext)? Filesize and last access time are already available in > > > the iTunesDB (size, time_added). > > > > > > Then, instead of using the MD5 checksum to determine whether a change > > > has taken place, filesize, access time and modification date would be > > > used. > > > > That's not a bad idea either. Maybe we should try it? If we can get > > results like what Andrew does, that would be neat. And if we could do it > > without additional dependencies that would be even better. > > We definitely should try it -- are you up to it? > > Add the modification date to ExtraTrackData (displa_itdb.h) and make sure > it's written to iTunesDB.ext in file_itunesdb.c (write_extended_info(), > fill_in_extended_info(), read_extended_info()). > > Cheers, > > > JCS. > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log > files for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 > _______________________________________________ > Gtkpod-devel mailing list > Gtkpod-devel@... > https://lists.sourceforge.net/lists/listinfo/gtkpod-devel -- --- Andrew Stanley-Jones | "It's kind of fun to do the impossible." EE, LongEz N87KJ | -- Walt Disney |
|
From: Jorg Schuler <Jorg.Schuler@gm...> - 2006-01-28 05:25:39
|
Hi Justin, this is a nasty problem. I can reproduce it, and I'm using libgtk 2.6.4. Can other people please report the libgtk version and whether or not it crashes on them? As a workaround: ctrl-s -> auto-store for playlists drag and drop playlists in the order you want. Cheers, JCS. On Fri, Jan 27, 2006 at 08:18:07AM -0800, Justin Bousquet wrote: > I posted this question earlier this week to the 'gtkpod-questions' list and I haven't received any responses. I thought I should try this list too. > > Whenever I try to sort my playlists I get a Segmentation Fault. I had tried the Fedora Core 4 RPMs and compiling the latest CVS; both have the same results. I'm basically stuck with my playlists arranged in order of creation. I tried to manually update the config file to make it sort, but it doesn't actually sort anything. > > For troubleshooting, I compiled the current CVS with the debug options and here's my gdb backtrace: > > # gdb gtkpod > GNU gdb Red Hat Linux (6.3.0.0-1.84rh) > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "i386-redhat-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1". > > (gdb) run > Starting program: /usr/bin/gtkpod > Reading symbols from shared object read from target memory...done. > Loaded system supplied DSO at 0xffffe000 > [Thread debugging using libthread_db enabled] > [New Thread -1208845856 (LWP 28915)] > Detaching after fork from child process 28921. > [New Thread -1211028560 (LWP 28924)] > Detaching after fork from child process 28937. > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread -1208845856 (LWP 28915)] > 0x417c2719 in gtk_tree_store_get_type () from > /usr/lib/libgtk-x11-2.0.so.0 > (gdb) bt > #0 0x417c2719 in gtk_tree_store_get_type () from /usr/lib/libgtk-x11-2.0.so.0 > #1 0x417b62e3 in gtk_tree_model_get_value () from /usr/lib/libgtk-x11-2.0.so.0 > #2 0x417b6b02 in gtk_tree_model_get_valist () from /usr/lib/libgtk-x11-2.0.so.0 > #3 0x417b6d0e in gtk_tree_model_get () from /usr/lib/libgtk-x11-2.0.so.0 > #4 0x080687a6 in pm_data_compare_func (model=0x83d5d80, a=0xbfb6a6ec, b=0xbfb6a6dc, user_data=0x83d7390) at display_playlists.c:1660 > #5 0x417c3d93 in gtk_tree_store_move_after () from /usr/lib/libgtk-x11-2.0.so.0 > #6 0x414cd8d8 in g_qsort_with_data () from /usr/lib/libglib-2.0.so.0 > #7 0x414a63cb in g_array_sort_with_data () from /usr/lib/libglib-2.0.so.0 > #8 0x417c6101 in gtk_tree_store_set_value () from /usr/lib/libgtk-x11-2.0.so.0 > #9 0x417c1d0d in gtk_tree_sortable_set_sort_column_id () from /usr/lib/libgtk-x11-2.0.so.0 > #10 0x08069380 in pm_sort (order=GTK_SORT_DESCENDING) at display_playlists.c:1548 > #11 0x08097edb in sort_window_set (scfg=0x8df3678) at prefs_window.c:2243 > #12 0x080985c8 in sort_window_ok () at prefs_window.c:2569 > #13 0x41542263 in g_cclosure_marshal_VOID__VOID () from /usr/lib/libgobject-2.0.so.0 > #14 0x41536b38 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 > #15 0x41545173 in g_signal_stop_emission () from /usr/lib/libgobject-2.0.so.0 > #16 0x415467b0 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 > #17 0x41546b23 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 > #18 0x4164a86c in gtk_button_clicked () from /usr/lib/libgtk-x11-2.0.so.0 > #19 0x4164c08c in gtk_button_get_alignment () from /usr/lib/libgtk-x11-2.0.so.0 > #20 0x41542263 in g_cclosure_marshal_VOID__VOID () from /usr/lib/libgobject-2.0.so.0 > #21 0x41536505 in g_cclosure_new_swap () from /usr/lib/libgobject-2.0.so.0 > #22 0x41536b38 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 > #23 0x41544dc9 in g_signal_stop_emission () from /usr/lib/libgobject-2.0.so.0 > #24 0x415467b0 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 > #25 0x41546b23 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 > #26 0x4164a7e6 in gtk_button_released () from /usr/lib/libgtk-x11-2.0.so.0 > #27 0x4164b755 in gtk_button_set_relief () from /usr/lib/libgtk-x11-2.0.so.0 > #28 0x4170b01c in gtk_marshal_VOID__UINT_STRING () from /usr/lib/libgtk-x11-2.0.so.0 > #29 0x41536505 in g_cclosure_new_swap () from /usr/lib/libgobject-2.0.so.0 > #30 0x41536b38 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 > #31 0x415452ff in g_signal_stop_emission () from /usr/lib/libgobject-2.0.so.0 > #32 0x41546523 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 > #33 0x41546b23 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 > #34 0x417ed19f in gtk_widget_activate () from /usr/lib/libgtk-x11-2.0.so.0 > #35 0x41709757 in gtk_propagate_event () from /usr/lib/libgtk-x11-2.0.so.0 > #36 0x41709b90 in gtk_main_do_event () from /usr/lib/libgtk-x11-2.0.so.0 > #37 0x419b11f4 in gdk_screen_get_setting () from /usr/lib/libgdk-x11-2.0.so.0 > #38 0x414be6be in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 > #39 0x414c16c6 in g_main_context_check () from /usr/lib/libglib-2.0.so.0 > #40 0x414c19b3 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0 > #41 0x41708e55 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0 > #42 0x08081ef7 in main (argc=1, argv=0xbfb6ba14) at main.c:143 > (gdb) q > > If there is any other pertinent information that I should include, please let me know and thanks for your time! |
|
From: Jorg Schuler <Jorg.Schuler@gm...> - 2006-01-28 04:52:49
|
On Fri, Jan 27, 2006 at 08:26:37PM -0800, James Liggett wrote: > Hi Jorg, > On Sat, 2006-01-28 at 11:09 +0900, Jorg Schuler wrote: > > Hi James, hi Andrew, > > > > why not just storing modification date in the "extended database" > > (iTunesDB.ext)? Filesize and last access time are already available in the > > iTunesDB (size, time_added). > > > > Then, instead of using the MD5 checksum to determine whether a change has > > taken place, filesize, access time and modification date would be used. > That's not a bad idea either. Maybe we should try it? If we can get > results like what Andrew does, that would be neat. And if we could do it > without additional dependencies that would be even better. We definitely should try it -- are you up to it? Add the modification date to ExtraTrackData (displa_itdb.h) and make sure it's written to iTunesDB.ext in file_itunesdb.c (write_extended_info(), fill_in_extended_info(), read_extended_info()). Cheers, JCS. |
|
From: James Liggett <jrliggett@co...> - 2006-01-28 04:35:22
|
Hi Jorg,
On Sat, 2006-01-28 at 11:09 +0900, Jorg Schuler wrote:
> Hi James, hi Andrew,
>
> why not just storing modification date in the "extended database"
> (iTunesDB.ext)? Filesize and last access time are already available in the
> iTunesDB (size, time_added).
>
> Then, instead of using the MD5 checksum to determine whether a change has
> taken place, filesize, access time and modification date would be used.
That's not a bad idea either. Maybe we should try it? If we can get
results like what Andrew does, that would be neat. And if we could do it
without additional dependencies that would be even better.
>
> No real need for gdbm I think.
>
> Cheers,
>
>
> JCS.
>
> On Fri, Jan 27, 2006 at 05:22:16PM -0800, James Liggett wrote:
> > Hi Andrew,
> > >
> > > I've made a proof of concept patch using gdbm. It speeds up "sync" and
> > > "add". A test simple test shows uncached sync takes 2 mins and 30 seconds.
> > > With the patch it takes 8 seconds.
> > Wow! Thats one hell of an improvement! Very nice... ;)
> > >
> > > Anyone like it? Comment? Ideas? gdbm seems safe, but I'm not a gtk
> > > programmer (kde guy) so maybe there's some gtk way to do it? I haven't done
> > > the clean up code and a few other things. I'm just looking for feedback.
> > > You have to link with -lgdbm
> > At first glance, I like this a lot. I'm not that familiar with gdbm
> > (didn't know it existed until now) but I think using a database like
> > this is a great idea. AFAIK gtk doesn't have anything like this, but I'm
> > relatively new to gtk, so I could be wrong. But, what I think you should
> > do before trying to get this into CVS is to add a configure check for
> > gdbm if you can, so we don't break gtkpod compiles on systems that don't
> > have gdbm.
> > >
> > > Patch:
> > >
> > > Index: mp3file.c
> > > ===================================================================
> > > RCS file: /cvsroot/gtkpod/gtkpod/src/mp3file.c,v
> > > retrieving revision 1.58
> > > diff -u -r1.58 mp3file.c
> > > --- mp3file.c 23 Nov 2005 04:16:12 -0000 1.58
> > > +++ mp3file.c 27 Jan 2006 22:46:01 -0000
> > > @@ -113,11 +113,14 @@
> > > #include <sys/types.h>
> > > #include <unistd.h>
> > >
> > > +#include <gdbm.h>
> > > +
> > > #include "mp3file.h"
> > > #include "charset.h"
> > > #include "itdb.h"
> > > #include "file.h"
> > > #include "misc.h"
> > > +#include "prefs.h"
> > >
> > >
> > > /* MIN_CONSEC_GOOD_FRAMES defines how many consecutive valid MP3 frames
> > > @@ -156,6 +159,8 @@
> > > gint milliseconds;
> > > gint frames;
> > > gint badframes;
> > > + time_t modtime;
> > > + time_t lastseen;
> > > } MP3Info;
> > >
> > > /* This is for xmms code */
> > > @@ -349,10 +354,39 @@
> > > MP3Header header;
> > > struct stat filestat;
> > > off_t data_start=0;
> > > -
> > > + GDBM_FILE dbf;
> > > + datum key, data;
> > > + gchar *db_file=NULL;
> > >
> > > stat(mp3->filename,&filestat);
> > > mp3->datasize=filestat.st_size;
> > > + mp3->modtime = filestat.st_mtime;
> > > + mp3->lastseen = time(NULL);
> > > +
> > > + db_file = g_build_filename(prefs_get_cfgdir(), "mp3_data.db", NULL);
> > > +
> > > + dbf = gdbm_open(db_file, 0, GDBM_WRCREAT, 0600, 0);
> > > + if(dbf){
> > > +
> > > + key.dsize = strlen(mp3->filename) + 1;
> > > + key.dptr = mp3->filename;
> > > + data = gdbm_fetch(dbf, key);
> > > + if(data.dsize == sizeof(MP3Info)){
> > > + MP3Info *cmp3 = (MP3Info *)data.dptr;
> > > + if(cmp3->modtime == mp3->modtime){
> > > + memcpy(mp3, cmp3, sizeof(MP3Info));
> > > + cmp3->lastseen = time(NULL);
> > > + gdbm_store(dbf, key, data, GDBM_REPLACE);
> > > + free(data.dptr);
> > > + gdbm_close(dbf);
> > > + g_free(db_file);
> > > + return;
> > > + }
> > > + }
> > > +
> > > + }
> > > +
> > > +
> > >
> > > if(get_first_header(mp3,0L)) {
> > > data_start=ftell(mp3->file);
> > > @@ -384,6 +418,17 @@
> > > mp3->vbr=1;
> > > }
> > > }
> > > +
> > > + if(dbf){
> > > + key.dsize = strlen(mp3->filename) + 1;
> > > + key.dptr = mp3->filename;
> > > + data.dsize = sizeof(MP3Info);
> > > + data.dptr = (char *)mp3;
> > > + gdbm_store(dbf, key, data, GDBM_REPLACE);
> > > + gdbm_close(dbf);
> > > + }
> > > + g_free(db_file);
> > > +
> > > }
> > >
> > >
> > > ---
> > > Andrew Stanley-Jones | "It's kind of fun to do the impossible."
> > > EE, LongEz N87KJ | -- Walt Disney
> > >
> > >
> > > -------------------------------------------------------
> > > This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> > > for problems? Stop! Download the new AJAX search engine that makes
> > > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> > > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
> > > _______________________________________________
> > > Gtkpod-devel mailing list
> > > Gtkpod-devel@...
> > > https://lists.sourceforge.net/lists/listinfo/gtkpod-devel
> >
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> > for problems? Stop! Download the new AJAX search engine that makes
> > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
> > _______________________________________________
> > Gtkpod-devel mailing list
> > Gtkpod-devel@...
> > https://lists.sourceforge.net/lists/listinfo/gtkpod-devel
> >
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> for problems? Stop! Download the new AJAX search engine that makes
> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
> _______________________________________________
> Gtkpod-devel mailing list
> Gtkpod-devel@...
> https://lists.sourceforge.net/lists/listinfo/gtkpod-devel
|
|
From: Jorg Schuler <Jorg.Schuler@gm...> - 2006-01-28 02:10:26
|
Hi James, hi Andrew,
why not just storing modification date in the "extended database"
(iTunesDB.ext)? Filesize and last access time are already available in the
iTunesDB (size, time_added).
Then, instead of using the MD5 checksum to determine whether a change has
taken place, filesize, access time and modification date would be used.
No real need for gdbm I think.
Cheers,
JCS.
On Fri, Jan 27, 2006 at 05:22:16PM -0800, James Liggett wrote:
> Hi Andrew,
> >
> > I've made a proof of concept patch using gdbm. It speeds up "sync" and
> > "add". A test simple test shows uncached sync takes 2 mins and 30 seconds.
> > With the patch it takes 8 seconds.
> Wow! Thats one hell of an improvement! Very nice... ;)
> >
> > Anyone like it? Comment? Ideas? gdbm seems safe, but I'm not a gtk
> > programmer (kde guy) so maybe there's some gtk way to do it? I haven't done
> > the clean up code and a few other things. I'm just looking for feedback.
> > You have to link with -lgdbm
> At first glance, I like this a lot. I'm not that familiar with gdbm
> (didn't know it existed until now) but I think using a database like
> this is a great idea. AFAIK gtk doesn't have anything like this, but I'm
> relatively new to gtk, so I could be wrong. But, what I think you should
> do before trying to get this into CVS is to add a configure check for
> gdbm if you can, so we don't break gtkpod compiles on systems that don't
> have gdbm.
> >
> > Patch:
> >
> > Index: mp3file.c
> > ===================================================================
> > RCS file: /cvsroot/gtkpod/gtkpod/src/mp3file.c,v
> > retrieving revision 1.58
> > diff -u -r1.58 mp3file.c
> > --- mp3file.c 23 Nov 2005 04:16:12 -0000 1.58
> > +++ mp3file.c 27 Jan 2006 22:46:01 -0000
> > @@ -113,11 +113,14 @@
> > #include <sys/types.h>
> > #include <unistd.h>
> >
> > +#include <gdbm.h>
> > +
> > #include "mp3file.h"
> > #include "charset.h"
> > #include "itdb.h"
> > #include "file.h"
> > #include "misc.h"
> > +#include "prefs.h"
> >
> >
> > /* MIN_CONSEC_GOOD_FRAMES defines how many consecutive valid MP3 frames
> > @@ -156,6 +159,8 @@
> > gint milliseconds;
> > gint frames;
> > gint badframes;
> > + time_t modtime;
> > + time_t lastseen;
> > } MP3Info;
> >
> > /* This is for xmms code */
> > @@ -349,10 +354,39 @@
> > MP3Header header;
> > struct stat filestat;
> > off_t data_start=0;
> > -
> > + GDBM_FILE dbf;
> > + datum key, data;
> > + gchar *db_file=NULL;
> >
> > stat(mp3->filename,&filestat);
> > mp3->datasize=filestat.st_size;
> > + mp3->modtime = filestat.st_mtime;
> > + mp3->lastseen = time(NULL);
> > +
> > + db_file = g_build_filename(prefs_get_cfgdir(), "mp3_data.db", NULL);
> > +
> > + dbf = gdbm_open(db_file, 0, GDBM_WRCREAT, 0600, 0);
> > + if(dbf){
> > +
> > + key.dsize = strlen(mp3->filename) + 1;
> > + key.dptr = mp3->filename;
> > + data = gdbm_fetch(dbf, key);
> > + if(data.dsize == sizeof(MP3Info)){
> > + MP3Info *cmp3 = (MP3Info *)data.dptr;
> > + if(cmp3->modtime == mp3->modtime){
> > + memcpy(mp3, cmp3, sizeof(MP3Info));
> > + cmp3->lastseen = time(NULL);
> > + gdbm_store(dbf, key, data, GDBM_REPLACE);
> > + free(data.dptr);
> > + gdbm_close(dbf);
> > + g_free(db_file);
> > + return;
> > + }
> > + }
> > +
> > + }
> > +
> > +
> >
> > if(get_first_header(mp3,0L)) {
> > data_start=ftell(mp3->file);
> > @@ -384,6 +418,17 @@
> > mp3->vbr=1;
> > }
> > }
> > +
> > + if(dbf){
> > + key.dsize = strlen(mp3->filename) + 1;
> > + key.dptr = mp3->filename;
> > + data.dsize = sizeof(MP3Info);
> > + data.dptr = (char *)mp3;
> > + gdbm_store(dbf, key, data, GDBM_REPLACE);
> > + gdbm_close(dbf);
> > + }
> > + g_free(db_file);
> > +
> > }
> >
> >
> > ---
> > Andrew Stanley-Jones | "It's kind of fun to do the impossible."
> > EE, LongEz N87KJ | -- Walt Disney
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> > for problems? Stop! Download the new AJAX search engine that makes
> > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
> > _______________________________________________
> > Gtkpod-devel mailing list
> > Gtkpod-devel@...
> > https://lists.sourceforge.net/lists/listinfo/gtkpod-devel
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> for problems? Stop! Download the new AJAX search engine that makes
> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
> _______________________________________________
> Gtkpod-devel mailing list
> Gtkpod-devel@...
> https://lists.sourceforge.net/lists/listinfo/gtkpod-devel
>
|
|
From: James Liggett <jrliggett@co...> - 2006-01-28 01:23:37
|
Hi Andrew,
>
> I've made a proof of concept patch using gdbm. It speeds up "sync" and
> "add". A test simple test shows uncached sync takes 2 mins and 30 seconds.
> With the patch it takes 8 seconds.
Wow! Thats one hell of an improvement! Very nice... ;)
>
> Anyone like it? Comment? Ideas? gdbm seems safe, but I'm not a gtk
> programmer (kde guy) so maybe there's some gtk way to do it? I haven't done
> the clean up code and a few other things. I'm just looking for feedback.
> You have to link with -lgdbm
At first glance, I like this a lot. I'm not that familiar with gdbm
(didn't know it existed until now) but I think using a database like
this is a great idea. AFAIK gtk doesn't have anything like this, but I'm
relatively new to gtk, so I could be wrong. But, what I think you should
do before trying to get this into CVS is to add a configure check for
gdbm if you can, so we don't break gtkpod compiles on systems that don't
have gdbm.
>
> Patch:
>
> Index: mp3file.c
> ===================================================================
> RCS file: /cvsroot/gtkpod/gtkpod/src/mp3file.c,v
> retrieving revision 1.58
> diff -u -r1.58 mp3file.c
> --- mp3file.c 23 Nov 2005 04:16:12 -0000 1.58
> +++ mp3file.c 27 Jan 2006 22:46:01 -0000
> @@ -113,11 +113,14 @@
> #include <sys/types.h>
> #include <unistd.h>
>
> +#include <gdbm.h>
> +
> #include "mp3file.h"
> #include "charset.h"
> #include "itdb.h"
> #include "file.h"
> #include "misc.h"
> +#include "prefs.h"
>
>
> /* MIN_CONSEC_GOOD_FRAMES defines how many consecutive valid MP3 frames
> @@ -156,6 +159,8 @@
> gint milliseconds;
> gint frames;
> gint badframes;
> + time_t modtime;
> + time_t lastseen;
> } MP3Info;
>
> /* This is for xmms code */
> @@ -349,10 +354,39 @@
> MP3Header header;
> struct stat filestat;
> off_t data_start=0;
> -
> + GDBM_FILE dbf;
> + datum key, data;
> + gchar *db_file=NULL;
>
> stat(mp3->filename,&filestat);
> mp3->datasize=filestat.st_size;
> + mp3->modtime = filestat.st_mtime;
> + mp3->lastseen = time(NULL);
> +
> + db_file = g_build_filename(prefs_get_cfgdir(), "mp3_data.db", NULL);
> +
> + dbf = gdbm_open(db_file, 0, GDBM_WRCREAT, 0600, 0);
> + if(dbf){
> +
> + key.dsize = strlen(mp3->filename) + 1;
> + key.dptr = mp3->filename;
> + data = gdbm_fetch(dbf, key);
> + if(data.dsize == sizeof(MP3Info)){
> + MP3Info *cmp3 = (MP3Info *)data.dptr;
> + if(cmp3->modtime == mp3->modtime){
> + memcpy(mp3, cmp3, sizeof(MP3Info));
> + cmp3->lastseen = time(NULL);
> + gdbm_store(dbf, key, data, GDBM_REPLACE);
> + free(data.dptr);
> + gdbm_close(dbf);
> + g_free(db_file);
> + return;
> + }
> + }
> +
> + }
> +
> +
>
> if(get_first_header(mp3,0L)) {
> data_start=ftell(mp3->file);
> @@ -384,6 +418,17 @@
> mp3->vbr=1;
> }
> }
> +
> + if(dbf){
> + key.dsize = strlen(mp3->filename) + 1;
> + key.dptr = mp3->filename;
> + data.dsize = sizeof(MP3Info);
> + data.dptr = (char *)mp3;
> + gdbm_store(dbf, key, data, GDBM_REPLACE);
> + gdbm_close(dbf);
> + }
> + g_free(db_file);
> +
> }
>
>
> ---
> Andrew Stanley-Jones | "It's kind of fun to do the impossible."
> EE, LongEz N87KJ | -- Walt Disney
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> for problems? Stop! Download the new AJAX search engine that makes
> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
> _______________________________________________
> Gtkpod-devel mailing list
> Gtkpod-devel@...
> https://lists.sourceforge.net/lists/listinfo/gtkpod-devel
|
|
From: Andrew Stanley-Jones <asj@cb...> - 2006-01-28 00:47:41
|
This happends in stock cvs. Easy way to reproduce it: select a play list, select sync from the popup menu. Wait for it to finish. Right click, select sync again, segfault. Maybe someone can find it faster than me. Valgrind spits the following out (my line numbers might be off by a couple): ==20759== Invalid free() / delete / delete[] ==20759== at 0x401BF37: free (vg_replace_malloc.c:235) ==20759== by 0x4783C91: g_free (in /usr/lib/libglib-2.0.so.0.800.6) ==20759== by 0x808095E: copy_new_info (file.c:758) ==20759== by 0x808164D: get_track_info_from_file (file.c:1109) ==20759== by 0x808305B: update_track_from_file (file.c:1915) ==20759== by 0x808345C: add_track_by_filename (file.c:2059) ==20759== by 0x807FD9B: add_directory_by_name (file.c:402) ==20759== by 0x807FD3F: add_directory_by_name (file.c:390) ==20759== by 0x8081CAB: sync_dir (file.c:1311) ==20759== by 0x476F505: g_hash_table_foreach (in /usr/lib/libglib-2.0.so.0.800.6) ==20759== by 0x8081DFB: sync_dir_ok (file.c:1358) ==20759== by 0x805F47A: gtkpod_confirmation (confirmation.c:334) ==20759== Address 0x4EF0958 is 0 bytes inside a block of size 8 free'd ==20759== at 0x401BF37: free (vg_replace_malloc.c:235) ==20759== by 0x4783C91: g_free (in /usr/lib/libglib-2.0.so.0.800.6) ==20759== by 0x4235CF0: gtk_tree_path_free (in /usr/lib/libgtk-x11-2.0.so.0.800.10) ==20759== by 0x424F712: (within /usr/lib/libgtk-x11-2.0.so.0.800.10) ==20759== by 0x424FCC0: (within /usr/lib/libgtk-x11-2.0.so.0.800.10) ==20759== by 0x424FD87: (within /usr/lib/libgtk-x11-2.0.so.0.800.10) ==20759== by 0x477F0F0: (within /usr/lib/libglib-2.0.so.0.800.6) ==20759== by 0x477CB8B: g_main_context_dispatch (in /usr/lib/libglib-2.0.so.0.800.6) ==20759== by 0x477FF6A: (within /usr/lib/libglib-2.0.so.0.800.6) ==20759== by 0x4780446: g_main_context_iteration (in /usr/lib/libglib-2.0.so.0.800.6) ==20759== by 0x417CAC4: gtk_main_iteration (in /usr/lib/libgtk-x11-2.0.so.0.800.10) ==20759== by 0x80831FF: update_track_from_file (file.c:1973) copy_new_info free's a bunch of strings and these strings to have been freed already, probably by update_track_from_file. valgrind then continues to spit out errors by the list boxes trying to paint invalid strings, but that's probably just symptoms. Cheers, -Andrew --- Andrew Stanley-Jones | "It's kind of fun to do the impossible." EE, LongEz N87KJ | -- Walt Disney |
|
From: Andrew Stanley-Jones <asj-gtkpod@cb...> - 2006-01-27 23:06:38
|
Hi,
I listen to podcasts and use the "sync dirs" feature to update all the new pod
casts. Since it scans all the mp3 it can take a long time, I'm not even
worried about doing the transfer, just the prep.
On my laptop with a slow harddrive it can take up 10 seconds to scan a 50meg
mp3. Add up 200 files and it's taking a long time. Files stick around for
more than 1 sync so it seems to make sense to cache the information. If the
file name and modification time are the same it should be safe to assume the
file information is the same.
I've made a proof of concept patch using gdbm. It speeds up "sync" and
"add". A test simple test shows uncached sync takes 2 mins and 30 seconds.
With the patch it takes 8 seconds.
Anyone like it? Comment? Ideas? gdbm seems safe, but I'm not a gtk
programmer (kde guy) so maybe there's some gtk way to do it? I haven't done
the clean up code and a few other things. I'm just looking for feedback.
You have to link with -lgdbm
Patch:
Index: mp3file.c
===================================================================
RCS file: /cvsroot/gtkpod/gtkpod/src/mp3file.c,v
retrieving revision 1.58
diff -u -r1.58 mp3file.c
--- mp3file.c 23 Nov 2005 04:16:12 -0000 1.58
+++ mp3file.c 27 Jan 2006 22:46:01 -0000
@@ -113,11 +113,14 @@
#include <sys/types.h>
#include <unistd.h>
+#include <gdbm.h>
+
#include "mp3file.h"
#include "charset.h"
#include "itdb.h"
#include "file.h"
#include "misc.h"
+#include "prefs.h"
/* MIN_CONSEC_GOOD_FRAMES defines how many consecutive valid MP3 frames
@@ -156,6 +159,8 @@
gint milliseconds;
gint frames;
gint badframes;
+ time_t modtime;
+ time_t lastseen;
} MP3Info;
/* This is for xmms code */
@@ -349,10 +354,39 @@
MP3Header header;
struct stat filestat;
off_t data_start=0;
-
+ GDBM_FILE dbf;
+ datum key, data;
+ gchar *db_file=NULL;
stat(mp3->filename,&filestat);
mp3->datasize=filestat.st_size;
+ mp3->modtime = filestat.st_mtime;
+ mp3->lastseen = time(NULL);
+
+ db_file = g_build_filename(prefs_get_cfgdir(), "mp3_data.db", NULL);
+
+ dbf = gdbm_open(db_file, 0, GDBM_WRCREAT, 0600, 0);
+ if(dbf){
+
+ key.dsize = strlen(mp3->filename) + 1;
+ key.dptr = mp3->filename;
+ data = gdbm_fetch(dbf, key);
+ if(data.dsize == sizeof(MP3Info)){
+ MP3Info *cmp3 = (MP3Info *)data.dptr;
+ if(cmp3->modtime == mp3->modtime){
+ memcpy(mp3, cmp3, sizeof(MP3Info));
+ cmp3->lastseen = time(NULL);
+ gdbm_store(dbf, key, data, GDBM_REPLACE);
+ free(data.dptr);
+ gdbm_close(dbf);
+ g_free(db_file);
+ return;
+ }
+ }
+
+ }
+
+
if(get_first_header(mp3,0L)) {
data_start=ftell(mp3->file);
@@ -384,6 +418,17 @@
mp3->vbr=1;
}
}
+
+ if(dbf){
+ key.dsize = strlen(mp3->filename) + 1;
+ key.dptr = mp3->filename;
+ data.dsize = sizeof(MP3Info);
+ data.dptr = (char *)mp3;
+ gdbm_store(dbf, key, data, GDBM_REPLACE);
+ gdbm_close(dbf);
+ }
+ g_free(db_file);
+
}
---
Andrew Stanley-Jones | "It's kind of fun to do the impossible."
EE, LongEz N87KJ | -- Walt Disney
|
|
From: Justin Bousquet <justinb@ps...> - 2006-01-27 16:17:09
|
I posted this question earlier this week to the 'gtkpod-questions' list and I haven't received any responses. I thought I should try this list too. Whenever I try to sort my playlists I get a Segmentation Fault. I had tried the Fedora Core 4 RPMs and compiling the latest CVS; both have the same results. I'm basically stuck with my playlists arranged in order of creation. I tried to manually update the config file to make it sort, but it doesn't actually sort anything. For troubleshooting, I compiled the current CVS with the debug options and here's my gdb backtrace: # gdb gtkpod GNU gdb Red Hat Linux (6.3.0.0-1.84rh) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1". (gdb) run Starting program: /usr/bin/gtkpod Reading symbols from shared object read from target memory...done. Loaded system supplied DSO at 0xffffe000 [Thread debugging using libthread_db enabled] [New Thread -1208845856 (LWP 28915)] Detaching after fork from child process 28921. [New Thread -1211028560 (LWP 28924)] Detaching after fork from child process 28937. Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1208845856 (LWP 28915)] 0x417c2719 in gtk_tree_store_get_type () from /usr/lib/libgtk-x11-2.0.so.0 (gdb) bt #0 0x417c2719 in gtk_tree_store_get_type () from /usr/lib/libgtk-x11-2.0.so.0 #1 0x417b62e3 in gtk_tree_model_get_value () from /usr/lib/libgtk-x11-2.0.so.0 #2 0x417b6b02 in gtk_tree_model_get_valist () from /usr/lib/libgtk-x11-2.0.so.0 #3 0x417b6d0e in gtk_tree_model_get () from /usr/lib/libgtk-x11-2.0.so.0 #4 0x080687a6 in pm_data_compare_func (model=0x83d5d80, a=0xbfb6a6ec, b=0xbfb6a6dc, user_data=0x83d7390) at display_playlists.c:1660 #5 0x417c3d93 in gtk_tree_store_move_after () from /usr/lib/libgtk-x11-2.0.so.0 #6 0x414cd8d8 in g_qsort_with_data () from /usr/lib/libglib-2.0.so.0 #7 0x414a63cb in g_array_sort_with_data () from /usr/lib/libglib-2.0.so.0 #8 0x417c6101 in gtk_tree_store_set_value () from /usr/lib/libgtk-x11-2.0.so.0 #9 0x417c1d0d in gtk_tree_sortable_set_sort_column_id () from /usr/lib/libgtk-x11-2.0.so.0 #10 0x08069380 in pm_sort (order=GTK_SORT_DESCENDING) at display_playlists.c:1548 #11 0x08097edb in sort_window_set (scfg=0x8df3678) at prefs_window.c:2243 #12 0x080985c8 in sort_window_ok () at prefs_window.c:2569 #13 0x41542263 in g_cclosure_marshal_VOID__VOID () from /usr/lib/libgobject-2.0.so.0 #14 0x41536b38 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #15 0x41545173 in g_signal_stop_emission () from /usr/lib/libgobject-2.0.so.0 #16 0x415467b0 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #17 0x41546b23 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 #18 0x4164a86c in gtk_button_clicked () from /usr/lib/libgtk-x11-2.0.so.0 #19 0x4164c08c in gtk_button_get_alignment () from /usr/lib/libgtk-x11-2.0.so.0 #20 0x41542263 in g_cclosure_marshal_VOID__VOID () from /usr/lib/libgobject-2.0.so.0 #21 0x41536505 in g_cclosure_new_swap () from /usr/lib/libgobject-2.0.so.0 #22 0x41536b38 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #23 0x41544dc9 in g_signal_stop_emission () from /usr/lib/libgobject-2.0.so.0 #24 0x415467b0 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #25 0x41546b23 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 #26 0x4164a7e6 in gtk_button_released () from /usr/lib/libgtk-x11-2.0.so.0 #27 0x4164b755 in gtk_button_set_relief () from /usr/lib/libgtk-x11-2.0.so.0 #28 0x4170b01c in gtk_marshal_VOID__UINT_STRING () from /usr/lib/libgtk-x11-2.0.so.0 #29 0x41536505 in g_cclosure_new_swap () from /usr/lib/libgobject-2.0.so.0 #30 0x41536b38 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #31 0x415452ff in g_signal_stop_emission () from /usr/lib/libgobject-2.0.so.0 #32 0x41546523 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #33 0x41546b23 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 #34 0x417ed19f in gtk_widget_activate () from /usr/lib/libgtk-x11-2.0.so.0 #35 0x41709757 in gtk_propagate_event () from /usr/lib/libgtk-x11-2.0.so.0 #36 0x41709b90 in gtk_main_do_event () from /usr/lib/libgtk-x11-2.0.so.0 #37 0x419b11f4 in gdk_screen_get_setting () from /usr/lib/libgdk-x11-2.0.so.0 #38 0x414be6be in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #39 0x414c16c6 in g_main_context_check () from /usr/lib/libglib-2.0.so.0 #40 0x414c19b3 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0 #41 0x41708e55 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0 #42 0x08081ef7 in main (argc=1, argv=0xbfb6ba14) at main.c:143 (gdb) q If there is any other pertinent information that I should include, please let me know and thanks for your time! |
|
From: Jake Thebault-Spieker <summatusmentis@gm...> - 2006-01-26 03:14:09
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, I'm a 17 year old high school student, with some programming experiance. I'd like to implement, or help implement photo transfer capabilities. I'm not overly experianced, but I've gotten up through arrays in C/C++. I've looked at the libgpod code a little bit, because my understanding was that something needed to be implemented there first, and then it could be integrated into gtkpod itself. Can someone explain to me where I need to start, and if there's anything I should do before attempting this. Thank you for your help. - -- Numbers rule the Universe. - -The Pythagoreans Carpe Aptenodytes(Seize the Penguins), Jake Thebault-Spieker Take back the web! <www.mozilla.org> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFD2D5U1+LV7p8W5GQRAsyMAKCPR64gFElvt/Xo3+QkLwUdN/kKcgCeNrfh 7HWso70NeRUYcJ2YdK9i7GU= =ldnh -----END PGP SIGNATURE----- |
|
From: James Liggett <jrliggett@co...> - 2006-01-23 20:41:17
|
Can you post the errors? Thanks On Mon, 2006-01-23 at 16:17 +0000, Adam Phillips wrote: > can i have the dependencies needed to run gtkpod on KDE please. As i am > getting errors on install. > > Thanks > > Adam > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 > _______________________________________________ > Gtkpod-devel mailing list > Gtkpod-devel@... > https://lists.sourceforge.net/lists/listinfo/gtkpod-devel |
|
From: Adam Phillips <adam_phillips@bl...> - 2006-01-23 16:23:25
|
can i have the dependencies needed to run gtkpod on KDE please. As i am getting errors on install. Thanks Adam |
|
From: Brian Jackson <iggy@th...> - 2006-01-22 05:11:15
|
I constantly have these problems from sourceforge's cvs servers (on this project and others). I usually just have to retry it a few times to get it to start updating. --Briah James Liggett wrote: > Hi, > When I tried to update my cvs copy from anonymous CVS today it gave this > weird error message: > > cvs [update aborted]: end of file from server (consult above messages if > any) > > And there aren't any other messages other than this one. Is anyone else > having problems like this? > > Thanks, > James > |
|
From: James Liggett <jrliggett@co...> - 2006-01-22 04:57:37
|
Hi, When I tried to update my cvs copy from anonymous CVS today it gave this weird error message: cvs [update aborted]: end of file from server (consult above messages if any) And there aren't any other messages other than this one. Is anyone else having problems like this? Thanks, James |
|
From: James Liggett <jrliggett@co...> - 2006-01-22 03:51:25
|
Hi all, For the past few months I've been working on simplifying the prefrences system in gtkpod to make adding new options easier. Today I finished implementing the backend and things seem to work fine in my testing, but I'd like to get some comments on it before I start posting patches to the list. I've attached some "prototypes" of the new prefs.c and prefs.h files. I've also put the testsuite I made to test this system on my webspace: http://members.cox.net/jrliggett/gtkpod/gtkpod-test-gui-0.1.tar.gz It's just a basic gtk2 app made with glade. The tarball is pretty standard--just extract it someplace, run configure and make, and just run it out of the source tree. Thanks for any commments/suggestions. James |
|
From: Jorg Schuler <jorg.schuler@gm...> - 2006-01-22 02:41:46
|
Hi James, thanks for the update. Feel free to post the backend to the list. I probably won't have time to check out the details, but maybe someone else will be interested. Cheers, JCS. > --- Ursprüngliche Nachricht --- > Von: James Liggett <jrliggett@...> > An: Jorg Schuler <Jorg.Schuler@...> > Kopie: GtkPod Developer Mailing List <gtkpod-devel@...> > Betreff: [Gtkpod-devel] Prefs overhaul...Almost done :) > Datum: Sat, 21 Jan 2006 16:01:00 -0800 > > Hey Jorg, > Good news--I've finished implementing the new prefs backend. :) I've > been testing it with a simple GUI testsuite, and things appear to be > working wonderfully. My next step is going to be to take it out of the > testsuite and try moving over some prefs in the real gtkpod. If that > works, I'll start sending patches in very soon. If you like I can send > you the testsuite also so you can test the new interfaces for yourself. > > James -- What's the difference between eating sugar (e.g. candy bar) and eating carbon hydrates (let's say a loaf of bread)? Telefonieren Sie schon oder sparen Sie noch? NEU: GMX Phone_Flat http://www.gmx.net/de/go/telefonie |
|
From: James Liggett <jrliggett@co...> - 2006-01-22 00:00:01
|
Hey Jorg, Good news--I've finished implementing the new prefs backend. :) I've been testing it with a simple GUI testsuite, and things appear to be working wonderfully. My next step is going to be to take it out of the testsuite and try moving over some prefs in the real gtkpod. If that works, I'll start sending patches in very soon. If you like I can send you the testsuite also so you can test the new interfaces for yourself. James |