Type change causes 'last written' timestamp update [#8843]

This forum is for reporting bugs in MediaMonkey for Windows 4. Note that version 4 is no longer actively maintained as it has been replaced by version 5.

Moderator: Gurus

Post Reply
KEP
Posts: 186
Joined: Sun Feb 18, 2007 10:27 pm
Location: Vancouver USA

Type change causes 'last written' timestamp update [#8843]

Post by KEP »

EDIT: Added comments in "code" block, to clarify what was going on. I know not everyone "speaks DOS" anymore.

As I try to clean up my music library, so it works better with the new Collections paradigm in MM4, I've noticed that simply changing the Type (eg, from Music to Classical Music), causes the "last written" timestamp on the MP3 file to change. And yet, appropriately, there are no changes being made to the MP3 itself. Here's the trail as seen through a command prompt...

Code: Select all

***** Make copies of several MP3s before changing database attributes in MM *****

F:\Music\Composers\Beethoven\Symphonies\Symphony 2>for %f in (*.mp3) do copy "%f" "%f.bak"

F:\Music\Composers\Beethoven\Symphonies\Symphony 2>copy "Symphony no.2 in D major, op.36- Adagio molto - Allegro con brio.mp3" "Symphony no.2 in D major, op.36- Adagio molto - Allegro con brio.mp3.bak"
        1 file(s) copied.

F:\Music\Composers\Beethoven\Symphonies\Symphony 2>copy "Symphony no.2 in D major, op.36- Allegro molto.mp3" "Symphony no.2 in D major, op.36- Allegro molto.mp3.bak"
        1 file(s) copied.

F:\Music\Composers\Beethoven\Symphonies\Symphony 2>copy "Symphony no.2 in D major, op.36- Larghetto.mp3" "Symphony no.2 in D major, op.36- Larghetto.mp3.bak"
        1 file(s) copied.

F:\Music\Composers\Beethoven\Symphonies\Symphony 2>copy "Symphony no.2 in D major, op.36- Scherzo (Allegro).mp3" "Symphony no.2 in D major, op.36- Scherzo (Allegro).mp3.bak"
        1 file(s) copied.

***** Show that MP3 and BAK files all have matching "last written" time stampes ***** 

F:\Music\Composers\Beethoven\Symphonies\Symphony 2>dir /tw
 Volume in drive F has no label.
 Volume Serial Number is 10AC-F8B1

 Directory of F:\Music\Composers\Beethoven\Symphonies\Symphony 2

11/26/2011  12:29 PM    <DIR>          .
11/26/2011  12:29 PM    <DIR>          ..
11/26/2006  08:35 AM        16,246,912 Symphony no.2 in D major, op.36- Adagio molto - Allegro con brio.mp3
11/26/2006  08:35 AM        16,246,912 Symphony no.2 in D major, op.36- Adagio molto - Allegro con brio.mp3.bak
11/26/2006  08:37 AM         8,585,344 Symphony no.2 in D major, op.36- Allegro molto.mp3
11/26/2006  08:37 AM         8,585,344 Symphony no.2 in D major, op.36- Allegro molto.mp3.bak
11/26/2006  08:36 AM        13,518,976 Symphony no.2 in D major, op.36- Larghetto.mp3
11/26/2006  08:36 AM        13,518,976 Symphony no.2 in D major, op.36- Larghetto.mp3.bak
11/26/2006  08:36 AM         6,256,768 Symphony no.2 in D major, op.36- Scherzo (Allegro).mp3
11/26/2006  08:36 AM         6,256,768 Symphony no.2 in D major, op.36- Scherzo (Allegro).mp3.bak
               8 File(s)     89,216,000 bytes
               2 Dir(s)  397,931,245,568 bytes free

***** Switch to MM4 and change Type attribute from Music to Classical Music ***** 

***** Look again at "last written" time stamp, and see that MP3 and BAK now vary! ***** 

F:\Music\Composers\Beethoven\Symphonies\Symphony 2>dir /tw
 Volume in drive F has no label.
 Volume Serial Number is 10AC-F8B1

 Directory of F:\Music\Composers\Beethoven\Symphonies\Symphony 2

11/26/2011  12:29 PM    <DIR>          .
11/26/2011  12:29 PM    <DIR>          ..
11/26/2011  12:30 PM        16,246,912 Symphony no.2 in D major, op.36- Adagio molto - Allegro con brio.mp3
11/26/2006  08:35 AM        16,246,912 Symphony no.2 in D major, op.36- Adagio molto - Allegro con brio.mp3.bak
11/26/2011  12:30 PM         8,585,344 Symphony no.2 in D major, op.36- Allegro molto.mp3
11/26/2006  08:37 AM         8,585,344 Symphony no.2 in D major, op.36- Allegro molto.mp3.bak
11/26/2011  12:30 PM        13,518,976 Symphony no.2 in D major, op.36- Larghetto.mp3
11/26/2006  08:36 AM        13,518,976 Symphony no.2 in D major, op.36- Larghetto.mp3.bak
11/26/2011  12:30 PM         6,256,768 Symphony no.2 in D major, op.36- Scherzo (Allegro).mp3
11/26/2006  08:36 AM         6,256,768 Symphony no.2 in D major, op.36- Scherzo (Allegro).mp3.bak
               8 File(s)     89,216,000 bytes
               2 Dir(s)  397,931,245,568 bytes free

***** Do a byte-by-byte file comparison between MP3 and BAK to show files were not altered ***** 

F:\Music\Composers\Beethoven\Symphonies\Symphony 2>for %f in (*.mp3) do fc "%f" "%f.bak"

F:\Music\Composers\Beethoven\Symphonies\Symphony 2>fc "Symphony no.2 in D major, op.36- Adagio molto - Allegro con brio.mp3" "Symphony no.2 in D major, op.36- Adagio molto - Allegro con brio.mp3.bak"
Comparing files Symphony no.2 in D major, op.36- Adagio molto - Allegro con brio.mp3 and SYMPHONY NO.2 IN D MAJOR, OP.36- ADAGIO MOLTO - ALLEGRO CON BRIO.MP3.BAK
FC: no differences encountered


F:\Music\Composers\Beethoven\Symphonies\Symphony 2>fc "Symphony no.2 in D major, op.36- Allegro molto.mp3" "Symphony no.2 in D major, op.36- Allegro molto.mp3.bak"
Comparing files Symphony no.2 in D major, op.36- Allegro molto.mp3 and SYMPHONY NO.2 IN D MAJOR, OP.36- ALLEGRO MOLTO.MP3.BAK
FC: no differences encountered

F:\Music\Composers\Beethoven\Symphonies\Symphony 2>fc "Symphony no.2 in D major, op.36- Larghetto.mp3" "Symphony no.2 in D major, op.36- Larghetto.mp3.bak"
Comparing files Symphony no.2 in D major, op.36- Larghetto.mp3 and SYMPHONY NO.2 IN D MAJOR, OP.36- LARGHETTO.MP3.BAK
FC: no differences encountered

F:\Music\Composers\Beethoven\Symphonies\Symphony 2>fc "Symphony no.2 in D major, op.36- Scherzo (Allegro).mp3" "Symphony no.2 in D major, op.36- Scherzo (Allegro).mp3.bak"
Comparing files Symphony no.2 in D major, op.36- Scherzo (Allegro).mp3 and SYMPHONY NO.2 IN D MAJOR, OP.36- SCHERZO (ALLEGRO).MP3.BAK
FC: no differences encountered

F:\Music\Composers\Beethoven\Symphonies\Symphony 2>
In this example, absolutely *no* other attributes were changed. Just the Type classification.

What's the harm? Needless backups. Hope you can find what's causing this, and swat it down!

Thanks...
Top
KEP
Posts: 186
Joined: Sun Feb 18, 2007 10:27 pm
Location: Vancouver USA

Re: Type change causes 'last written' timestamp update

Post by KEP »

Bump...

I guess I'm alone in seeing this as a bug?
Top
Kent

Re: Type change causes 'last written' timestamp update

Post by Kent »

If you change any tag, the timestamp is updated. Very frustrating for backing up your music/video files. We should have a choice.
Top
Mizery_Made
Posts: 2283
Joined: Tue Aug 29, 2006 1:09 pm
Location: Kansas City, Missouri, United States

Re: Type change causes 'last written' timestamp update

Post by Mizery_Made »

You do have a choice as to whether you update the timestamp or not when modifying tags. It's in the options, on the Tags & Playlists page: "Modify timestamps when updating tags." As for it being updated when you change the type... it may have to do with the fact that the tag is "updated" when you change the type. This is probably because some types may store information a little differently in the tag. Therefor changing the type would change how the tag is written? I did find it weird myself though, when I first played around with changing types.
Top
KEP
Posts: 186
Joined: Sun Feb 18, 2007 10:27 pm
Location: Vancouver USA

Re: Type change causes 'last written' timestamp update

Post by KEP »

Mizery_Made wrote:You do have a choice as to whether you update the timestamp or not when modifying tags. It's in the options, on the Tags & Playlists page: "Modify timestamps when updating tags."
Normally, you would want timestamps updated if the tag is stored within the file as well as the database. Toggling this option off would force you do to full backups, rather than incrementals.

Actually, I just use RoboCopy to copy changed files to an external HDD and other HDDs across the network. Needless changes, especially as when moving large quantities of files from one Type to another, can present a huge burden to syncing many copies of a library.
Mizery_Made wrote:As for it being updated when you change the type... it may have to do with the fact that the tag is "updated" when you change the type.
If you mean a tag stored inside the file, that's definitely not the case. Doing a file comparison, byte-by-byte, following such a change shows absolutely no differences.

The file's "last written" timestamp should reflect changes to the file only, not to the database.
Top
Lowlander
Posts: 59216
Joined: Sat Sep 06, 2003 5:53 pm

Re: Type change causes 'last written' timestamp update

Post by Lowlander »

I can confirm that files get rewritten. This shouldn't happen in my opinion as it does interfere with backups and can cause problems when tagging files multiple times (MediaMonkey struggles with that). Added as: http://www.ventismedia.com/mantis/view.php?id=8843
Top
KEP
Posts: 186
Joined: Sun Feb 18, 2007 10:27 pm
Location: Vancouver USA

Re: Type change causes 'last written' timestamp update

Post by KEP »

Lowlander wrote:I can confirm that files get rewritten. This shouldn't happen in my opinion as it does interfere with backups and can cause problems when tagging files multiple times (MediaMonkey struggles with that). Added as: http://www.ventismedia.com/mantis/view.php?id=8843
Read the bug report (thanks!), and wonder how you're confirming the (unchanged tags in) files are actually written. Filemon? It's a more serious concern than I'd realized, if actual writes are occurring needlessly.
Top
Lowlander
Posts: 59216
Joined: Sat Sep 06, 2003 5:53 pm

Re: Type change causes 'last written' timestamp update [#884

Post by Lowlander »

I'm just verifying that the files Date Modified is updated as this is a problem for backup solutions.
Top
KEP
Posts: 186
Joined: Sun Feb 18, 2007 10:27 pm
Location: Vancouver USA

Re: Type change causes 'last written' timestamp update [#884

Post by KEP »

Lowlander wrote:I'm just verifying that the files Date Modified is updated as this is a problem for backup solutions.
Okay, made me look. :) I just ran three tests, all on the same MP3 file, and watched what MM4 (b1460) did on each using Process Monitor...

Test 1: Change the Type attribute from Classical Music to Music:

Code: Select all

11:21:21.7583012 AM	WriteFile	SUCCESS	Offset: 0, Length: 512, Priority: Normal
11:21:21.7583456 AM	WriteFile	SUCCESS	Offset: 512, Length: 417, Priority: Normal
11:21:21.7585865 AM	WriteFile	SUCCESS	Offset: 0, Length: 4,096, I/O Flags: Non-cached, Paging I/O, Synchronous Paging I/O, Priority: Normal
11:21:21.7614304 AM	WriteFile	SUCCESS	Offset: 5,183,488, Length: 3, Priority: Normal
11:21:21.7614651 AM	WriteFile	SUCCESS	Offset: 5,183,491, Length: 30, Priority: Normal
11:21:21.7615006 AM	WriteFile	SUCCESS	Offset: 5,183,521, Length: 30, Priority: Normal
11:21:21.7615386 AM	WriteFile	SUCCESS	Offset: 5,183,551, Length: 30, Priority: Normal
11:21:21.7615729 AM	WriteFile	SUCCESS	Offset: 5,183,581, Length: 4, Priority: Normal
11:21:21.7616088 AM	WriteFile	SUCCESS	Offset: 5,183,585, Length: 28, Priority: Normal
11:21:21.7616417 AM	WriteFile	SUCCESS	Offset: 5,183,613, Length: 3, Priority: Normal
11:21:21.7618304 AM	WriteFile	SUCCESS	Offset: 5,181,440, Length: 4,096, I/O Flags: Non-cached, Paging I/O, Synchronous Paging I/O, Priority: Normal
Test 2: Change the Track# from 1 to 0:

Code: Select all

11:22:33.5147143 AM	WriteFile	SUCCESS	Offset: 0, Length: 512, Priority: Normal
11:22:33.5147579 AM	WriteFile	SUCCESS	Offset: 512, Length: 417, Priority: Normal
11:22:33.5150111 AM	WriteFile	SUCCESS	Offset: 0, Length: 4,096, I/O Flags: Non-cached, Paging I/O, Synchronous Paging I/O, Priority: Normal
11:22:33.5179257 AM	WriteFile	SUCCESS	Offset: 5,183,488, Length: 3, Priority: Normal
11:22:33.5179582 AM	WriteFile	SUCCESS	Offset: 5,183,491, Length: 30, Priority: Normal
11:22:33.5179898 AM	WriteFile	SUCCESS	Offset: 5,183,521, Length: 30, Priority: Normal
11:22:33.5180210 AM	WriteFile	SUCCESS	Offset: 5,183,551, Length: 30, Priority: Normal
11:22:33.5180523 AM	WriteFile	SUCCESS	Offset: 5,183,581, Length: 4, Priority: Normal
11:22:33.5180861 AM	WriteFile	SUCCESS	Offset: 5,183,585, Length: 30, Priority: Normal
11:22:33.5181429 AM	WriteFile	SUCCESS	Offset: 5,183,615, Length: 1, Priority: Normal
11:22:33.5184154 AM	WriteFile	SUCCESS	Offset: 5,181,440, Length: 4,096, I/O Flags: Non-cached, Paging I/O, Synchronous Paging I/O, Priority: Normal
Test 3: Change the Type back to Classical Music (from Music) and the Track# back to 1 (from 0):

Code: Select all

11:23:12.0763822 AM	WriteFile	SUCCESS	Offset: 0, Length: 512, Priority: Normal
11:23:12.0764232 AM	WriteFile	SUCCESS	Offset: 512, Length: 417, Priority: Normal
11:23:12.0767581 AM	WriteFile	SUCCESS	Offset: 0, Length: 4,096, I/O Flags: Non-cached, Paging I/O, Synchronous Paging I/O, Priority: Normal
11:23:12.0795799 AM	WriteFile	SUCCESS	Offset: 5,183,488, Length: 3, Priority: Normal
11:23:12.0796137 AM	WriteFile	SUCCESS	Offset: 5,183,491, Length: 30, Priority: Normal
11:23:12.0796466 AM	WriteFile	SUCCESS	Offset: 5,183,521, Length: 30, Priority: Normal
11:23:12.0796898 AM	WriteFile	SUCCESS	Offset: 5,183,551, Length: 30, Priority: Normal
11:23:12.0797232 AM	WriteFile	SUCCESS	Offset: 5,183,581, Length: 4, Priority: Normal
11:23:12.0797612 AM	WriteFile	SUCCESS	Offset: 5,183,585, Length: 28, Priority: Normal
11:23:12.0797937 AM	WriteFile	SUCCESS	Offset: 5,183,613, Length: 3, Priority: Normal
11:23:12.0799520 AM	WriteFile	SUCCESS	Offset: 5,181,440, Length: 4,096, I/O Flags: Non-cached, Paging I/O, Synchronous Paging I/O, Priority: Normal
I don't see any differences in offsets or bytes written there. MM seems to be writing the same group of tags to the file, no matter which attributes were modified. That's a very ugly bug, from my perspective. From the developer perspective, nothing opens you up to data corruption like needless file i/o. In particular, needless writes.
Top
Post Reply

Return to “Bug Reports (MMW4)”