by davidbspalding » Tue Feb 02, 2010 2:11 pm
Running software from a shared network drive .... Huh-uh, I wouldn't do that. But
there's a Support post about locating the database as well as the music on a server. I suppose you could have your .INI copied to the server routinely, and have other computers download the latest copy before running MM. This is a sort of Parent - Child relationship, with a network server as the "drop box." But I would definitely keep the software running locally. (A non-commercial gold license is allegedly good for three computers to use, so there's no economic necessity for this.)
I tried hosting the dB on my network share ... and endured intermittent problems with MM having queries fail ... and it wouldn't recover very gracefully from it. Fortunately, I had a scheduled batch file making backups of the database. Another member suggested keeping the database locally (on the system which I sync with), and that's helped with the errors and performance; I edited the batch file to copy the dB to a shared drive for my secondary computer (which I rip CDs on) to access. My primary, syncing computer scans the NAS share where my music is stored for changes, so when the secondary, ripping computer uses AutoOrganize to move music (and m3u playlists) to the NAS, the primary computer picks up on the new music when it starts.
BTW, I would NOT access the shares in your MEDIAMONKEY.INI via drive letter ... use IP address (e.g. \\192.168.1.2\share1\mp3files\), or UNC if you have an entry in your
hosts file and the share is on a static ip (e.g. \\simpleshare\share1\mp3files\). Why? Some operating systems (cough -- Windows) are crotchety about reading or writing to network drives if they haven't been "accessed" first. Don't ask me to explain, it's as mystifying to me as it is lame.
Running software from a shared network drive .... Huh-uh, I wouldn't do that. But [url=http://www.mediamonkey.com/support/index.php?_m=knowledgebase&_a=viewarticle&kbarticleid=49]there's a Support post about locating the database as well as the music on a server[/url]. I suppose you could have your .INI copied to the server routinely, and have other computers download the latest copy before running MM. This is a sort of Parent - Child relationship, with a network server as the "drop box." But I would definitely keep the software running locally. (A non-commercial gold license is allegedly good for three computers to use, so there's no economic necessity for this.)
I tried hosting the dB on my network share ... and endured intermittent problems with MM having queries fail ... and it wouldn't recover very gracefully from it. Fortunately, I had a scheduled batch file making backups of the database. Another member suggested keeping the database locally (on the system which I sync with), and that's helped with the errors and performance; I edited the batch file to copy the dB to a shared drive for my secondary computer (which I rip CDs on) to access. My primary, syncing computer scans the NAS share where my music is stored for changes, so when the secondary, ripping computer uses AutoOrganize to move music (and m3u playlists) to the NAS, the primary computer picks up on the new music when it starts.
BTW, I would NOT access the shares in your MEDIAMONKEY.INI via drive letter ... use IP address (e.g. \\192.168.1.2\share1\mp3files\), or UNC if you have an entry in your [i]hosts [/i]file and the share is on a static ip (e.g. \\simpleshare\share1\mp3files\). Why? Some operating systems (cough -- Windows) are crotchety about reading or writing to network drives if they haven't been "accessed" first. Don't ask me to explain, it's as mystifying to me as it is lame.
