GNOME Bugzilla – Bug 389550
Import ratings, play count, and last-played data from iPod
Last modified: 2020-03-17 08:21:59 UTC
When importing music from an iPod, Banshee should also import the associated metadata such as rating, play count, and last played date. This information should also be imported when syncing an iPod with a Banshee library.
Please specify the latest version of banshee you have been able to test this against or let us know that this is no longer a problem. Thank you for helping us keep track of your bug.
*** Bug 512461 has been marked as a duplicate of this bug. ***
Since Bug 512461 was marked as a duplicate of this, I have to assume that this bug relates to syncing the iPod, not only importing music from it. As someone who listens to a lot of music on my iPod, I just wanted to point out that it would be really nice if listening to a song on my iPod would increase its play count in the Banshee library when I sync the iPod. Just thought I'd throw in a +1 for this enhancement.
If Banshee sync'ed the rating information, it would turn it into my iTunes alternative. The rating features of Banshee is one of the main reasons I love it so much, and need it to work with my ipod. Please work on this bug for it's been out for 2 years. I currently upgraded to Banshee 1.4.1 and have yet to see this feature. Thank you contributing to Banshee... it's almost there! Best Regards
adding this feature would put banshee way ahead of all the other linux players as this is still not properly implemented in any linux player
Created attachment 135331 [details] [review] First draft for rating import This is the first draft of a patch. I leave it here just in case (hopefully I can resume this work next weekend :) ). Beware: - This patch depends on ipod-sharp trunk, plus the patch for bug 583760. - This patch only attempts to update ratings (not playcount or last-played yet). - It's just a draft, it has a lot of commented code and it's very dirty yet. What this patch already accomplishes: - It transfers Ratings to the iPod when the track is already Synced, and Rating >0 on the DB, and Rating==0 on the iPod. - It transfers Ratings from the iPod when the track is already Synced, and Rating==0 on the DB, and Rating>0 on the iPod. Any feedback appreaciated (specifically, there's one UPDATE query that succeeds and seems to be correct, but doesn't cause the PrimarySource to update the values, how can I refresh them without requiring user intervention on the UI?)
Created attachment 135596 [details] [review] v1 Ok! This is the first patch that can be considered clean enough to be committed. Please review. Thanks!
Created attachment 135641 [details] [review] v2, updated to master This patch depends on ipod-sharp trunk to really work.
Can you clarify what won't work if I use it with ipod-sharp 0.8.2? I'm trying to test this out in banshee 1.5.0 and trying to figure out just how unstable of code I have to use to do so.
My iPod is manually managed. Ratings are still not saved, even with this patch. Nor are edits to the compilation artist field (and possibly others; that's the only one I've tried). More details in bug 580632.
(In reply to comment #10) > My iPod is manually managed. Ok, I didn't tested with manual sync mode, I will do it soon. Can you test with auto-sync in the meantime? Thanks for the feedback. PS: Beware, how have you installed ipod-sharp trunk in your system? I ask because there's one system copy and another internal one used by Banshee (be sure to search the ipod-sharp.dll file and replace all its occurrences).
I can think about testing auto-sync, but it will be not terribly practical. I have a 60GB iPod, and it's full now, and my existing music collection on disk is larger than that. I guess I'd have to scrounge up 60GB of space, empty the entire iPod, test it against a temporary smaller collection, and then load it all back... I probably won't have time for that in the immediate future, unfortunately. As for ipod-sharp. I started with the Debian package of it (libipod-cil and libipodui-cil), v 0.8.2. Then I used svn to check out the trunk from http://anonsvn.mono-project.com/source/trunk/ipod-sharp. I then patched the Debian package up to this version, built new .debs, installed them systemwide (overwriting the libipod-cil and libipodui-cil packages that were already installed). Finally, I rebuilt banshee 1.5.0 with this patch applied, and installed it systemwide in the same manner. I do see that both libipod-cil and banshee packages installed ipod-sharp.dll files in various locations. the banshee source package doesn't have that package; it must build it at compile time, and I had upgraded libipod-cli and libipodui-cli first.
Created attachment 138708 [details] [review] v3, added syncing in manualsync mode, and updated to master (In reply to comment #12) > I can think about testing auto-sync, but it will be not terribly practical. I > have a 60GB iPod, and it's full now, and my existing music collection on disk > is larger than that. I guess I'd have to scrounge up 60GB of space, empty the > entire iPod, test it against a temporary smaller collection, and then load it > all back... I probably won't have time for that in the immediate future, > unfortunately. Ok, jgoerzen, can you test this patch now? It's working for me in manual sync mode as well. Thanks in advance.
I will be HAPPY to -- but it might not happen until Monday. (Have a newborn baby in the house and spare time is, well, diminished..) Thanks for your work on it!
I'm trying to apply this atop 1.5.0 and am getting some conflicts. I'll work through it, but do you expect it to work on 1.5.0?
(In reply to comment #15) > I'm trying to apply this atop 1.5.0 and am getting some conflicts. I'll work > through it, but do you expect it to work on 1.5.0? > jgoerzen: sorry if I wasn't clear: the patch applies to git master, not 1.5.0. See http://banshee-project.org/contribute/write-code/ for further info. BTW, I'll add some excerpts from the Banshee Developer meeting held today regarding this feature: (...) abock: DB changes like this require extra scrutiny and review abock: gabaug: thoughts on knocte's patch? gabaug: the ipod one? abock: it's a pretty comprehensive patch abock: oui gabaug: we can put it on the list of possibly's - I'd want to do an review/iteration or two (...) abock: I think we can also do BGO 489861 for 1.5.2 abock: if it turns out to be a good idea :) abock: that leaves auto-dj and sync-dap-from-playlists abock: and possibly the rating-sync from ipod, pending review and heavy testing of the DB stuff for 1.5.3 (...) So, marking for wanted-1.6.
OK, I will try that out too, but it might take me a bit longer. In any case, the feature I care about isn't any syncing, just writing out changes manually made. It appears that patch is wrapped up in the larger syncing one though?
(In reply to bug#580632 comment #9) > In particular, 1.5.0 has format 32 in BansheeDbFormatMigrator, while this patch > assumes that I was starting with format 33. Makes me nervous to try to apply > it. Advice? Well, yeah, I recommend that you backup your database before trying out this patch. (In reply to comment #17) > In any case, the feature I care about isn't any syncing, just writing out > changes manually made. It appears that patch is wrapped up in the larger > syncing one though? Let's see. I'll explain the typical use case this bug covers: 1. You have 3 songs in your local database: Coldplay - White Shadows (Rating: 3 stars) Keane - Bedshaped (No rating set) Depeche Mode - In Your Room (No rating set) Massive Attack - Future Proof (No rating set) 2. You connect the iPod, and: a) If you have AutoSync mode, all songs are transferred to the iPod. b) If you have manual mode, you transfer the songs manually to the iPod (drag and drop). 3. You disconnect the iPod. After this step, the situation is the following: [Local DB] Coldplay - White Shadows (Rating: 3 stars) Keane - Bedshaped (No rating set) Depeche Mode - In Your Room (No rating set) Massive Attack - Future Proof (No rating set) [iPod] Coldplay - White Shadows (Rating: 3 stars) Keane - Bedshaped (No rating set) Depeche Mode - In Your Room (No rating set) Massive Attack - Future Proof (No rating set) 4. While using your iPod, you rate the Depeche Mode song with 4 stars and the Massive Attack one with 4 stars as well. 5. While using Banshee, you rate Keane's song with 5 stars, update Coldplay's song to 4 stars, and give Massive Attack's 5 stars. After this step, the situation is the following: [Local DB] Coldplay - White Shadows (Rating: 4 stars) Keane - Bedshaped (Rating: 5 stars) Depeche Mode - In Your Room (No rating set) Massive Attack - Future Proof (Rating: 5 stars) [iPod] Coldplay - White Shadows (Rating: 3 stars) Keane - Bedshaped (No rating set) Depeche Mode - In Your Room (Rating: 4 stars) Massive Attack - Future Proof (Rating: 4 stars) 6. You connect the iPod again. Result: all the ratings will *merge*. That is: - 1st song will update the rating to the iPod. - 2nd song will import the rating to the iPod. - 3rd song will import the rating from the iPod. - 4th song will be held as is in both places, because there was a conflict. (Because you did different ratings on both places. You will see an error about the synchronization of the rating for this song.) Result: [Local DB] Coldplay - White Shadows (Rating: 4 stars) Keane - Bedshaped (Rating: 5 stars) Depeche Mode - In Your Room (Rating: 4 stars) Massive Attack - Future Proof (Rating: 5 stars) [iPod] Coldplay - White Shadows (Rating: 4 stars) Keane - Bedshaped (Rating: 5 stars) Depeche Mode - In Your Room (Rating: 4 stars) Massive Attack - Future Proof (Rating: 4 stars) Now, if your use case is not covered on this scenario (which covers already plenty of combination of sync use cases), please describe it. Thanks! And congrats for the new visitor in your house ;)
Thanks! :-) That all sounds like a cool feature, but it's way more than I care about. What I'm after is this: If I plug in an iPod that is manually managed, and I click on a track to set a rating, I want that rating to be actually saved to the iPod, not ignored. That's all. Down the road, I may use the features you mentioned, but not immediately.
(In reply to comment #19) > If I plug in an iPod that is manually managed, and I click on a track to set a > rating, I want that rating to be actually saved to the iPod, not ignored. When you say "click on a track to set a rating", are you referring to the track on the iPod or to the track on your library? If it's the former, that should work already. If it's the latter, heck, I didn't think about that, and I'll include that use case in the next version of the patch. Thanks for sharing your thoughts.
The track on the iPod. Those tracks aren't in the library at all on some of the computers I regularly use. See my comment #3 on bug 580632 for details. Thanks again for your help.
(In reply to comment #21) > The track on the iPod. Those tracks aren't in the library at all on some of > the computers I regularly use. Gosh, I thought this was working already with Banshee 1.5.0 or git master! Sorry for wasting your time then. Anyway, it's a different bug and thus I filed bug 589196 for that (and I already uploaded a proposed patch). Thanks!
Comment on attachment 138708 [details] [review] v3, added syncing in manualsync mode, and updated to master I'm marking this patch as needs-work because: - A new version of ipod-sharp has been released. Now I can embed the check for this version in the patch as a change in the configure phase. - The patch on bug 589196 is smaller than this one and covers a simpler scenario than this bug (indeed, that is a defect and this one is an enhancement), so it's more likely that gets committed before this one, and that patch contains some code that can be reuse or may conflict with this patch.
Bulk changing the assignee to banshee-maint@gnome.bugs to make it easier for people to get updated on all banshee bugs by following that address. It's usually quite apparent who is working on a given bug by the comments and/or patches attached.
Whats the status of this bug/feature-request? Is it being worked on, and can it be expected to be found in a future version av banshee anytime soon? The feature is already available in amarok and songbird just to mention a few other linux music players (of which the latter i have just migrated from to banshee, just to find out that i cant sync my ipod properly when i've worked like 10 hours straight just to transfer playcounts and ratings into banshee)
*** Bug 609783 has been marked as a duplicate of this bug. ***
(In reply to comment #25) > Whats the status of this bug/feature-request? Is it being worked on, and can it > be expected to be found in a future version av banshee anytime soon? Sorry for the late response. As I said in comment#23, I see more logical to apply the simplest use case (the patch for bug 589196) before we commit this one, so I'm marking this bug as dependent on that one. If you're interested in helping, I cannot figure out another way than bugging the devs/maintainers to do the reviews ASAP :) (BTW, that bug depends on another one...)
Do I understand the current status correct, if the ratings made on the iPod are _not_ synchronized? The Depeche Mode song will not have 4 stars in the Banshee library then, will it? And there's no patch in git master o.s.s. for this, correct? I really would appreciate this feature and would like to help to test it.
(In reply to comment #28) > Do I understand the current status correct, if the ratings made on the iPod are > _not_ synchronized? > The Depeche Mode song will not have 4 stars in the Banshee library then, will > it? > > And there's no patch in git master o.s.s. for this, correct? There's a patch in the bug that covers only rating import, though, and which may be updated. > I really would appreciate this feature and would like to help to test it. Great, thanks for offering your help. Sorry I have been very delayed in getting this feature properly reviewed by maintainers, but I've been fixing other things which IMO had more priority. For example, a feature that I consider more basic than this one is be able to save updated metadata (including Rating) from the library to the iPod, which is bug 589196. I want to land that feature before this one. For that, it would be helpful also that you help testing it. And currently, that bug depends on another bug which has a patch and is waiting for a review. Would you be so kind to test the patch and report that it works? Thanks!
(In reply to comment #29) > (In reply to comment #28) > > Do I understand the current status correct, if the ratings made on the iPod are > > _not_ synchronized? > > The Depeche Mode song will not have 4 stars in the Banshee library then, will > > it? > > > > And there's no patch in git master o.s.s. for this, correct? > > There's a patch in the bug that covers only rating import, though, and which > may be updated. I meant outdated.
K, I will try to get git master running and will test bug 589196.
I'd just like to throw my weight behind this enhancement (instead of posting a duplicate bug) - I want to use Banshee to manage my music, not to play it - therefore the playcount, ratings etc on the ipod are more relevant. 2-way sync with the Banshee playcount/ratings is needed.
(In reply to comment #32) > 2-way sync with the Banshee playcount/ratings is needed. Totally agree, but 1-way sync has more priority, don't you think? If yes, go help me on bug 589196 first :)
(In reply to comment #33) > Totally agree, but 1-way sync has more priority, don't you think? If yes, go > help me on bug 589196 first :) You are some kind of pushing bug 589169, don't you? I really appreciate this! :)
Damn, I mistyped the bug id... I meant bug 589196 of course.
Quick comment after a chat with knocte on IRC about // if the LastModifiedTime field in the iPod gave us the real date on which the rating was modified, we wouldn't need this table This table is used to decide whether to sync the rating ipod->banshee or banshee->ipod when the ratings are different on the iPod and in banshee. The iPod database contains 2 rating fields, "rating" which is the rating as displayed by the iPod, and an application_rating field. It *seems* the application_rating field could be used to store the banshee rating after a sync. This could then be used to decide in which way to sync when rating differs between banshee and the iPod. Some changes in libgpod might be needed though.
Are there any updates about this bug? (Or even patches? :) )
guerda, this bug still depends on a not fixed bug. I cannot create a patch for this until we finish it.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I decided for myself to donate 50 €, if this bug is fixed and rolled out to a Banshee PPA. I will split the donation as followed: 25 € to the Gnome Foundation and 25 € to the developer who has implemented the applied patch. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5SIp8ACgkQYNYFUFLXAD0L1ACfWidb1DKG9dPjSr/HZXwr/MBJ CWIAoImJGt0ahJ3jWnkf//UuK4c8mipE =YiUa -----END PGP SIGNATURE-----
hmm, just check the bugzilla & the code on libgpod and track.time_modified seems ok on that side. So issue is on banshee because last modified date is always update when read thanks to playcount. The patch of the bug 602159 can solve this issue and a patch for sync can work for it I guess... Knocte, do you know more blocking issue before patch. Else We can code the patch (not interested by money thanks but can be given to paid banshee website/gnome foundation).
I think banshee should use the rating vs. app_rating fields from the database, same with recent_playcount. So I don't think we have to mess with file times.
Banshee is not under active development anymore and had its last code changes more than three years ago. Its codebase has been archived. Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect reality. Please feel free to reopen this ticket (or rather transfer the project to GNOME Gitlab, as GNOME Bugzilla is being shut down) if anyone takes the responsibility for active development again. See https://gitlab.gnome.org/Infrastructure/Infrastructure/issues/264 for more info.