Modified track not re-synced to device

[tbm72]

I edited a track from my MM5 library on my PC within my DAW because it needed some attention with its EQ levels (this is something I often do because of my work). But when I went to sync it to my phone I was watching the sync process and it never downloaded the newly edited track to my phone.

To double check I downloaded the track from my phone to compare it and sure enough it's the unedited version so it never got updated during the sync. I always assumed modified tracks would get updated onto my phone during syncing, based on the fact they have a more recent timestamp. So I guess I've probably got hundreds of tracks in my MM5 library on my PC that don't match the ones on my phone.

Am I wrong to assume they would be re-synced because their timestamp is more recent? I guess I'll need to resync my entire library to make sure.

[Lowlander]

Is the file showing updated in MMW5? If so, which Build (Help > About) of MediaMonkey are you using and what exactly did you modify in the file?

[tbm72]

So as I say, I edit a file (for example an mp3) within my DAW software and make whatever changes I need. This could involve things like adjusting the EQ of the track, volume normalisation, fade ins, chopping out sections of the track etc. Then I save the edited file back to its original location. So that MM is aware the file has been changed I add/rescan that particular album back in.

If something like the bitrate of the file has been changed (maybe I've now saved the mp3 as 320kpbs instead of 128kbps) then MM seems to know and it resyncs the updated edited file to my phone next time I run a sync. But if it's something like a change to the EQ of the track then MM won't update the file onto my device.

I guess what I'm asking is under what circumstances does MM download an updated version of a track during sync? It seems to do it if the bitrate has changed but is there anything else? For example if the mp3 was originally 3 minutes long but I've shortened it so it's now 2 min 30 will it sync the shorter version over (I don't think it does)? I assumed it was something like the 'created' datestamp property of the file that determined whether to sync a file across but it doesn't look like that's the case.

I suppose what I'm going to have to do in future is to delete the track from my device and then run sync and it will download the updated version of the file from my PC because it no longer exists on the phone.

(5.1.0.2832)

[Lowlander]

Has the Timestamp changed within MMW5 after edits for those edited files that fail to re-sync? Do shortened files consistently fail to re-sync?

[tbm72]

I just tested the timestamp and it does show the correct timestamp within MM5 for a file that I just edited.

i.e. I created a test mp3 of a random track, imported it to MM5 and then edited it in Audacity to make the whole track silent. Then saved it over the top of the original, rescanned in MM5 and under Properties>Details it shows the correct updated timestamp for when I saved it over the top of the original.

I can't test the syncing part at the moment as I've just started a resync of my entire library (30k tracks!) just to make sure all the files on my phone are the correct latest versions the same as on my PC. I'll get back to you later to see if shortened files re-sync correctly but I'm guessing they won't as that's what led me to discover this issue today anyway.

[Ludek]

FYI: This may be related to https://www.ventismedia.com/mantis/view.php?id=14676

There is new option:
[.. ] Force files to resync whenever the source file has changed (slower)
but disabled by default (Sync profile > Tagging)

[tbm72]

FYI: This may be related to https://www.ventismedia.com/mantis/view.php?id=14676

There is new option:
[.. ] Force files to resync whenever the source file has changed (slower)
but disabled by default (Sync profile > Tagging)

Interesting, I never knew this setting was even available. But - it doesn't seem to make any difference. I've just tested it again with this setting both ticked and unticked and it doesn't make a difference.

If I update a track in my DAW and change the bitrate (e.g. from 128 kbps to 320 kbps) then during the next sync it DOES correctly upload the new 320 kbps to my device and overwrites the old one.

But if I do something like change the volume level of a track (as an extreme example, make the whole track silent but keep the same bitrate) then during the next sync it DOESN'T correctly upload the modified mp3 track.

In the track properties it does show the timestamp has changed to when I rescanned the now-silent mp3 but it won't resync the new version unless I do something like change the bitrate (I saw that changing the track length also triggers a sync of the edited version).

So changing the bitrate or duration of a track will definitely cause an edited track to update during a sync. But if I do something like change volume levels or EQ of a track then it won't update the new version onto my device. This is a bit of a problem for me as I need to know the tracks on my device are exactly the same as on my PC. The only workaround I can see is if I edit a track I'll need to delete it from my device and it should then appear again on the next sync.

[Ludek]

So changing the bitrate or duration of a track will definitely cause an edited track to update during a sync. But if I do something like change volume levels or EQ of a track then it won't update the new version onto my device.

OK, but I suppose that you are doing these edits in another app and after these edits the file timestamp (file modified attribute) is not changed in Windows Explorer too? So there is no chance to find that the file has been really changed/modified by the other app (including MediaMonkey)?

[tbm72]

OK, but I suppose that you are doing these edits in another app and after these edits the file timestamp (file modified attribute) is not changed in Windows Explorer too? So there is no chance to find that the file has been really changed/modified by the other app (including MediaMonkey)?

No, the timestamp (file modified property) *does* correctly show as changed in Windows Explorer. And as I said above, the timestamp does also show as changed in MediaMonkey too (under Properties>Details/Timestamp) but that doesn't seem to be enough to trigger a resync. It seems to only resync the edited/updated file if either the bitrate or duration has changed.

[Ludek]

Hmm, that's strage,
so are you sure that the file is on the sync list and the 'Timestamp' on Properties > Details page has changed?

[tbm72]

Yes, file is definitely on the sync list and timestamp is definitely updated under the properties tab.

If the bitrate or track duration has changed it always resyncs but if the bitrate or duration stays the same then it doesn't.

I guess I'm in a specific use case here that maybe not many other people will experience so not to worry!

[Dan33185]

Were you ever able to figure this out? I am wondering the same thing going forward as I often times will edit live tracks (intro/outro talk, etc.) as I come across them in my library, and I guess I just assumed MM didn't detect that kind of stuff. I've been deleting my whole library every few months and re-syncing, but it's become really slow and I'd like to avoid that if possible, so if MM has a way of detecting if a file has been cut/added EQ, etc. automatically, it would be really helpful.

[Lowlander]

Please try with MediaMonkey 2024. Are changes still not seen and re-synced for you?

[Dan33185]

Please try with MediaMonkey 2024. Are changes still not seen and re-synced for you?

I haven't had a reason to need the function recently, so I haven't tried it, just more curious for future cases. But, I can modify a file quick just to test it and see it if it works.

[tbm72]

No, still looks like the issue is there (on latest v3082). I edited a track from the library on my PC, muted it to silence and saved it. But when I ran a sync it didn't upload the new version, even though the timestamp has updated. I made sure to tick 'Force files to resync whenever the source file has changed (slower)'.