libipodimport
libipodimport copied to clipboard
H2CO3
iOS 6.0.1
Hi, when i try to use the code into my app the song was import into iPod library twice. One correctly and other with zero byte
I have try also addtoipod in ssh but i have the same issue
tnk's 4nd413
I can confirm this too (6.1, iPod touch 4g). Also the Cydia app Bridge has been updated with the message "Fixed duplicate song import bug on iOS 6." The duplicate song doesn't play, however, and is greyed out (as OP mentioned, is an empty file). It can be deleted by swiping. Does anyone have any ideas as to why, and how to avoid this? Something new in the StoreSession framework? I thought removePlaceholderDownload (not new) might be promising, but didn't have any effect for me.
Good question. I'll look into this soon as it seems to bug a lot of users. In the meantime, however, feel free to investigate what is going on, perhaps you can find some valuable information too.
@H2CO3: I've already tried some things. Did a diff of SSDownloadQueue.h in iOS 5 and 6 and saw one method was added: _handleDownloadsRemoved, but didn't get anywhere with that. Is the best way to go about doing this just to look and the dumped headers and try things out, or is there a more professional way?
A "more professional way" would be properly reverse engineering the StoreKit framework (et al.) but in my opinion, the "while (!works) { try out other stuff }" approach is generally faster.
Is it possible to hook into private framework functions with a tweak and do a stack trace, or would most information be missing in release versions?
That depends on various conditions, I don't know it off the top of my head, honestly.
I tried a bunch of different functions out today, including an alternative to importing with SSDownloadQueue: SSDownloadManager. All had no effect on the double import. Also tried this out on my newly purchased (used) iPhone 4 running iOS 6.1 (normally used iPod touch 4) and for some reason the code runs without creating duplicates in the iPod library, or at least duplicates disappears from view quite quickly. But the same code runs with duplicates on the iPod touch.
Had an alternative workaround: how about deleting the empty file from the iTunes library file (MediaLibrary.sqlitedb)? I had a quick look at the database structure and it would seem quite easy to just delete the empty duplicate.
The problem is that you can't "just delete" files. If I could, I would have done that already. But it's secured at multiple stages: checksums, whatever. And only the StoreServices framework knows how to do that.
That sucks. Well the dirty option is to just remove zero sized file entries from database https://gist.github.com/intarstudents/4725159 - thats works somehow
No you cannot. The database is cheksummed, that's what I'm trying to say. If you alter the database, iPod will erase it upon first launch.
I think @H2CO3's right, I tried out @intarstudents' script and it even though it worked at first sight--the empty file was back after a restart, so the database must have been replaced with a backup after failing the checksumming. Or did you have a different experience, @intarstudents?
@newenglander no, I forgot to test, what will happen after restart, so my bad.
I got a workaround that looks good, using the ML3MusicLibrary class from the MusicLibrary private framework. There you can open the database with initWithPath:enableWrites: and then with executeSQL: I ran @intarstudents statements (after waiting a few seconds, because the empty files don't appear immediately) and the empty files remain deleted even after a device restart.
If you guys are interested in trying this out, I could post some code in my yet unchanged fork. But there's not much to it.
Also tried out these functions from the same class, but didn't have any luck with them:
deleteAutoFilledTracksOfAtLeastTotalSize:
removeLocationsForItemsMissingAssets
resetAllContents
updateTrackIntegrity
resetUbiquitousMetadata
Sounds interesting. I'm interested. Maybe you could provide compiled binaries too?
The problem with providing a binary is I'm using the code for another project. If you're curious, check out my blog: http://erike.net/audioexplorer/ If you'd like to try a beta version of that, let me know.
@H2CO3 is strangely silent, not satisfied with the solution? ;) I would just add more conditions to @intarstudents' SQL statements to really make sure we're not deleting anything that was there before (who knows, maybe there are files there with file size of 0).
Well, I was just busy, I'll try this (but yeah, this seems quite a bit of a hack anyway).
Hmm, didn't have any crashing. But I'm using your suggestion about using the entitlements for accessing the iTunes library, so I don't have to hook into SpringBoard. Don't know if that's the issue.
It seems gremlin doesn't have this issue even though they use the same import mechanism
True I looked through his code but I couldn't find anything that stood out. Even tried adapting libipodimport to run as a daemon. I do not know if the code on his github is the same as the final build on bigboss though. Would be nice to figure this out maybe it would be better to make libipodimport a daemon service as outlined by apple docs that way it also removes the need for MobileSubstrate
I'd rather not make a daemon - it functions almost the same as a MobileSubstrate-injected dylib, but then I need to worry about signing with entitlements and setting up the startup plist. It's superfluous. However, I did notice some very small differences in Gremlin which I'll try to implement accordingly to see if it improves anything.
Makes sense. Hopefully it works. There is more completion work in gremlin. I did notice that itunes was throwing some warnings saying that art rendering wasn't done with libipodimport but not with gremlin so maybe its the cleanup thats doing this