GNOME Bugzilla – Bug 605140
Rebuilding ArtworkDB to slow, option not sync until the end
Last modified: 2018-05-24 14:54:45 UTC
Created attachment 150171 [details] [review] Patch to differ a database save if new save action are submitted Please look at the bug : https://bugzilla.gnome.org/show_bug.cgi?id=605126 Using iPhone 3GS, firmware 3.1.2 (should apply to iPod Touch new gen) Basically rebuilding the ArtworkDB (process done by libgpod) is too time and bandwidth expensive to be done continuously as it seriouly impact the file transfert process making the whole process 5 to 10 times slower. Maybe an option to disable this behaviour and wait the end of all file transfert to sync the database. Included a small patch to wait 15 seconds more for the database sync process to start if a new save action is submitted.
On the one hand, not saving while the database is being modified makes sense, on the other hand, saving from time to time minimizes the amount of data loss if something goes wrong (rhythmbox crash) while rhythmbox is transferring data. I have plans to make that better (hopefully much better) in libgpod, but they are low priority at the moment.
Or on one hand I have a process that takes 2 hours but is saved continuously, on the other hand I have the same process that takes 20 minutes and is not saved until its end. Theorically rhythmbox have the same chance of crashing in either case but libgpod when called 10 times during this process instead of one will have more chance to crash. Not to mention it is painfully slow. In case of crash I can still use gtkpod to clean up (detect orphans, etc...). Maybe this functionality could be imported inside the ipod plugin anyway. libgpod for me is working fine with iFuse. The problem is when used with a gvfs-afc mount.
(In reply to comment #2) > Or on one hand I have a process that takes 2 hours but is saved continuously, > on the other hand I have the same process that takes 20 minutes and is not > saved until its end. This is not just about you and what you experience using an experimental library, this is about rb+ipod users in general, especially those without an iphone/itouch.
gvfs-afc is not experimental. :) But I agree with you, I am not the only one, that's why I proposed to add a check box or something in the rb-ipod interface to let the user choose the sync behaviour. That seems fair to me. Anyway I return your comment back to you, who says the current behaviour is the preferred method by all the users? If I do not agree with you, maybe I am not the only one. For me that's fine as is, as I have patched rb for my use. As I said, I proposed a modification, I explained why with some arguments (speed, frequency of crash from other lib and usability), I included a small patch explaining what I request (without the interface code), and I let you Gnome devs decide what is best. I am sure you know what you are doing. :) > This is not just about you and what you experience using an experimental > library, this is about rb+ipod users in general, especially those without an > iphone/itouch. Let see in a few months, how things goes...
(In reply to comment #4) > gvfs-afc is not experimental. :) But the libgpod you are using is, and it's doing thousands of stat calls when it needs not... > Anyway I return your comment back to you, who says the current behaviour is the > preferred method by all the users? If I do not agree with you, maybe I am not > the only one. I haven't said I favoured one behaviour over the other, I'm just not sure which tradeoff is preferrable so I was trying to assess the pros and cons. > As I said, I proposed a modification, I explained why with some arguments > (speed, frequency of crash from other lib and usability), I included a small > patch explaining what I request (without the interface code) Yep, thanks for the patch and the explanations ;)
> But the libgpod you are using is, and it's doing thousands of stat calls when > it needs not... I am just saying that with iFuse + this experimental version I do not have this issue. So I hope you are right and that when this lib will not make unneeded stat calls everything will rocks. No, I am sure you are right on the money, it must be it :) I mean, who cares about what iFuse is doing :)
But did you test gtkpod + gvfs (through fuse)? If not, I'm not sure we can make a meaningful comparison between what you get with gvfs afc and what you get with ifuse. I'm also not saying there's no bug in gvfs-afc (there was a thread about stat cost on libiphone-devel btw), I'm just pointing out that libgpod isn't behaving nicely with the iphone either and that some improvement could come from it too.
I can test : 1) gtkpod with my ~/.gvfs/iPhone mount point using the gvfs-afc backend for the gvfs fuse module 2) gtkpod with my /media/iphone mount point using iFuse without gvfs Same libgpod, same ligiphone, same gtkpod, usbmuxd, etc... : 1) 2m40s 2) 25s
ok, wasn't sure this had been tested, thanks for the data point!
My point is, there is something wrong in gvfs-afc. I don't know if it can be fixed but if it can't rhythmbox ipod needs something because the current support (or the one in the next stable, or what ever) of the iPhone and iPod touch will be something really annoying. Copying 100 songs in half an hour or more will annoy a lot of people. As things goes actually with the Apple products, there is more iPhone 3G(S) than iPhone in the world. I don't have the latest number for the iPod touch but in six months we can expect a lot more users. So this problem I have, not wanting to have rhythmbox sync continuously risk to be pointed out by others...
So here is my latest benchmark with the libgpod4=0.7.90git20100210-0ubuntu2~ppa1. This version is less than a month old. There is a newer libgpod but there is still no package for it and I doubt it does more for this problem (see the changelog). I will update this bench as soon as I find a newer version. My test is done with 38 audio files for 264MB and an iPhone 3GS 32GB. I have on it already 2390 files for 18.2GB . ====== GTKPod ====== First let's take a look at using GTKPod. I have a Music Libray containing only those files. I will copy them, press the "Save" button, wait for the transfert to finish and wait for the sync process to finish writing down both the times it took. I delete those files and sync between each test of course. Using GTKPod + GVFS-AFC ----------------------- Copy process : 3:21 (two second gap between the two process) Sync process : 3:02 Total Process Time : 6:25 Using GTKPod + iFuse -------------------- Copy process : 4:38 (two second gap between the two process) Sync process : 0:29 Total Process Time : 5:09 Conclusion ---------- Strange, iFuse is slower to transfert the data but the sync process is way faster (6 times faster). I checked again and the benchmark were similar. ========= Rhythmbox ========= Now for the most annoying problem. Using Rhythmbox. Rhythmbox unpatched ------------------- Rhythmbox ipod plugin does not just transfert the files and sync after, it start a sync 15 seconds after the first transfert is started. The transfert rate drops 3 to 4 times slower and when the sync process is over, if others file were copied a new sync process is started 15 seconds later, slowing down again the process, etc... When the last file is transfered, if the device is still sync'ing a last sync process is started... 15 seconds later. So for this bench, two times : 1-the duration of the transfert to the end of the last sync process which started during the file transfert 2-the duration of the sync process that started 15 seconds after the last file transfert and ongoing sync process Copy+Ongoing Sync : 12:24 (~15 seconds gap) Last Sync : 3:07 Total process : 15:47 15 minutes and 47 seconds. For just 38 tracks and 264 MB. At this rate it will take me more than 24 hours to fill my device (using the 12:24 times). Rhythmbox patched ----------------- Now I patched Rhythmbox for resheduling the sync process for 15 more seconds if a file started to be transfered since the process was scheduled. Now no sync process is done durint file transfert and this process is not slowed down. Still a last sync process occurs after few seconds at the end of the transfert process. Copy process : 2:59 (~25 seconds gap) Sync process : 3:07 Total Process : 6:32 The sync process time did not changed at all but the transfert process was hugely improved. ========== CONCLUSION ========== GTKPod + GVFS-AFC : 6:25 GTKPod + iFuse : 5:09 Rhythmbox unpatched : 15:47 Rhythmbox patched : 6:32 Even if GVFS-AFC could be improved with much coding and suffering and caching and stuff the problem will still be here !!!!! I repeat it would take about 24 hours to fill my device using Rhythmbox without patching it first!!! For huge device like those huge iPod Touch, up to 64GB which would take two days to fill, and iPhone 3GS there should not have a continuous sync during transfert!!!
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/rhythmbox/issues/855.