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. Have a look at this
YouTube video – or just search for "Meisterbarden".
If you understand some German, you may have a look at our website
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
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
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.
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
And: Apologies for some funny/strange phrasing in this text; I'm not a native English
And now: Download and enjoy!
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
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)