Add/Rescan adding all files after DST change [#6699]

by **LikeMM** » Mon Mar 14, 2011 9:31 pm

nohitter151 wrote:You do these updates with a program besides MM? If not, you do not need to rescan.

Ah, I get what you mean. I have to explain more carefully. When I get these old concerts, I sample-listen to the songs and decide if the recording quality is good or if they could be cleaned by me. If yes, I tag them with Mp3tag and add them to MM3. Later when I get time I clean them up in Audacity and other software. Sometimes these programs don't preserve all the tags, especially comment & year.

As it is done outside MM, I do rescan, run Files To Edit -> Unsynchronized Tags and re-synchronize them. I know I can scan only the folder I changed. Also, I can just enable Folder Watch instead of rescanning when I add songs. I find it simpler to rescan all; and not let MM poke its nose when I am working on songs in a folder. I temporarily convert mp3's to flac while working on clean up. Don't want MM to add these temp flac files to database.

by **nohitter151** » Mon Mar 14, 2011 8:03 pm

LikeMM wrote:Sorry nohitter, this is a bug and has been acknowledged with a mantis entry. The developers need to fix it. Unfortunately they seem to be too busy with MM4.

I am not saying is isn't a bug. Just that the workaround is easy enough.

LikeMM wrote:Only periodical complete rescan will expose any discrepancy with what is in the database and what are in the tags. My database is not a dormant one. I constantly update people involved and concert tidbits of old concerts from 1950's and beyond, as I get new info.

You do these updates with a program besides MM? If not, you do not need to rescan.

by **LikeMM** » Mon Mar 14, 2011 8:00 pm

Sorry nohitter, this is a bug and has been acknowledged with a mantis entry. The developers need to fix it. Unfortunately they seem to be too busy with MM4.

Only periodical complete rescan will expose any discrepancy with what is in the database and what are in the tags. My database is not a dormant one. I constantly update people involved and concert tidbits of old concerts from 1950's and beyond, as I get new info. Recorded on spool tapes before I was born.

by **nohitter151** » Mon Mar 14, 2011 8:58 am

LikeMM wrote:When will this be resolved in MM3? I am seeing it again after DST change.

The workaround is very simple, just don't rescan your tracks every day! Once the files are in the DB, there really is no need to rescan them!

by **LikeMM** » Sun Mar 13, 2011 9:58 pm

When will this be resolved in MM3? I am seeing it again after DST change.

by **Lowlander** » Tue Nov 16, 2010 7:09 pm

I do believe the way the Timestamp is stored is the cause of this issue.

I've added it to the Bug Tracker: http://www.ventismedia.com/mantis/view.php?id=6699

by **Lowlander** » Tue Nov 16, 2010 6:52 pm

Just checked on a folder and yes the Timestamp has changed to a hour earlier on first rescan after DST change.

I wonder if dates are stored as x time since y or as actual dates in the database.

by **MinersC** » Sat Nov 13, 2010 8:06 pm

I think that might be a different problem, I doubt it's related to the change in time.

After re-starting MM several times due to the out of resources errors once MM's private bytes had reached 1.7GB MM has finally re-scanned the entire database. I've added a bunch of new albums I had waiting and MM seems well behaved now and I haven't seen it's private bytes grow continuously while adding tracks. Not sure what the issue was but something was up.

by **nohitter151** » Fri Nov 12, 2010 10:21 pm

MinersC wrote:Update to issue is that after letting MM run for awhile error windows start popping up for each song it tries to scan. The error is:

Thread creation error: Not enough storage is availalbe to process this command.

MM produces 20 of these windows. After closing them clicking anywhere in the MM window then causes windows to popup one after another stating:

Not enough storage is availalbe to process this command.

So far this is repeatable.

I think that might be a different problem, I doubt it's related to the change in time.

by **MinersC** » Fri Nov 12, 2010 7:53 pm

Update to issue is that after letting MM run for awhile error windows start popping up for each song it tries to scan. The error is:

Thread creation error: Not enough storage is availalbe to process this command.

MM produces 20 of these windows. After closing them clicking anywhere in the MM window then causes windows to popup one after another stating:

Not enough storage is availalbe to process this command.

So far this is repeatable.

by **MinersC** » Wed Nov 10, 2010 9:16 pm

Lowlander wrote:He's asking about the Timestamp which is a column you can enable in MediaMonkey.

For a track that has been scanned as part of the "slow scan" since DST change the time stamp in MM is 1 hour behind the file's LastWriteTime timestamp on disk.
For a track that has not yet been scanned since DST change the time stamp in MM is the same as the file's LastWriteTime timestamp on disk.

by **Lowlander** » Wed Nov 10, 2010 8:58 pm

He's asking about the Timestamp which is a column you can enable in MediaMonkey.

by **MinersC** » Wed Nov 10, 2010 8:54 pm

When I asked about timestamp, I meant the reported timestamp in MediaMonkey, not the one you find in Windows Explorer.

Please let me know how to find the last scan time, as it doesn't seem to be one of the track properties when looking at the properties from right clicking on the track.

by **Lowlander** » Wed Nov 10, 2010 8:02 pm

I can't say if the timestamps changed in MediaMonkey, but they didn't change to the scan date.

by **nohitter151** » Wed Nov 10, 2010 7:53 pm

MinersC wrote:I've also experienced the same issue with MM re-scanning all tracks when only a few are added and using Tools/Add/Rescan Tracks to the Library.... My last scan was before the local time change and took less than a minute. Now scan has been runing for well over 30 minutes and has added less than 5500 songs, averaging about 3 songs per second. The songs are all MP3s stored on an external drive attached via eSATA and formatted NTFS on Windows 7 64-bit. I routinely use RoboCopy to backup the songs to a remote share and have just ran it again to verify the time stamps of the MP3 files have not changed as only the new albums were copied. I've used MM for years and have never had this issue across a time change. I'm running the latest version 3.2.2.1300. As well, when I right click on the "adding" status bar and choose Terminate from the popup menu it does not terminate. I'm not sure if this is typical but when I first looked MM was using just over 400MB in Private Bytes and now at just under 6000 tracks scanned it is using 650MB in Private Bytes. It looks like there is some sort of bug with MM.

When I asked about timestamp, I meant the reported timestamp in MediaMonkey, not the one you find in Windows Explorer.

Add/Rescan adding all files after DST change [#6699]

Post a reply

Expand view Topic review: Add/Rescan adding all files after DST change [#6699]

Re: Add/Rescan adding all files after DST change [#6699]

Re: Add/Rescan adding all files after DST change [#6699]

Re: Add/Rescan adding all files after DST change [#6699]

Re: Add/Rescan adding all files after DST change [#6699]

Re: Add/Rescan adding all files after DST change [#6699]

Re: Add/Rescan adding all files after DST change

Re: Add/Rescan adding all files after DST change

Re: Add/Rescan adding all files after DST change

Re: Add/Rescan adding all files after DST change

Re: Add/Rescan adding all files after DST change

Re: Add/Rescan adding all files after DST change

Re: Add/Rescan adding all files after DST change

Re: Add/Rescan adding all files after DST change

Re: Add/Rescan adding all files after DST change

Re: Add/Rescan adding all files after DST change