View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0012266||MediaMonkey (current)||Synchronization||public||2014-10-27 11:44||2019-10-10 12:54|
|Target Version||4.1.25||Fixed in Version||4.1.25|
|Summary||0012266: iOS5+ sync: Read device content rather from MediaLibrary.sqlitedb|
|Description||iTunesCDB file is quite outdated although still used by iTunes as DB file for device content. Nevertheless starting from iOS5 the device itself reads its content mainly from MediaLibrary.sqlitedb.|
So MM should also read content from MediaLibrary.sqlitedb rather than from (almost deprecated?) iTunesCDB file to ensure that correct content will be presented in MM insterface even if iTunesCDB is missing or is only partial.
|Tags||No tags attached.|
|Fixed in build||1893|
|parent of||0012814||resolved||Ludek||iOS8: Tracks deleted in iPhone music app are still visible by iTunes and MM|
|related to||0012396||closed||Ludek||iPhone content not read when iTunesCDB is larger than 4194304 bytes|
|related to||0012806||resolved||Ludek||iOS8: In some cases audio doesn't match title on iPhone|
|related to||0016017||closed||Ludek||Sync: Iphone7 iOS 13.1.2 do not finish Scanning device|
I added the code to read the contents from MediaLibrary.sqlitedb, but I finally just backed up the code and did not apply it so far for several reasons:
1) Durning the implementation I found that iTunes still prefers the old iTunesCDB file to read the device contents, namely if the file is missing or corrupted then iTunes does not see the device content
2) MediaLibrary.sqlitedb is really used rather for storing internal device contents and its DB structure is changed with every new version of iOS in any way, while iTunesCDB structure is almost unchanged for years
3) I wanted to change it because of the user from ticket VOY-630-62036 , but finally it shown another issue, there was bug in MediaMonkey that it can't read iTunesCDB larger than 2^22 = 4194304 bytes , this issue was fixed as 0012396
The original code for this issue is backed up in SVN, but not applied due to the reasons noted above and high risk of a regression
Moving target to 5.0
We should evaluate this as possible remedy of GNK-420-16733
It could be implemented with a fallback:
i.e. whenever reading from MediaLibrary.sqlite fails for whatever reason (e.g. new SQL structure) then MM will read the tracks from iTunesCDB (as currently)
A safe way to implement this for 4.1.25 (and remedy of GNK-420-16733) would be to read the tracks from the *.SQLite only when track count from *CDB is lower.
=> Implemented in 1892 and merged to MM5
No regressions while testing with iPod Touch 4G
Close after tests in MM5
The remedy does not work for GNK-420-16733 , there was still a bug.
Fixed in 1893 and supplied updated DLL to the user to confirm the fix...
||Fix confirmed by the user and me, closing.|