View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0006699 | MMW v4 | DB/FileMonitor | public | 2010-11-17 00:08 | 2011-09-08 00:49 |
| Reporter | lowlander | Assigned To | |||
| Priority | urgent | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Product Version | 3.2.3 | ||||
| Target Version | 4.0 | Fixed in Version | 4.0 | ||
| Summary | 0006699: DST change forces rescan of all files | ||||
| Description | When DST changes MediaMonkey will rescan all files. This seems to be due to the way MediaMonkey stores the Timestamp. Tested on MediaMonkey 3.2.3. | ||||
| Steps To Reproduce | 1) Have time change go in effect 2) Set option to rescan files, but only for changed timestamp 3) Start scan 4) Notice that Timestamps change and all files are rescanned | ||||
| Additional Information | http://www.mediamonkey.com/forum/viewtopic.php?f=7&t=53519 http://www.mediamonkey.com/forum/viewtopic.php?f=6&t=58539 | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 1398 | ||||
|
|
This could be related to users who report all files get resynced after time change: http://mediamonkey.com/forum/viewtopic.php?f=7&t=38592 |
|
|
Fixed in build 1386. |
|
|
I found small regression all non played tracks in my library have last played date to 30.12.1899 03:00:00 instead of Empty last played date. To test simply create Auto-Playlist using criteria Played # < 1 EDIT: I have also tested few Scripts and all things we talked on IM it looks that you were right with few exceptions of Auto playlists. That do not improve current change at all. I'm creating specific test script to ensure that there is no regressions. |
|
|
fyi: I tested with build 1388 (upgraded from build 1385), and didn't notice any incorrect last-played dates/times. |
|
|
Yesterday and today I have done tests on 6 of my backup libraries and in all cases after convert last played have that info. I uploaded one DB to FTP, use "playlist -> !!! Not Listened Random 500" to test problem. |
|
|
Fixed in build 1389. - Any newly made update from older databases will prevent this problem. |
|
|
An EL indicates that there can happen an 'Invalid argument to date encode.' error. |
|
|
Fixed in build 1390. |
|
|
UTCOffset field isn't properly filled in for played tracks. |
|
|
Fixed in build 1393. |
|
|
As reported by Bex, DST isn't properly applied for some tracks which results in 1 hour difference after the DB update. |
|
|
Fixed in build 1398. (note that a new DB update is needed in order to test the fix) |
|
|
Verified 1428 |
