Track Redirection & Synchronization 3.4 (2012-10-08) [MM3+]

[ZvezdanD]

I assume it will only update the ones that have changes?

Yes, I already explained that:

if some metadata, e.g. Artist, is same between master and redirected track, it would not be written during sync at all (there is no need to write same data over existing tag).

[ZvezdanD]

There is a new version of this script: v3.0 - 2009-08-07
- Added: Synchronize and Transfer playstats options to the Create Redirections/Copy Metadata dialog box; it is now possible to copy metadata between duplicates which are not already redirected;
- Added: Synchronize and Transfer playstats options to the Show and Remove Redirections dialog box which is now renamed to Maintain Redirections;
- Added: possibility to turn on/off the transfer of playstats and/or synchronization when creating redirections;
- Added: Select unsync button to mentioned dialog boxes, after click on it you would get selected only redirections which have unsynchronized metadata;
- Added: when you click on some redirections in mentioned dialog boxes which has unsynchronized metadata you would get displayed which metadata are different in the bottom of the dialog;
- Added: option to display all/only selected duplicates in the Create Redirections for Duplicates dialog box;
- Added: Synchronize metadata to match masters only option now works using manual synchronization, i.e. even with turned off the Automatically synchronize metadata option;
- Added: Tag and File options for album art storage during synchronization (until now only same storage as with master was possible);
- Added: selection of tracks with similar titles (e.g. Title (live)) if there is none track with exactly same title in Create Redirection for Specified Tracks dialog box;
- Added: possibility to hide some of menu items from this script by modifying .ini file, e.g. you could hide .asx options if you are using only redirected audio files;
- Fixed: transfer of playstats from redirected audio files to masters (until now only transfer from redirected .asx files worked correctly).

[nynaevelan]

Z:

I have two tracks which I've selected, both are new to the library, in order for the redirections to be created, but I keep getting an empty box. I tried both Create Redirections for... and Create/Copy Metadata... and neither gives me the dialog box with the tracks in it in order to create redirections for these tracks. Am I missing something??

Nyn

[ZvezdanD]

I have two tracks which I've selected, both are new to the library, in order for the redirections to be created, but I keep getting an empty box. I tried both Create Redirections for... and Create/Copy Metadata... and neither gives me the dialog box with the tracks in it in order to create redirections for these tracks. Am I missing something??

I don't know. Are you sure they both have same Artist names and Titles? Have you added them to the Library or you are accessing them in the My Computer node? Could you post a screenshot with the main window where I could see those tracks?

By the way, you could use Create Redirections for Specified Tracks even for tracks which don't have same Artist names and Titles, but you need to specify the redirected one.

[nynaevelan]

Yes I am sure they arein the library and they are all named the same, version 2.5.1 picks them up but here is a screen shot of the six tracks.



Nyn

[nynaevelan]

Here is what it looks like in 2.5.1:



Nyn

[ZvezdanD]

Here is what it looks like in 2.5.1:

Thanks for the report. There is a new revision: v3.0.1 - 2009-08-08
- Fixed: empty table in Create Redirections/Copy Metadata with turned on only selected in main tracklist and empty folder text boxes.

[nynaevelan]

Thank you, now I am back in business.

[Bex]

Well, you need to use the Flush method to ensure that your changed (or created) ini values are immediately saved to the disk.

I knew that you will say that. Well, I don't need to use the Flush method since my scripts work just fine without it (and without installed your scripts). And it is not true that SDB.IniFile is a way faster if it is used with a global variable. Anyway, I don't need to write to .ini file so often to get some slow-downs because of such use. In my opinion reliability is more important than speed. If I need reliability I need to use Flush method every time after oSomeGlobalIniVarialble.StringValue = ..., so I would get same slow-downs as when I use SDB.IniFile directly. You are not using Flush method either, so if the program crashes your .ini settings made during last session would be lost as well.

Yes, you do need to use the flush method to ensure that your scripts write its ini values to the ini file. No, it is indeed very true that a script is way faster if you use a variable for SDB.IniFile, you can even use it in a loop without any delay.

So instead of calling other scripts nasty, you should change your scripts so they give you the reliability you need if MM crashes.

[ZvezdanD]

Well, you need to use the Flush method to ensure that your changed (or created) ini values are immediately saved to the disk.

I knew that you will say that. Well, I don't need to use the Flush method since my scripts work just fine without it (and without installed your scripts). And it is not true that SDB.IniFile is a way faster if it is used with a global variable. Anyway, I don't need to write to .ini file so often to get some slow-downs because of such use. In my opinion reliability is more important than speed. If I need reliability I need to use Flush method every time after oSomeGlobalIniVarialble.StringValue = ..., so I would get same slow-downs as when I use SDB.IniFile directly. You are not using Flush method either, so if the program crashes your .ini settings made during last session would be lost as well.

Yes, you do need to use the flush method to ensure that your scripts write its ini values to the ini file. No, it is indeed very true that a script is way faster if you use a variable for SDB.IniFile, you can even use it in a loop without any delay.

