WAN Songbook Filler

Hello, this is Arnhor from server Vanyar. Since 2008, our band "Die Meisterbarden von Bree" is performing every Friday night (Central European Time) at the Auction House of Bree. Just search for "Meisterbarden" at YouTube.

If you understand some German, you may have a look at our website meisterbarden.hanft.de for more information about us.

If you are a LOTRO musician, you know the problems which arise when you have several people in your band who are all contributing new music files which must be distributed to all other players in order to play together. You could send them by e-mail to the others, or put them into a Teamspeak browser or something like that. But there are some big disadvantages in "distributing" the files at all: Sometimes, musicians are busy in "Real Life" and cannot perform once or twice, and after three weeks the questions arise "which files are new?" – "where can I download the new files?" – "are there improved files which I have to overwrite?" and more. Ok, on the first thought, you could manage by "file date since last concert" or so. But believe me (and I do have more than 4-year-experience): After some time, with many (5,000+) files, many file folders and directories, and more than 2 players: somewhen you will get "unsynced" somehow.

To avoid getting "unsynced", we have lately installed a shared "web music folder". I won't go in-depth here for a detailled explanation, but give some hints which should be sufficient for more-or-less computer/server admins to create such a shared folder:

• Create a music directory on a web server somewhere out there in the Internet.
• Limit directory access just to your friends (as always: .htaccess or httpd.conf etc.).
• Enable WebDav access to that folder (with Apache, it's just "Dav On").
• Install NetDrive on your LOTRO computer. This is a WebDav client which simulates the WebDav web server folder as a local drive, for example "Z:" (Windows does have a built-in WebDav client, but it seems to be rather buggy, at least if you want to access case-sensitive Linux file systems on the server). (Google Drive does work, too, if you don't happen to have own webspace available.)
• Open a cmd shell with admin rights, go to your LOTRO music folder, and enter the command mklink /d band Z: (this is true for Windows 7; with Windows XP, you have to download junction and enter junction band Z: instead).
• Now the folder of your band is just a sub-folder of your normal LOTRO music folder called "band"; you can use it with Windows Explorer just normally to create, copy, delete, or edit music files.
• Within LOTRO, you can directly play music files in your band folder by just /play band/lalala 5 sync (and also /playlist now includes that folder)
• If you don't need a local music folder any more, you could even go to LOTRO folder and create a link mklink /d Music Z: – then your complete music (sub)folder(s) is shared on the server (and you don't need to specify a subfolder at the /play command)!

Get the point? New music files just have to be put into that "band" folder, and every musician can play them just like that – no copying, no overwriting, no asking... great, isn't it?

Of course, the shared folder is also included in the Songbook Plugin which many of our band members are gratefully using. As you already know, you have to update the Songbook plugin data files before using in LOTRO. And here comes the problem: The original "Songbook.HTA" script (and some other external "SongBookFiller" application which I had found) read each and every music file every time to get the track info (track ID and name) which is displayed in Songbook. Now think of 5,000+ music files which reside on a server somewhere out there in the Internet: Reading (which, in effect, means "complete downloading"!) all those files for every Songbook update lasts more than half an hour every time... and would be actually unnecessary for files that weren't changed since last "scanning"!

So my idea was "scan only newer files" and keep the rest in some kind of a "local database". Since getting the directory of a web server is very fast (which includes file alteration date/time and file size), the file-content (which includes the track information) is only (re-)read if...

• ...no local track information is stored yet at all (of course, this is always the case at the first run); or...
• ...file date/time and/or file size of the "real" file differ from the locally stored file date/time and/or file size.

Nice side-effects:

• Since the mentioned "local database" happens to be a CSV file, you could open it with OpenOffice Calc or Microsoft Excel and continue to process your music files, for example populate an SQL database, or display a playlist on a web site;
• Of course, you can use the software without any web folder, too – since scanning directories is very fast, but reading files is rather slow, it should speed-up your (local-only) Songbook plugin data update as well.

I have called my software "WAN Songbook Filler" because it's best used when your music files are distributed in one or more wide area networks. (Granted: Not very fancy, but it describes the function and purpose best, doesn't it?)

If you have any questions, you can contact me by e-mail. And: Apologies for some funny/strange phrasing in this text; I'm not a native English speaker.

And now: Download and enjoy!

Revision History:

• 1.4: Until version 1.3, you couldn't browse through folders where no ABC files were located at all. From version 1.4 on, all "in-between" folders down to a sub-sub-sub...folder are now included so that you can browse to a song called "sub1/sub2/sub3/sub4/mysong.abc" even if sub1/2/3 are completely empty.
• 1.3: Well, if it would have been that easy... In fact, it's not. Linux servers store file modification time together with time zones, WebDAV servers deliver GMT or local time (together with time zone information or not), WebDAV clients add or subtract their local time zone to or from the delivered time... and all this even depends on DST active (or not) by the time of uploading and/or downloading! There are just too many pieces of software involved in this process so that you can get unpredictable results anyway. So I gave up finding a solution for managing the correct time zone by all means, but installed a checkbox in the program which treats an exact 1-hour offset as "same time". Granted, this may lead to miss a changed file if it was modified exactly one hour (to the second!) after the last write, but I think this won't happen very often – and if you're suspicious about it, just un-check the "Ignore" checkbox.
• 1.2: Stores file time as UTC time instead of local time. So you don't have to re-read all files at the beginning and at the end of daylight saving time. (Of course, the program will re-read everything when you upgrade from version 1.1 to version 1.2 – but only once in a lifetime, and not twice per year.)
• 1.1: Creates a single track (with an empty name) even for ABC files where no tracks are found at all (because Songbook seems to be a bit allergic about empty track arrays)
• 1.0: First version