Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[glynor]

I've now updated the library sharing scripts that I developed (and which were described in detail in this thread over here) to run in WSH scripts (VBScript) rather than simple BAT scripts.  This allows me to do a few slightly more powerful things with them, and also prevents the CMD window from popping up when the scripts run (yay).

This time, I've also included a README file which explains how to set the system up in more detail.  Plus, I set up all the items you might need to modify in the scripts as variables clearly marked at the beginning
of each script.  In the future, I might figure out how to do the VBScript version of the C "includes" statement so that you don't have to modify this information individually on each script, but I haven't gotten there yet.  So, for now, you have to modify each of the scripts before you use them to put in the proper paths to your various libraries (the local and shared ones).

NOTE ON SETTING VARIABLES:

I haven't modified the README file to include this, but I'm getting common questions about setting the variables.  Hopefully this will help explain it a bit better.

My local library is stored at: C:\library_data\standard
My "shared" library is stored at: M:\library_data\standard

So, I have my variables set like this:

Code: [Select]

'USER DEFINED VARIABLES

strSharedLibraryDir = "M:\library_data\"
strLocalLibraryDir = "C:\library_data\"
strLibraryName = "standard"
It makes no difference what MC "calls" the library in the library manager, only which folder it's in.  I originally designed it that way so that I could eventually modify the scripts further to allow you to use them with multiple libraries, but I never got there.   

If you have any questions about how to set this up, just ask (though please read the README file I wrote first)!

Download them here!

Current Version: 2.04

[glynor]

1.0

Old BAT file version.

2.01 - 20060926

Initial Public 2.x release

2.02 - 20060926

Fix: Forgot to include the MC_Library-Import_Only.wsf script in original archive.

[glynor]

2.04 - 20060926

• NEW: Added /verbosity command line option (which when set to "on" pops up a timed message when the script finishes running)
• NEW: Included Start Menu Icons
• FIX: Updated internal messaging to make updates simpler
• NEW: Included my_variables.txt file and included suggestion for use in README
• FIX: Updated README file

To use the new /verbosity command line option simply set it to either on or off on the command line when calling one of the scripts (the default is off so if you omit the option it will not show the message).  It works with all of the scripts.

EXAMPLE 1:

Code: [Select]

M:\scripts\MC_Scripts\MC_Library-Import_Shared.wsf /verbosity:on
This would run the Import Shared script.  When it finishes it will pop up a message box stating that it completed.  The message box will disappear when you click OK on it or after 5 seconds elapses (whichever comes first).

EXAMPLE 2:

Code: [Select]

M:\scripts\MC_Scripts\MC_Library-Import_Shared.wsf /verbosity:off
-or-
M:\scripts\MC_Scripts\MC_Library-Import_Shared.wsf

Both of these commands will run the Import Shared script but neither will show the message box.

[glynor]

I got this personal message but decided to post it so that others would see the answer too:

