View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002638 | MMW v4 | Synchronization | public | 2006-09-08 16:21 | 2011-04-27 15:47 |
| Reporter | rusty | Assigned To | |||
| Priority | urgent | Severity | major | Reproducibility | sometimes |
| Status | resolved | Resolution | fixed | ||
| Summary | 0002638: Files synch unnecessarily to iPod when synch timestamp < track timestamp | ||||
| Description | When synching a set of 51 tracks, for some reason there's a set of 8 tracks that always resynchs no matter what--even with auto-conversion disabled. This issue has been reported on numerous occasions in the forums, but hasn't been the reproducible until now. It seems that this is related to the fact that the tracks in question have a timestamp that is in the future (i.e. past the date of the PC doing the synching). To reproduce: Set date on fileserver to 5 minutes ahead of the date of the machine on which MM is running and modify a track on the fileserver (using MM) and then synch. --> future-dated tracks will resynch needlessly. This problem is relatively minor since it is usually transient in nature (in the sense that it'll stop once the future date passes). Note: If after doing step 1, the user wait 5 minutes so that the timestamp of the track passes the time of the machine upon which MM is running and then resynchs. Then ---> tracks resynch needlessly the first time, but afterwards they don't. | ||||
| Additional Information | Debug log on the ftp server. Debug log 1 is based on 0000019:0000050 file synch list of which 8 files are always needlessly synched. The synch operations take place at ~line 700 and ~line 1300 of the log. The tracks that are unnecessarily synched include: Donovan--, Steve Miller-Abracadabra, Dr. Seuss-Zoo Story, Is this love, Down by the River to Pray, Only Rock 'n Roll, I'm on Fire. Note from Jiri re. the exact condition that triggers a file to synchronize: -Update tracks on device if last track synchronization timestamp < track timestamp (as stored in MM DB, not in filesystem) -The timestamp in MM DB and filesystem are usually the same, but maybe they can differ in some cases. | ||||
| Tags | No tags attached. | ||||
| Fixed in build | |||||
|
|
A possible solution discussed is to modify the timestamps of tracks during the synchronization process. This could cause problems though as: a) it'll increase synch time (assuming the entire track has to be loaded/saved over the network). b) timestamps will have to be modified at every synch operation on an ongoing basis (i.e. if the server on which the tracks exist has a time that is slightly ahead of the machine running MM, then whenever the tracks properties are modified, they'll have a new timestamp based on the machine upon which they're stored). c) timestamps may not be modifiable for read-only tracks d) this goes against MM's philosophy of not changing things without the user's consent A possible alternative is to only change the timestamp in the MM db, but this goes against the MM Philosophy of keeping the filesystem in synch with the DB. Thus, I wonder whether the best solution is to simply leave things as is for now and document the fact that files can be synchronize needlessly if time stamps are future-dated. |
|
|
Per discussion, we'll defer this to 3.0 and take a different approach that relies on some changes in the MM db. |
|
|
Can be implemented when 0002729 is resolved. |
|
|
It's probably already resolved. |
