View Issue Details

IDProjectCategoryView StatusLast Update
0006699MediaMonkey (current)DB/FileMonitorpublic2011-09-08 00:49
Reporterlowlander Assigned To 
Status closedResolutionfixed 
Product Version3.2.3 
Target Version4.0Fixed in Version4.0 
Summary0006699: DST change forces rescan of all files
DescriptionWhen 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 Reproduce1) 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
TagsNo tags attached.
Fixed in build1398


related to 0007943 closedjiri DB Error on Upgrade to build 1386 



2010-11-17 00:11

developer   ~0021367

This could be related to users who report all files get resynced after time change:


2011-06-08 12:35

developer   ~0025991

Fixed in build 1386.


2011-06-11 19:05

developer   ~0026049

Last edited: 2011-06-11 22:59

View 3 revisions

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.


2011-06-12 02:19

administrator   ~0026052

fyi: I tested with build 1388 (upgraded from build 1385), and didn't notice any incorrect last-played dates/times.


2011-06-12 09:20

developer   ~0026053

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.


2011-06-13 09:47

administrator   ~0026070

Fixed in build 1389.
 - Any newly made update from older databases will prevent this problem.


2011-06-14 13:30

administrator   ~0026128

An EL indicates that there can happen an 'Invalid argument to date encode.' error.


2011-06-14 13:31

administrator   ~0026129

Fixed in build 1390.


2011-06-17 20:45

administrator   ~0026212

UTCOffset field isn't properly filled in for played tracks.


2011-06-17 20:52

administrator   ~0026213

Fixed in build 1393.


2011-06-27 09:04

administrator   ~0026379

As reported by Bex, DST isn't properly applied for some tracks which results in 1 hour difference after the DB update.


2011-06-27 09:05

administrator   ~0026380

Fixed in build 1398.
 (note that a new DB update is needed in order to test the fix)


2011-09-08 00:49

developer   ~0027504

Verified 1428