Do these scripts copy everything including thumbnails or should I continue to use the  scripts that copy my entire database over to the laptop. I was confusing myself wondering if your scripts keep only the tag info in order but I guess the entire database might be needed (I'm really not up to speed in all this yet).

My database folder is about 2.2GB; this seem normal?

No, they do not copy everything.  The scripts use the exclude.txt file to exclude any files with "\Thumbnails\" or "\Cache\" in their filenames, which essentially excludes everything in those two folders.

I'm not exactly positive what the files in the \Cache\ folder do, but they aren't needed for the tag data and database info to work properly, and copying them over makes the scripts take lots longer to complete, so I exclude them (and essentially let each copy of MC manage it's own cache). 

As for the \Thumbnails\ folder...

If I'm not mistaken, if you have a folder called Thumbnails inside your library folder, then it's an old remnant of a much older version of MC (unless you changed it back there manually).  MC12 includes a registry key HKEY_CURRENT_USER\Software\JRiver\Media Center 12\Properties\Thumbnails - Base Path which is set by default to [Application Data Path]Thumbnails\.  That puts your Thumbnail cache at: C:\Documents and Settings\<USERNAME>\Application Data\J River\Media Center 12\Thumbnails.

If you manually moved your Thumbnails cache to live in a subdirectory of your local library's folder, and you want the thumbnails to be included in the "sync", you can certainly delete the line that says "\Thumbnails\" out of the exclude.txt file and then it will happily copy those files over as well.  However, since the script does not do incremental copying at all, this will take much longer.  I would recommend that if you want to sync the Thumbnails folders on various different computers, that you investigate a solution like SyncBack instead, as that will have much better performance.

[glynor]

There's a more in-depth description of how I use these scripts posted over here: http://yabb.jriver.com/interact/index.php?topic=39663.msg270298#msg270298

[glynor]

Sorry... I'm working insane hours this week (and next).  Summer is my busy time...

The podcast problem has nothing (or little) to do with any out of memory error.  The only issue is that when you sync the libraries using the scripts, there's no way to specify one machine as the "Podcast Auto Downloader" and have the rest have Auto-Downloading disabled.  This can cause duplicates to get downloaded and other wackiness.  The reason for this is that the auto-download "status" is stored in the podcast.xml file in the library.  To do this, the script would have to keep track of which machine its running on and edit the XML file to turn that flag on and off selectively depending on which machine its running on.

This could be done with the windows scripting host, but really at that point, it would be much easier to just write a real honest-to-god application to do it, which is what I'm considering doing.

What I'm worried about is that I'll decide to do it, and then spend a bunch of time and get 3/4 of the way there, and then Jim & Co will decide to change MC's database to a relational, network-aware, multi-user system.  While I'd love that, I'd be awfully disappointed if I did a lot of useless work!

[JONCAT]

Hey Glynor - hope the Mainiac in you is coming out full force this Summer.

As you know , I never had any luck setting the script system up. The result, or lack thereof was right strange, but hopefully we can just attribute all that nonsense to running Winx64 at the time.

I'm going to give it another go, but I was wondering if using a vbs script withOUT your flagging system would be asking for trouble; I'm pretty sure it is so I'll see if I can't get your scripts working properly on XP SP3

DC

[glynor]

Not sure I follow... What exactly are you asking?

[JONCAT]

I'm going to give it another go, but I was wondering if using a vbs script withOUT your flagging system would be asking for trouble; I'm pretty sure it is so I'll see if I can't get your scripts working properly on XP SP3

sorry, I left out a rather important negative. I was wondering if I had MC on two pcs using a vbs script to write the library to the shared folder on shutdown and pull from it on startup, the setup would need to have the flagging to avoid problems (overwriting or importing old library data). I assume that’s why you set it up as such; I had considered just using scripts to work with a shared library folder but the more I thought about it it seemed like it could become problematic.

DC

[Johnny B]

Code: [Select]

M:\scripts\MC_Scripts\MC_Library-Import_Shared.wsf /verbosity:on
This would run the Import Shared script.  When it finishes it will pop up a message box stating that it completed.  The message box will disappear when you click OK on it or after 5 seconds elapses (whichever comes first).

Is it somehow possible to change this behaviour so that the message box stays on until I click OK and does not disappear automatically? 5 seconds is too short, sometimes I perform the scripts when I am not looking at the screen all the time and then I am not sure if the script has already finished or if it is still in progress...
Apart from this big THANKS for this great feature!

[glynor]

Sure.  Shouldn't be difficult to do at all.  I can make a /verbose=stayon option or something like that.

I actually plan to make some other tweaks to the scripts as well, so give me a couple of days.

[Johnny B]

Great! Thank you in advance 

[Johnny B]

So when can we expect the promised update? 

Another question: can I use these "old" scripts also in MC13? Does everything works the same way here as in MC12 or are there any differences which need to be taken into consideration? What is the best approach (regarding your scripts) if I want to finally switch completely from MC12 to MC13?

[glynor]

Sorry...

To answer your question, the scripts DO still work just fine with MC13.  I've continued to use them with no issues.

About the update.  I can't give a promised date, but I'll really, really try to get to it this week.  I had just completely forgotten about it.  It is now on my To-Do list, though.

[Johnny B]

We are still waiting...