View Issue Details

IDProjectCategoryView StatusLast Update
0006699MediaMonkey (current)DB/FileMonitorpublic2011-09-08 00:49
Reporterlowlander Assigned To 
PriorityurgentSeverityminorReproducibilityalways
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 Informationhttp://www.mediamonkey.com/forum/viewtopic.php?f=7&t=53519
http://www.mediamonkey.com/forum/viewtopic.php?f=6&t=58539
TagsNo tags attached.
Fixed in build1398

Relationships

related to 0007943 closedjiri DB Error on Upgrade to build 1386 

Activities

lowlander

2010-11-17 00:11

developer   ~0021367

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

Ludek

2011-06-08 12:35

developer   ~0025991

Fixed in build 1386.

peke

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.

rusty

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.

peke

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.

jiri

2011-06-13 09:47

administrator   ~0026070

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

jiri

2011-06-14 13:30

administrator   ~0026128

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

jiri

2011-06-14 13:31

administrator   ~0026129

Fixed in build 1390.

jiri

2011-06-17 20:45

administrator   ~0026212

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

jiri

2011-06-17 20:52

administrator   ~0026213

Fixed in build 1393.

jiri

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.

jiri

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)

peke

2011-09-08 00:49

developer   ~0027504

Verified 1428