So instead of calling other scripts nasty, you should change your scripts so they give you the reliability you need if MM crashes.

No, I don't need to use Flush method and my scripts would save values to the .ini file correctly. They are not working correctly only if I have installed your scripts. Yes, your scripts are nasty because I lost several hours of my time writing some SQL queries for Magic Nodes and Regular expressions for Find & Replace script only because I had installed your scripts - if I didn't have your scripts installed it would not happen. Yes, I could add the Flush method to my scripts, but you didn't answer to my question what about a bunch of old scripts where their authors are not supporting them anymore. As I said, this change in .ini handling is most problematic of all MM devs decisions. I am not the only one who is against their decision - I remember many complains of some scripters about it, at least it was MoDementia and raybeau528. I remember many times Jiri responded to me and other scripters when we asked why some things are implemented like they are and he said that he do not want to change anything because of compatibility. On another side, he added such thing like .ini handling and Flush method which affect with compatibility more than we asked for. I remember also some scripters had some errors generated on the line with the Flush method, I think it was raybeau528 with some of his scripts. If you think that the Flush method is a solution, why don't you use it in your scripts?

You could repeat your claims as many times as you want, but you didn't give me any proof. I remember two times before I gave you a proof that my code is faster than your sending you test scripts, and you responded how "even though it is slower (wonder why?) it's still unnoticeable imo since the function is only used a couple of times". So, I could respond like you and repeat myself - I am not using access to .ini file so often to notice such slow-downs. But, you are intentionally skip my main point about this all the time - I am not telling that you should not use variables to access IniFile object, I just say that you should not use GLOBAL variable for such thing. I am using local variables for IniFile object whenever it should and it works nothing more slower than with a global variable. If you are so concerned about the speed why your PlayHistory is not using global variable for IniFile object?

However, instead of you, I have a real proof that you are wrong. Your claim that using a global varibale and the Flush method is a way faster than direct access to the IniFile object is simply opposite to the truth. Here are two test scripts. You need to remove all scripts from Auto folder and to copy the first and the second script in it one at time, i.e. save the first script to Auto folder, start MM program and wait for it to finish, than exit program, delete the fist script, copy the second one to Auto folder and start MM. If you are too lazy to do this, here are results - my version of code is executing for 44 seconds, and your version is executing for 230 seconds! Now, could you tell me whose code is a way faster?

Code: Select all

' Zvezdan's version of the .ini file access
Option Explicit

Sub OnStartUp()
    Dim i, j
    Dim dTime

    dTime = Timer
    For j = 1 To 10000
        For i = 1 To 9
            SDB.IniFile.IntValue("ZvezdanTest", "Item" & i) = Int(Rnd * 100000)
        Next
    Next
    SDB.MessageBox FormatNumber(Timer - dTime, 2), mtInformation, Array(mbOk)
End Sub

Code: Select all

' Bex's version of the .ini file access
Option Explicit

Dim oIniFile

Set oIniFile = SDB.IniFile

Sub OnStartUp()
    Dim i, j
    Dim dTime

    dTime = Timer
    For j = 1 To 10000
        For i = 1 To 9
            oIniFile.IntValue("ZvezdanTest", "Item" & i) = Int(Rnd * 100000)
            oIniFile.Flush
        Next
    Next
    SDB.MessageBox FormatNumber(Timer - dTime, 2), mtInformation, Array(mbOk)
End Sub

[nynaevelan]

Z:

I am getting this error when trying to syncronize 31644 tracks from Maintain Redirections, is this a bug or a limitation of the number of tracks selected to sync?



Nyn

[ZvezdanD]

I am getting this error when trying to syncronize 31644 tracks from Maintain Redirections, is this a bug or a limitation of the number of tracks selected to sync?

It is a bug. Practically, there is no limitations to the number of selected tracks (actually, there is a limitation on 2^31 = 2,147,483,648 tracks). Unfortunately, from your screenshot I cannot see where it occurs (Line: 0, Column: 0). I suppose one of your tracks has some problematic tag, but I don't know which one. Did you see a number of synchronized tracks in the progress bar before this error occurs or this error occurs immediately after you click on the Synchronize button? It could be helpful if you locate which track leads to the error. If you are interested to help me in locating this bug, I will send you a modified version of this script with the logging. Also, if you had Event Logger installed, you could see which track is last successfully modified, the next one is problematic.

[nynaevelan]

Yes I would be interested in helping.

[ZvezdanD]

Yes I would be interested in helping.

Thanks for the report and help. There is a new release: v3.0.2 - 2009-08-15
- Added: LogReport key to the TrackRedirection section in the .ini file, enables logging of some events (sync, transfer) if set to = 1;
- Fixed: synchronization of Original Date tag with month/day information.

[nynaevelan]

z:

In a future release would your consider the possibility for Track Redirection to use a specified filter rather than the active filter?

Nyn