Announcement

Collapse
No announcement yet.

Change in Tagging behavior?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    DVD Ripper Change in Tagging behavior?

    Has there been some change in the way DVDFab builds the ID3 tags in recent releases (post 8.0.8.5)?

    The reason I ask is over the last few months I have noticed a quite pronounced change in the time it takes to alter the value of the Genre tag in any files ripped by DVDFab. At first I put it down to a Windows Update having changed some behavior, but recently, after having to revert to 8.0.8.5 to get around a few recent problems I notice a distinct change for the better with the 8.0.8.5 files.

    For the record here's what I'm describing... (using Windows 7)

    1. Rip my movie with DVDFab
    2. Select the movie in Windows Explorer
    3. Right Click and select properties
    4. Go to the "Details" tab, scroll down to Genre and enter a value
    5. Click on OK

    Up until version 8.0.8.5 when you click OK, the Properties window disappears almost instantly, beyond that version (I suspect since the QT versions given how long it's been happening), it can take quite some time before the properties window closes (visibly minutes). The effect is more pronounced the bigger the file.

    Worse still, if the file is already out on my server when I try and tag it, then it takes a VERY long time (over 10 minutes is not unusual). Watching what is happening on the server during this time has given me a clue as to what is going off. Whilst the Properties window is "hanging" I can hear a lot of disk activity, and when I look in the directory on the server I can see a second .tmp copy of the file being written, which gets tidied away once the window closes.

    My suspicion is that at some point DVDFab has altered the way it writes Tags, in such a way that Windows is no longer able to update the tags "in place" and so creates a new copy of the file, with the updated tags, and then either switches the names and deletes the original, or reads the updated file back into the original. Either way once the file is on the server this becomes very noticable as the "copy" is taking place "through" the windows box, meaning the entire content of the file shifts over the network at least twice (depending on the exact method Windows is using).

    Has anyone else noticed this? Can it be corrected in a future release? I'm on 8.1.6.1 at the moment, but I've been through many of the intervening releases, and it's been doing this for a while.
Working...
X